MCP: add tools to create and instantiate visual components

[borskyj-symph]

Summary

The Site MCP tool surface can read visual components but cannot create them. site_list_documents returns visualComponent documents alongside pages and templates, and both site_read_document and site_open_document accept {type: "visualComponent", id} — but there is no site_add_component, and no "convert this subtree into a component" equivalent. An agent can edit the inside of a component a human already made, and nothing else.

Current tool surface

Document type	Create	Read/edit	Rename	Delete	Instantiate
Page	site_add_page, site_duplicate_page	yes	site_rename_page	site_delete_page	n/a
Template	site_set_page_template (page → template)	yes	—	—	target matching
Visual component	nothing	yes	—	—	nothing

Repro

1. Connect the Site MCP server with the editor open.
2. Ask the agent to "create a Feature Card component and use it three times on /o-nas".
3. site_list_documents shows the existing visualComponent entries, so the concept is clearly modelled — but no tool produces a new one.
4. The best the agent can do is site_insert_html the same markup three times, producing duplicated, unlinked subtrees.

Observed on the Symphera workspace, where site_list_documents returns 6 visualComponent docs (Hero Carousel, Book a Call, Course Card, Service Block, Training Card, Speaker Card) — all authored by hand in the UI. On a fresh site the Explorer shows Components — None yet, and an agent has no way to change that.

Related gap: no instance insertion

Even for components that already exist, site_insert_html has importer markers for <instatic-loop> and <instatic-outlet> but no marker for a component instance. So there is no documented way to place an instance of an existing component onto a page via MCP. This makes the read-only component access largely academic — an agent can inspect components but cannot place one.

Impact

Any agent-driven page build degrades to copy-pasted HTML. Repeated UI (cards, CTA blocks, feature tiles) ends up as N independent subtrees, which:

• defeats the component model the editor is built around,
• turns later edits into an N-place find-and-replace,
• silently diverges from the components a designer already defined in the same workspace.

Proposed API

1. site_add_component({ title }) → creates an empty visualComponent, returns { componentId, rootNodeId } so the agent can build into it with site_insert_html. Mirrors the existing site_add_page contract.
2. site_create_component_from_node({ nodeId, title }) → converts a subtree into a component, replacing the source node with an instance. The higher-value one, since it matches how components actually get made in the UI.
3. An instance marker for site_insert_html, e.g. <instatic-component data-component-id="…">, consistent with the existing <instatic-loop> / <instatic-outlet> markers.
4. Round out the lifecycle: site_rename_document / site_delete_document accepting the same {type, id} union as site_open_document, rather than the page-only site_rename_page / site_delete_page. Separable from 1–3 if you'd rather split it.

Notes

• Items 1–3 need the editor open, same constraint as the other write tools — expected.
• If component creation is intentionally UI-only, the tool descriptions should say so. Right now nothing in the MCP surface signals it, so agents plan around a capability that doesn't exist and burn a turn discovering otherwise. That doc fix is the minimum useful outcome here.