Apograph can act as a Model Context Protocol server, so an external agent — Claude, an editor extension, your own agent — can do content work against it with an API token.
POST /api/v1/mcp
Authorization: Bearer apograph_…This points the opposite way from the copilot: the copilot is an assistant inside the product, and MCP is the product exposed as tools to something outside it.
Turning it on
Off by default. Once on, any holder of a full-scope API token can drive
content CRUD from an external agent, so it is an explicit decision.
MCP_ENABLED=trueNothing else changes. Tokens, scopes and workspace buckets are exactly as they were — this only controls whether the front door is mounted.
Connecting
Mint a token in the admin’s API Tokens page and point your agent at the
endpoint. read scope for a retrieval-only agent, full for one that authors.
The same X-Workspace-Id rules apply as everywhere else on /api/v1: optional
when the token covers one workspace, required when it covers several. See API
tokens.
The tools
Sixteen tools, flat, whatever your content model — with typeName as an
argument rather than a generated set per content type.
That is a deliberate choice: an MCP client loads every tool schema into the
model’s context on connect, so article_create, author_create, tag_create
and so on would scale the prompt cost with the size of your content model.
| Tool | Does |
|---|---|
content_types_list, content_type_get | Discover the model |
content_list, content_get | Read entries |
content_relations, content_media, content_translations | Read an entry’s links, assets and siblings |
content_create, content_update | Write |
content_publish, content_unpublish | Publish state |
content_delete | Delete |
content_bulk_save, content_bulk_publish, content_bulk_unpublish, content_bulk_delete | Batch operations |
An MCP agent can publish and delete; the copilot cannot
This is the sharpest difference between the two surfaces, and it is easy to miss.
The in-product copilot has no publish tool at any role, because a human presses publish. The MCP surface does expose publish, unpublish, delete and their bulk forms — because there the caller is a credential an operator minted deliberately, holding whatever the token’s scope grants, with no interactive user to prompt.
A full token handed to an external agent is a credential that can publish and
delete content across every workspace in its bucket. Mint narrowly, and prefer
read unless authoring is the point.
The protocol package owns nothing else
The MCP plugin owns the protocol and nothing more: the endpoint, bearer authentication, workspace resolution, JSON-RPC dispatch. It contains no content knowledge at all.
The registry lives in the tools package, and the tools themselves live in content — which is what lets a handler call the public-API query directly instead of re-implementing the rules it enforces. A tool call over MCP goes through the same visibility rules, the same validation, the same revision numbering and the same audit trail as the equivalent REST call.
Adding media or user tools later is a provider in that plugin and no change to the MCP package.
Surfaces
A tool declares which surfaces it is offered to. The admin_* tools the copilot
uses are copilot-only and are not on this endpoint.
Omitting the declaration means both, so a tool added carelessly is reachable here. See tools and permissions.
What this is not
Apograph is an MCP server, not an MCP client
This endpoint lets an agent call into Apograph. It does not let the copilot call out to your systems — the copilot being an MCP client of an operator’s own tools is a separate, planned thing that does not exist.
They are opposite directions and different features, and the shared acronym makes them easy to confuse.