Safety
The assistant acts as your account. It can change your live site and, if you allow it, email your subscribers. This page says what stands between a tool call and those effects.
The real boundaries
Two things actually stop an unwanted action. Both are under your control, not the assistant's.
- Your client's tool-approval prompt. Outward-facing tools carry the MCP destructive hint, so Claude Code, Claude Desktop, Cursor, and VS Code ask before running them unless you have auto-approved them.
- The server's environment switches. They are read when the server starts, and the assistant cannot change them.
| Switch | Off (default) | On |
|---|---|---|
MICROPAGE_MCP_ALLOW_SEND=1 | publish_post refuses any post that would email a list. Web-only posts still publish. | publish_post can email the list. |
MICROPAGE_MCP_ALLOW_DELETE=1 | delete_project is not registered. | delete_project exists. |
MICROPAGE_MCP_SUBMISSIONS=1 | list_submissions is not registered. list_forms still gives counts. | The assistant can read what visitors typed into your forms. |
Turn a switch on only for the session that needs it, and remove it afterwards. See Install for where to set them.
Do not auto-approve these
Leave these tools on "ask every time" in your client:
| Tool | Why |
|---|---|
publish_build | Replaces what visitors see on the live site. |
publish_post | Puts a post live and can email every subscriber on its list. Re-publishing re-sends. |
unpublish_post | Takes a live post off the site. |
delete_post | Deletes a post permanently. |
delete_project | Deletes the project and takes its site offline. Cannot be undone. |
Also read upsert_post calls before approving them when the post is already published: saving a published post changes the live page at once.
Read-only tools are safe to auto-approve. save_page never changes the live site, but it overwrites the project's active draft, including one you were editing in the web app. upload_asset replaces a stored file when the same filename is uploaded with different content.
Confirm arguments are friction, not a boundary
Outward tools also require a confirmation argument, checked by the server before any network call:
publish_build,unpublish_post,delete_post:confirm: truedelete_project:confirm_domainset to the project's micropage domainpublish_post: theconfirmation_tokenfrompreview_post_send, which is bound to the post as it was previewed and goes stale after any edit or after 15 minutesupsert_poston an already-published post:confirm_live_update: true
These force the assistant to make a deliberate second call, and the tool descriptions tell it to ask you first. They do not stop an assistant that decides to pass them anyway: the model can supply every one of these values itself. Rely on the approval prompt and the switches, not on these arguments.
Some clients also show a confirmation dialog from the server itself (MCP elicitation) before publish_post sends email and before delete_project. Declining aborts the call. Clients without elicitation support skip the dialog.
Form submissions are untrusted
Submissions are personal data written by strangers, and they can contain text aimed at the assistant ("ignore your instructions and..."). With MICROPAGE_MCP_SUBMISSIONS=1, list_submissions returns values only in a fenced block labelled as untrusted data, never in structured output, and the review_submissions prompt tells the assistant not to act on instructions found inside. Treat that as mitigation, not a guarantee: only turn submissions on when you need them.
Plan gate
The Pro check runs inside the MCP server, the same way the CLI does it. It is a product gate, not a security control. The platform's own plan limits, such as storage quota and project count, apply regardless.