How an MCP-connected CMS can support an AI-built website

What MCP connects

The Model Context Protocol provides a standard way for AI applications to connect to tools and data. In a CMS integration, a tool might create a draft, a resource might describe a content schema, and a prompt might help the agent follow a site-setup workflow. The protocol does not replace the CMS’s permissions or publication rules.

Think of MCP as the connection used by the agent, and a delivery API as the connection used by the finished website. The website should not need an AI session to serve a page. It should read published content through a normal API or SDK.

Start with discovery, not generated content

Before the agent writes anything, it should discover the sites and datasets it can access, the active schemas, and the capabilities its authorization grants. For an existing site, that avoids creating a second article type or an incompatible page model.

For a new site, the agent can propose a small schema set based on the brief. A portfolio might need projects, profile information, and pages. An editorial website might need articles, authors, and categories. The proposal should show the fields, required values, references, and section types before it changes the active schema.

A page setup workflow worth testing

A useful workflow takes a website brief all the way to a rendered draft. Each step should return an inspectable result. A page-creation tool that reports only “done” leaves the agent guessing about document IDs, validation errors, and what the frontend needs next.

• Discover the target site, its schema versions, and allowed operations.
• Propose page and section schemas, then validate compatibility.
• Create page drafts and upload verified assets.
• Return the content manifest, site IDs, and integration instructions.
• Build frontend components for the declared section identifiers.
• Preview the website, review the content, and publish through a separate authorized operation.

Keep the frontend boundary explicit

Suppose the CMS stores a page with hero, feature list, and text sections. Each section includes a component identifier and content fields. The agent creates matching frontend components in the website repository. Changing the hero heading is a content edit; changing its animation or grid layout is a frontend change.

This boundary means the CMS does not execute React code supplied by an agent. It also makes it possible for a human editor to update the website without rerunning the code-generation process. The generated frontend must handle unknown section types and missing optional fields in a predictable way.

Design for permission changes and interrupted work

A site-setup operation can fail halfway through. The schema may be active while an image upload is incomplete. Return a setup ID and checkpoints so the agent can resume the work. Idempotency keys help retries avoid creating the same page twice. Version preconditions prevent stale edits from overwriting someone else’s work.

Give an agent only the sites and capabilities it needs. Draft editing and publication should be separate permissions. Removing a user’s site membership should stop further access, even if their previously issued token has not expired. Content read from a document is input data, not an instruction that can expand these permissions.

The Blockquote direction

Blockquote’s planned MCP interface covers schema discovery, declarative schema setup, page creation, localization, and explicit publication. External agents are the main AI workflow. Optional built-in assistance will help with drafts and translations. Public access is coming soon, so these steps describe the intended workflow.