The tools that never change anything: Sakupa's read-only set, and why it comes first

#sakupa #mcp #ai #staticsites

A quick note first: I am not a Sakupa developer. I came across this MCP server while looking into how small-business websites get published, and this post is my own summary of public information from the official site and the official manual. This is not a hands-on review.

Sakupa is an MCP server that lets an AI agent publish and operate a static website, with no account registration. The manual lists 18 tools. Most write-ups group them by what they do — publishing, billing, domains, support. This time I want to read them from a different angle: which tools never change anything at all?

The read-only set

Six of the eighteen tools are read-only. They look, check, and report — they do not publish, charge, or delete anything.

Tool	What it does
`init`	First-time preparation. Runs locally only, no network traffic
`analyze`	A read-only check of whether a site is publishable; warns about unsuitable files
`status`	Shows connection state, expiry, and domain state
`plans`	The public catalog of pricing plans
`billing`	Checks the actual subscription, renewal schedule, and usage
`help`	A read-only local diagnostic

init runs once, on your own machine, and talks to nothing. analyze reads the site before anything is published and stops the flow if it finds a problem. status and billing answer "what is the current state?" without changing it. plans is just the price list, in the open. help diagnoses locally before anything is reported anywhere.

Why the read-only tools come first

What struck me is where these tools sit in the workflow. The read-only checks are at the entrance of every flow:

Before publishing, analyze reads first. Nothing is deployed until it passes.
Before paying, plans shows the catalog and billing shows the actual subscription. The agent's word alone is not the source of truth.
Before reporting a problem, help diagnoses locally. A fault report only goes out if help recommends it.

The pattern is consistent: read before you write, and check before you act.

The contrast: tools that do change things

The other twelve tools do change things — and every one of them is wrapped in a preview or a confirmation step. deploy publishes only after a preview and confirmation. rotate exchanges credentials only after showing what will be invalidated. delete removes a free site only with a preview, and it cannot be undone. support files a ticket only after you confirm its contents. subscribe and change don't even take payment themselves — they create a Stripe link, and you complete the action on Stripe's page.

So the design splits into two halves: a read-only half that is free to run any time, and a changing half that always pauses for confirmation first. The read-only half is also where the service puts its evidence: if you want to know what your subscription actually is, you check billing, not the agent's summary.

What this reading shows

Reading the tool list by "what never changes anything" makes three things visible:

The entrance to every flow is read-only. Checking comes before publishing, paying, or reporting.
The changing tools all pause first. Publishing, credential rotation, and deletion each go through a preview and a confirmation.
Money and authority decisions stay with the person. Payments happen on Stripe's page, and whether old credentials are invalidated is your choice, not the agent's.

When evaluating an MCP server, the tool list is worth reading twice — once by what the tools do, and once by which ones can never change anything. The second reading tells you where the design puts its caution.

Notes (within the scope of official information)

Sakupa is for static sites only. It is not for web apps with databases or login features.
It is a relatively new service (first published on npm in July 2026, per the official timeline). If you are considering it, trying the free preview (usually 30 days) with something small seems like the sensible first step.

DEV Community