An MCP server, so a coding agent connects with typed tools instead of shelling out to the CLI

#345 and #169 make an instance drivable by a CLI, and #345 argues correctly that declarative apply and plan are what make it safe for an agent. Both are the right thing.

Neither is how a coding agent actually connects. Claude Code, and every other agent worth supporting, connects over MCP. A CLI means the agent shells out, parses text, and guesses what commands exist. An MCP server means it is handed a typed tool list with schemas and can be refused properly.

## What to expose

Tools generated from what the instance already declares, not a hand-written list:

- The content surface: list types, read a type's schema, query entries, create, update, transition.
- The meta surface: which modules are loaded, which field types are valid, which capabilities exist.

`FieldTypeRegistry` is already the single source of accepted types, `/api/meta` already exists, and `ContentTypeDefinition` already carries the field shapes. So a tool schema is generated from the same place the API validates against, which is what stops the agent's mental model drifting from the server's.

## The part that matters more than the tools

**Authorisation is the existing one, not a new one.** An MCP session authenticates with an API key and gets exactly what that key gets. `ApiKeyScopeProcessor` already confines a key to the content and content-type surfaces and denies everything else outright, which is the property that makes handing one to an agent reasonable in the first place.

There must not be an agent permission model. A second model is a second place to get it wrong, and the whole point of this codebase's approach is that the refusal happens in one place.

**Writes are gated the way the CLI gates them.** #345's argument holds here and is stronger: an agent that can apply without a plan is an agent that can drop a content type at 2am. A write tool should either return a plan for confirmation or be off unless explicitly enabled.

## Relationship to the CLI

Not a replacement. The CLI is for humans, pipelines and promotion between environments, and #345's config-as-code argument stands on its own. This is the agent transport. They should share the same underlying operations so the two cannot disagree.

## Prior discussion

barakoBrew#16 covers a Modules and Agents screen and notes MCP against roadmap 3.26.0, with tools generated from the content schema and routed through existing RBAC. That issue is a design discussion. This is the server itself.

## Done when

- An agent can connect, list tools, read a content type's schema and query entries.
- The tool list is generated from the registry and the definitions, with a test that fails if a new field type does not appear.
- A key without a scope is refused by the existing processor, proven by a test.
- Writes require an explicit opt-in.

Start by tracing the existing /api/meta path, FieldTypeRegistry, ContentTypeDefinition, and ApiKeyScopeProcessor to understand how schemas, capabilities, and key scopes are exposed. Compare the shared operations with the CLI work in #345 and #169 before choosing the MCP server entry point. Done means the listed tools, schema-generation coverage, scope refusal, and explicit write opt-in tests all pass.

Written by the indexing model from the issue text.