AI · 2 / 23
Agents and MCP
Ortha CMS is an MCP server. An outside agent connects with an API token and works through the same permission-checked tools.
{ "typeName": "article",
"values": {
"title": "Oslo’s seed library turns ten",
"summary": "A drawer of envelopes, ten years on."
} } How it works
- 01
Create an API token for the agent, read-only or full access.
- 02
The agent calls tools at POST /api/v1/mcp over streamable HTTP.
- 03
An entry it creates lands as a draft in the Content Library.
- Endpoint
- POST /api/v1/mcp
- Auth
- Bearer API token
- Read-only token
- Never sees a write tool
In depth · For engineers connecting agents
Your CMS is an MCP server
Claude, Cursor or your own script connects to one endpoint with an API token and works with your content through the same tools as the built-in assistant.
One registry, two front doors
Outside agents and the in-product assistant call the same tool registry, which checks the caller’s permissions on every call. Ortha speaks MCP at POST /api/v1/mcp over stateless Streamable HTTP, and accepts bearer API tokens only.
An outside agent and the in-product assistant both arrive at one tool registry, which checks permissions before dispatching to the services behind it.
The token decides what the agent can do
Tokens are scoped read or full and granted to specific workspaces. A read-scoped token is never offered a write tool, and a refusal names the missing permission so the agent can explain it.
Twenty-six tools
Show the table
| Tool group | What it covers |
|---|---|
| Schema | List and read content types. |
| Reads | Published entries, with search, filter and sort. |
| Writes | Create, update, delete; a create yields a draft. |
| Publish lifecycle | Publish and unpublish, with separate permissions. |
| Batches | Bulk save, publish, unpublish and delete. |
| Media, read-only | Find and read assets; no uploads. |
| Review | Review status, diffs and requests; no approve tool. |
| Segments | Who may read an entry. |
Connecting a client
- Turn the endpoint on — it is off unless you set MCP_ENABLED
- Mint a token on the API Tokens page, read or full
- Grant it the workspaces it may reach
- Point the client at /api/v1/mcp with the token as a bearer header
- Name the workspace by header or query string
Questions
Does the agent see drafts?
Not by default: it reads published entries only. A full-access token can ask for drafts; a read-only token never can.
What stops a prompt injection in an entry body?
The agent holds exactly the token’s permissions, so the worst an injection achieves is something the token could already do.
Do I need to write an MCP server?
No. This is the server; point any MCP client at it. Clients that only speak stdio can use mcp-remote.