Reading an MCP server by its tool list: Sakupa's 18 tools, sorted by what they can change

#sakupa #mcp #ai #staticsites

A disclosure first: I am not Sakupa's developer. I came across this MCP server while looking into AI-published websites, and this post is my reading of its official manual's tool list. It is not a hands-on review.

When I evaluate an MCP server, I start with its tool list — not to count features, but to see where the line falls between what the AI may do on its own and what must stop for a human. Sakupa lists 18 tools. Sorted by what each one is allowed to change, they fall into three tiers.

Tier 1: Read-only (5 tools)

Tool	Role
`analyze`	Read-only pre-publish check; warns about unsuitable files
`status`	Shows connection state, expiry, and domain state
`plans`	Public catalog of pricing plans
`billing`	Checks the actual contract, renewal schedule, and usage
`help`	Local-only read-only diagnostics

Nothing in this tier changes the site or the contract. analyze is the interesting one: it reads before publishing and warns, but it does not fix or remove anything itself. The "look first" step is structurally separated from the "change" step.

Tier 2: Change, but only after a preview and confirmation (5 tools)

Tool	Role
`deploy`	Publishes the site, after confirmation
`rotate`	Swaps admin credentials (after preview, all old credentials expire)
`delete`	Deletes a free site (preview required, irreversible)
`report`	Fault report, only when `help` recommends it, sent after preview
`support`	Opens a support ticket (the user confirms the content before sending)

The irreversible operations live here, and their procedures get heavier as the stakes rise. delete is documented as irreversible; rotate shows in preview that old credentials will all expire. report cannot be fired casually — it requires a local diagnosis recommending it first.

Tier 3: Guide to the door, then hand over to the human (4 tools)

Tool	Role
`subscribe`	Creates a Stripe signup link for the chosen plan
`change`	Creates a Stripe management link for plan changes or end-of-term cancellation
`portal`	Opens the Stripe portal for invoices and payment methods
`bind`	Connects a custom domain (confirmed via DNS; only described as "published" when state is `active` and HTTP 200 is returned)

Money and domains sit in this tier, and the shared pattern is that the AI never handles card numbers or rewrites the contract itself. Payment happens on Stripe's page; a domain is not called "published" just because it was attached — it must be reachable first.

The remaining 4: setup, upkeep, recovery, apps

Tool	Role
`init`	First-time setup (local only, no network)
`refresh`	Extends a free site's expiry
`recover`	Recovers a site via a device path or a DNS path
`apps`	App catalog; the first app is a mail form

recover answers the weakness of a no-registration design: what happens when you switch machines. Two paths exist, and whether old credentials expire is the user's choice — the AI does not decide that for you.

What the sorting reveals

Three principles repeat across the tiers:

Read-only and mutating operations are separate tools, not modes of the same tool.
Mutating operations carry a preview and confirmation step, weighted by how reversible they are.
Money and authority decisions stay with the human. Payment goes to Stripe's page; credential revocation goes to the user's choice.

Tool lists are usually read as feature checklists. Read as a permission map, they tell you how much a server trusts its own agent — and where it deliberately does not.

Scope notes (from official information only)

Static sites only; not for web apps with databases or login features.
A relatively new service (first published on npm in July 2026, per the official timeline). The free preview (usually 30 days) is the sensible way to try it small first.

DEV Community