/api/mcp/ that shares its services with the REST API and the Console. A coding agent connected to it can inspect health and failures, land and shape datasets, author evaluators and run evals, launch and follow training, schedule optimisation runs, and wire up connectors and instrumentation — everything except the steps that need your filesystem, which it hands to the CLI.
Setup
overmind init --ide <client> writes the entry and overmind sync fills in the key, which is what the Quickstart prompt does for you. The entry is an HTTP server with an X-Api-Key header:
http://localhost:8000/api/mcp/ (overmind init --env local). Codex takes the same entry in .codex/config.toml.
Authentication
The key must be project-scoped — pinned to exactly one active project — and carryread and/or write. The project is bound from the key; no tool accepts a project id. A key with only read sees the read-only tools; mutation tools need write. The server answers 401 without a WWW-Authenticate: Bearer challenge on purpose, so MCP clients never try OAuth registration against it; Authorization: Bearer ovr_… is still accepted as an API key.
The public surface is read and write only. There are no delete, cancel, retry-anything, or generic API tools; retry_deployment covers exactly the failed-or-deleted deployment case.
Tools
Thirty-two tools, all project-scoped, each with a strict input and output schema the client reads at call time. Every result carries the same object twice — structured content and compact JSON text — plus resource links for the entities it touched. Errors are values ({"error": {code, message, retryable, fields}}), never exceptions.
Background work returns a job receipt —
kind, id, status, and an overmind://jobs/{kind}/{id} resource — that get_job reads back. Kinds: dataset_run, eval_run, finetune_job, deployment, optimizer_experiment, and connector_sync.
Names resolve within the project: capability tools take a name, slug, or id; dataset tools prefer the UUID list_datasets returned because dataset names are not unique.
Prompts
Twelve prompts compose the tools into multi-step workflows with human checkpoints:Resources
Read-only, project-scoped entity state underovermind://:
project/current, capabilities/{capability}, traces/{trace_id}, sessions/{session}, datasets/{dataset}, eval-runs/{eval_run}, finetunes/{job_id}, deployments/{deployment}, optimizer-runs/{experiment}, connectors/{connector}, jobs/{kind}/{id} — plus four static handoff guides, dataset-upload, dataset-export, checkpoint-download, and connector-setup, that tell the agent exactly which CLI command to run.
The CLI boundary
Three things never cross MCP: file bytes, repository edits, and provider secrets. A dataset file goes up withovermind dataset upload; a dataset or checkpoint comes down with overmind dataset export and overmind model download-checkpoint; an optimisation run’s candidates are generated and replayed by overmind optimise in your checkout; a model swap is a prompt (get_model_swap_prompt) the agent applies with its own editing tools; a connector’s provider key goes in with overmind connector add, and inspect_connectors answers connector_setup_required with that command until it exists. The prompts above name the exact command at each handoff, and --json on the CLI returns the ids the agent needs to continue.
The skill
overmind init installs the overmind skill next to the MCP entry. It holds the conventions the tools assume — list first, poll jobs with get_job, the dataset contracts that gate every run — and one reference per workflow, which is what the /overmind commands load. The skill is the fallback for anything the native prompts do not cover, and the only place the local scan (/overmind setup) lives.