[Docs/Feature]: MCP connectors imply autonomous site editing, but write tools require a live browser editor

Summary

The MCP connector feature currently gives the impression that an external AI client can connect to Instatic and use the CMS tool surface to edit a site autonomously/headlessly.

In practice, most Site editing tools (site_insert_html, site_replace_node_html, site_apply_css, etc.) require the connector owner's live, authenticated Site editor browser session to be open. Without that browser bridge, the external MCP client can perform some headless reads and site_publish, but cannot actually make the site changes that would normally precede publishing.

This is architecturally intentional and documented in the internal/technical docs, but it is not obvious from the MCP Connections UI or from the higher-level description of MCP connectors.

Why this matters

A common reason to configure an external MCP client is unattended automation, for example:

• AI agent maintains a website on a self-hosted Instatic instance
• agent edits HTML/CSS/content through MCP
• agent publishes after validation
• no human browser session needs to remain open

That workflow currently does not work. A browser session must remain open, logged in as the connector owner, and have the relevant Site/Content workspace active.

This is a significant operational difference between:

external AI clients can use the CMS tool surface

and:

external AI clients can use browser-backed editing tools while the owner's editor session is open

Reproduction

Tested with Instatic 0.0.14 in Docker and an external MCP client.

1. Create an MCP Connection and connect an external AI agent.
2. Confirm headless tools such as get_context / site_list_documents work.
3. Close the Instatic Site editor or do not keep an authenticated Site editor workspace open.
4. Call site_read_document, site_insert_html, or another browser-routed Site tool.
5. The call fails with a message indicating that the Site editor must be open in a browser as the connector owner.
6. Open the Site editor while authenticated as the connector owner.
7. The same browser-routed tools can then execute.

Expected / suggestions

One of these would make the behavior much clearer:

1. Documentation/UI: explicitly state in MCP Connections that Site/Content mutation tools require a live browser workspace owned by the connector user, and that MCP is not currently a fully headless editing API.

and/or

1. Feature: provide a true server-side/headless editing path for MCP connectors, with appropriate locking/versioning/draft semantics so it cannot desynchronize the editor state.

If true headless mutation is intentionally out of scope because the browser store must remain authoritative, making that limitation prominent in the MCP UI/docs would still prevent users from designing unattended automation around a capability that is not actually available.

Additional context

The technical documentation already explains the design well: headless reads and site_publish run server-side, while browser tools route through the connector owner's open Site or Content workspace. The issue is mainly that this constraint is not apparent when discovering/configuring MCP from the product surface.