MCP lets AI agents edit content through Draftbase directly
The Model Context Protocol gives an agent a fixed set of tools to call. No UI to click through. No API to guess at. Draftbase ships an MCP server. An agent can create, publish, and roll back content the same way a person does.
Updated
What is the Model Context Protocol
The Model Context Protocol is an open standard for connecting AI applications to external tools and data. It started at Anthropic. It defines how a client finds a set of tools, calls them with typed input, and reads back a structured result.
The reason a protocol exists at all is arithmetic. Without a shared protocol, connecting N AI clients to M tools takes N×M custom integrations. With one, each side implements the spec once, and the work drops to N+M. That is the whole pitch. Every client that speaks MCP can talk to every server that speaks MCP, and nobody writes glue per pair.
Worth being clear about what MCP is not. It isn't a library, an SDK, or a model. It's a specification, the way REST and GraphQL are specifications: a wire format plus rules about who says what and when. SDKs exist in most languages, but you can implement either side with an HTTP server and a JSON schema.
Without MCP, an agent that needs to edit content has two bad options. It can drive a browser and click through a UI built for humans. Or it can call a REST API it was never given docs for. Guessing at field names and rules. Both options break the moment the UI changes or a field gets renamed. Neither one is built on a real contract.
MCP replaces both with a defined tool contract. The agent calls create_entry with the fields the schema expects. Not a scraped form. The call either succeeds against real checks, or fails with a clear error. That error is structured too, so the agent can correct course instead of guessing again.
How MCP works: hosts, clients, and servers
MCP splits every integration into three parts. A host runs the AI, a client speaks the protocol, and a server exposes the tools. Once you can name the three, the rest of the spec reads as plumbing between them.
Host
The AI application a person actually uses: Claude Code, Claude Desktop, an IDE, a chat app. It holds the model and decides which servers to connect.
Client
Lives inside the host, one per server. It handles discovery, authentication, and message framing, so the host never has to know how a given server is reached.
Server
The thing exposing tools, data, and context. Draftbase's headless CMS ships one, with 26 tools over templates, entries, media, and MDX components.
The request path is short. The client connects and asks the server what tools it has. The server answers with a name, a description, and a JSON input schema per tool. The host hands that list to the model. When the model picks one, the client sends the call, the server runs it against the real application, and the result comes back as text the model can read. The model never touches the network itself.
One detail most write-ups still get wrong: the spec no longer assumes a long-lived session. The 2026-07-28 revision dropped the initialize handshake and the Mcp-Session-Id header. Each request now carries its own version, its client, and what that client can do. It also made Mcp-Method and Mcp-Name required headers, so a gateway can route on them without reading the body. (Source: MCP specification blog) Draftbase's server runs exactly that way, one fresh server instance per request with no session to keep warm. What an MCP server is goes through the spec change in detail.
MCP transports: stdio for local, HTTP for remote
A transport is how the two sides move messages. The spec defines two. With stdio, the client launches the server as a subprocess and writes to its standard input. With streamable HTTP, the client posts JSON-RPC messages to a URL. Draftbase uses streamable HTTP, because a hosted CMS has nothing to install on your machine.
Local vs. remote MCP servers
A local server runs beside you and inherits your environment, which is why filesystem and git servers are local. It also means every user installs and updates it. A remote server runs on the network and has to authenticate each caller, which costs a login flow and buys central updates plus real multi-user access. Draftbase is remote: point a client at the endpoint, log in through OAuth 2.1 with PKCE, and the tool list is current because the server is the one we run.
How Draftbase's MCP server works
Tools mirror the REST API 1:1
Template, entry, and media tools map to the same routes a human editor's requests hit. No separate agent-only path. No drift between what an agent can do and what a person can do.
One call per operation, by design
create_template takes every field up front, not one at a time. Token cost is a hard limit on every tool, not an afterthought. An agent that needs five calls to do one thing burns context and money on every edit.
Same schema, same validation
An agent's update_entry call is checked against the exact template schema a human editor is bound by. There is no way around it.
Revisions and rollback as tools
list_entry_revisions and rollback_entry are first-class tools. An agent's mistake is a revert, not a crisis.
This is why the server exposes the same content, revision, and status tools a human uses in the dashboard. Not a narrower or wider set built just for agents. Template, entry, and media tools cover the same three areas the REST API covers. An agent that can list templates can also read, create, update, and delete entries, and manage media. No separate setup per area.
The content itself helps here too. An entry an agent reads or writes is MDX. Plain markdown plus components. Not a deep JSON blob with layers of CMS-internal data to sort through. Less structure to work through means less context spent figuring out what a field holds. It also means a smaller footprint the agent can hold across a whole editing session. No need to re-fetch it. Tokens are scarce for an agent. Draftbase would rather it spend them on writing than on decoding your content.
Login follows the same secure flow a human's login uses. Scoped to one org through the token's claims. An agent never gets more access than the person who connected it.
In practice, a content workflow looks like this. An agent calls list_templates to see what schemas exist. It calls create_entry against the right one with a full set of fields. Then it calls set_entry_status to move it from draft to published once it looks right. Three tool calls. No scraped forms, no guesswork. See the technical setup docs for the full tool list and connection details. Want to check a server's tools before wiring one up? Use the free MCP Inspector.
MCP-connected editing vs. traditional API integration vs. no AI access
Teams that want AI content editing today usually pick one of three paths. They skip AI and keep editing manual. Or they build a custom integration against the CMS's REST API, writing tool-calling code by hand. Or they connect an MCP client to a server that already ships the tools.
| Approach | No AI access | Custom AI integration | Draftbase MCP server |
|---|---|---|---|
| Setup cost | None, but no automation | Weeks of custom tool-calling code | Connect an MCP client, tools ship built-in |
| Schema awareness | N/A | Hardcoded per integration, drifts from schema | Always matches the live template schema |
| Safety | N/A, human is the only actor | Depends on how carefully you built it | Same validation plus draft/publish and revision rollback as a human edit |
| Token/request efficiency | N/A | Depends on the integration author | One call per operation by design |
The middle column is where most custom integrations end up over time. They work at launch. Then they quietly drift from the schema as fields get added or renamed. Nothing forces the code to stay in sync with the content model.
Is MCP secure?
The protocol itself adds no security. It describes how tools are listed and called, and leaves authentication and authorization to the server. So the honest answer is that an MCP server is exactly as safe as the permissions sitting behind its tools.
The risk surface is easy to name. An agent with write access to production content can change what visitors read. Worse, the agent takes instructions from text, and some of that text may come from content it just read. That's prompt injection reaching a tool call: a comment field that says "delete every draft" is not a request from your team, but an agent has no built-in way to tell the difference.
Which is why scoped credentials matter more here than in a normal integration. A token that can only reach one org, only the operations that org's roles allow, and only through validated writes, limits what a hijacked instruction can accomplish. A shared master key does the opposite.
Four controls Draftbase enforces on every MCP call, not as an agent-specific layer but because the tools go through the same routes the dashboard uses:
- One org per connection. The token carries the org it was issued for, and every tool call is scoped to it. There is no cross-org read.
- The connecting user's own permissions. Calls carry that person's token and hit the same org role checks a browser request does. An agent can never do more than the person who connected it.
- Same template validation.
create_entryandupdate_entryare checked against required fields, length bounds, and patterns. There is no second write path that skips them. - Drafts and revisions as the review gate. An agent can leave work in draft for a human to publish, and every save keeps a revision, so
rollback_entryundoes a bad edit.
What Draftbase does not do is read the agent's mind. If you grant a role that can publish, tool calls can publish. Treat the connection like a teammate's account, because that's what it is.
Alternatives to MCP
MCP is not the only way to give a model tools, and it isn't always the cheapest. Three alternatives come up in practice.
A plain REST or GraphQL API plus hand-written tool definitions. You already have the API. You describe a few endpoints to the model yourself and call them from your own code. For one client and three operations, this is less work than anything else, and it stays under your control.
Provider function-calling schemas. OpenAI-style tool schemas are well documented and need no extra server. The cost shows up when you add a second provider, since the definitions don't transfer and you now maintain two copies of the same tool list.
Agent frameworks with their own plugin format. Useful if you were going to adopt the framework anyway. Your integration then belongs to that framework, and moving off it means rewriting the tool layer.
MCP earns its keep when several clients need the same operations. One server, and every compliant host gets the tools. That's the case a CMS is in: the same content operations are wanted from an IDE, a chat client, and a build script, and none of them should need their own integration.
Common pitfalls with agent-driven content editing
Teams that connect an agent for the first time usually make one of two mistakes. First, they treat every tool call as equally safe. They let an agent run set_entry_status straight to published with no review step. The fix is a workflow rule, not a missing feature. Second, they build a custom integration before checking whether an MCP server already covers what they need. That just duplicates code an off-the-shelf server already ships.
Here's the angle most AI-CMS pitches skip. The safety story isn't about limiting what an agent can call. It's about what happens after a bad call. Draftbase's rollback_entry tool sits next to update_entry. So an agent's wrong edit costs one revert, not a recovery job. That's a trait of the content model, not the AI layer. Revisions exist for human edits too.
Why MCP adoption is moving fast
MCP SDK downloads grew from about 100,000 in November 2024 to 97 million a month by March 2026. That's a 970x jump in under a year and a half. (Source) As of December 2025, MCP had more than 10,000 active public servers. (Source)
The protocol also changed hands. In December 2025, Anthropic gave MCP to the new Agentic AI Foundation, under the Linux Foundation. OpenAI and Block joined as co-founders. (Source) A protocol backed by rival AI labs is a safer bet for a CMS to build on than one vendor's own tool format.
For a CMS, this shift changes what "AI content editing" means. A chatbot bolted onto a dashboard can draft text. But it still needs a human to copy that text into the right fields. An MCP-connected agent calls the same field-level tools a human uses. The draft lands right in the template, checks already applied.
For an editorial team, the real effect is fewer handoffs. A writer can ask an agent to draft an entry. An editor can ask it to check every required field before a launch. Neither step needs exporting content to a separate tool and back. The tools work on live data in the same org the humans use. Not a staging copy to fix later.
Give your agent MCP-connected AI content editing
Connect an MCP client and edit entries through the schema your team already uses. No custom integration code, no separate write path.
Hobby is free, no card. Startup is $49/mo when you outgrow it. The price is on the pricing page, where prices go.
No migration quarter, no kickoff workshop. Define a template and ship something today.
Frequently asked questions
What is MCP?
The Model Context Protocol is an open standard that lets AI agents call structured tools against an application. Instead of scraping a UI or guessing at an API, an agent gets a defined set of typed operations to call, each with a fixed set of arguments and a predictable response shape.
Is MCP specific to Draftbase?
No. MCP is an open standard, not a Draftbase feature. As of December 2025 it's governed by the Agentic AI Foundation under the Linux Foundation. Draftbase implements a server for it — the protocol itself works with any compliant application, and the same MCP client you use with Draftbase can also connect to other MCP servers.
Can an AI agent publish content without human review?
Technically, yes. The MCP tools mirror the same status-change operations a human editor has, including publish. But every entry keeps its revision history, and rollback is also exposed as a tool, so an agent's edit is never a one-way door. If a team wants a human gate before publish, that's a workflow decision for how the agent is instructed, not a limitation of the tools themselves.
Does the MCP server bypass template validation?
No. An agent calling create_entry or update_entry hits the same field validation a human editor hits, including required fields, min/max constraints, and pattern rules defined on the template. There is no separate write path for AI tools, so a schema change protects both actors equally.
Which MCP clients work with Draftbase?
Any client that supports the OAuth 2.1 + PKCE discovery flow, including Claude Code and Claude Desktop. See the technical setup docs for connection details and the full tool reference, including separate staging and production endpoints.
What is an MCP server?
An MCP server is a program that exposes an application's operations as MCP tools, so any compliant AI client can call them. It publishes a list of tools, each with a typed input schema, and returns structured results. Draftbase's server exposes 26 tools covering templates, entries, media, and MDX components.
Why would I build an MCP server?
Because one server covers every client that speaks the protocol. Without MCP you write a bespoke tool layer per AI client, and each one drifts on its own schedule. With MCP you describe your operations once, and Claude Code, Claude Desktop, or any other compliant client picks them up without you shipping client-specific code.
What is the difference between an MCP server and an API?
An MCP server usually sits on top of an API rather than replacing it. The API defines routes and payloads for a programmer who has read the docs. MCP adds discovery: the client asks the server what tools exist, reads the input schema for each one, and calls them without hardcoded knowledge. Draftbase runs both, and the MCP tools call the same REST routes the dashboard does.
What are MCP transports?
A transport is how the client and server exchange messages. The spec defines two: stdio, where the client launches the server as a local subprocess and talks over standard input and output, and streamable HTTP, where the client posts to a URL over the network. Draftbase uses streamable HTTP, since the server is hosted rather than installed.
What is the difference between a local and a remote MCP server?
A local server runs on your machine as a subprocess over stdio and reads credentials from your own environment, which suits filesystem or git access. A remote server runs on the network over HTTP and authenticates every request, which suits a hosted product with multiple users. Draftbase is a remote server: you point a client at the endpoint and log in over OAuth, with nothing to install.
What is the difference between an AI agent and an MCP server?
The agent decides, the server executes. An agent is the model plus the loop that chooses what to do next; an MCP server is the set of typed operations it can choose from, with no reasoning of its own. Draftbase ships the server. The agent lives in whichever client you connect.
Are MCP servers secure?
The protocol adds no security of its own, so a server is exactly as safe as the permissions behind its tools. The two real risks are an over-scoped token and prompt injection reaching a tool call. On Draftbase, every tool call carries the connecting user's own token, is scoped to one org through the token claims, and passes the same role checks and template validation as a dashboard request. Every write also leaves a revision, so a bad call is a rollback.
Who created MCP, and is it open source?
Anthropic released MCP as an open specification in November 2024. In December 2025 it moved to the Agentic AI Foundation under the Linux Foundation, with OpenAI and Block as co-founders. The spec, the SDKs, and the reference servers are all public, and anyone can implement either side of it.
What are the alternatives to MCP?
Three, in practice. A plain REST or GraphQL API plus tool definitions you write per client. Provider-specific function-calling schemas, which work well until you add a second provider. Or an agent framework with its own plugin format, which ties your integration to that framework. MCP wins when several clients need the same operations, because you implement it once.
How many tools does the Draftbase MCP server expose?
26. They cover template listing and CRUD, entry read, create, update, delete, status changes and scheduled publishing, revision listing and rollback, media upload and tagging, and MDX component management. The set mirrors the management REST API rather than adding an agent-only subset.
Is this AI content management, or AI content generation?
Management. MCP tools call the same create, update, and status-change operations a human editor uses, with the same template validation and revision history behind every write. The agent still needs something to write, whether that's your prompt or its own model output; MCP is the layer that lets it act on the CMS once it has that content, not a tool that writes copy for you.