MCP server
cori mcp — serve check, run, show, runs, and status as MCP tools for agent clients, with human-in-the-loop consent.
cori mcp serves Cori over the Model Context Protocol
on stdio, so agent clients — Claude Desktop, Cowork, Claude Code, and any other
MCP client — can preflight, run, and inspect workflows through the same code paths
as the CLI verbs.
{
"mcpServers": {
"cori": {
"command": "cori",
"args": ["mcp"]
}
}
}Four different things are called “MCP” around Cori
Don't mix these up:
mcp_toolsteps — a workflow activity kind that calls a tool on an external MCP server at runtime.- The broker's MCP client — the Cori worker component that executes those steps.
~/.cori/mcp-servers.json— the worker's configuration listing external MCP servers thatmcp_toolsteps may call.cori mcp(this page) — Cori itself acting as an MCP server for your agent.
Do not add cori mcp to ~/.cori/mcp-servers.json — that file configures servers
Cori calls, not clients that call Cori. Register cori mcp in your agent's MCP
configuration instead (e.g. claude_desktop_config.json).
Tools
The tools are a strict subset of the CLI verbs — same arguments, same errors, same underlying code:
| Tool | CLI equivalent | Description |
|---|---|---|
check | cori check | Per-step readiness + capability auth status |
run | cori run | Execute a workflow, return the full run trace |
show | cori show | Manifest, steps, required capabilities |
runs_list | cori runs list | Recent run history |
runs_show | cori runs show | One run's persisted trace |
status | cori status | Endpoint, identity, capabilities, workers, and the capability registry (capability_registry: every Cori-blessed binary — installed or not — with a use_for line and the remedy command that makes it ready) |
There are deliberately no login, work, or config tools, and no
save_workflow tool. Machine-trust operations stay human-initiated, and credentials
never transit an MCP client. This is a fixed rule, not a missing feature.
Consent
MCP run has a stricter consent model than the CLI, because the caller is an agent
rather than a human:
CORI_ASSUME_YESis ignored. An MCP server inherits the environment it was launched with; honoring the variable would silently auto-approve agent-initiated runs.cori mcpstrips it at startup.- Every
runasks the human first — a per-run confirmation naming the workflow, source, and parameters. This applies to local paths and already-trusted remote refs too: once your agent client auto-approves Cori's tools, this confirmation is the only human left in the loop. The channel adapts to the client:- MCP elicitation, when the client declares the capability at initialize;
- otherwise a native dialog on the machine running
cori mcp(macOS dialog, Windows message box,zenityon Linux) — possible because local MCP servers run on the host, so the dialog reaches the same human who owns the machine; - if neither channel exists (headless, or
CORI_MCP_DISABLE_NATIVE_CONFIRM=1),runis refused with a pointer to the desktop app or the terminal.
- First-run trust consent for an untrusted remote ref is a second, richer
confirmation through the same channels, showing the ref, the exact commit, and the
capabilities the workflow declares — the same consent recorded by
cori runand the Cori desktop app, stored in the sametrust.json. check,show,runs_*, andstatuswork everywhere with no confirmation; on an untrusted remote ref,checkreportsconsent_requiredinstead of prompting.
A declined or unanswered confirmation (5-minute timeout) never runs anything, and
CORI_MCP_DISABLE_NATIVE_CONFIRM can only disable a confirmation channel — there
is no variable that approves one.
Progress, timeouts, cancellation
- If the client sends a
progressToken,runemitsnotifications/progress— a plan message, then one notification per completed step. (Step events are currently emitted when the workflow completes, mirroring the engine'sProgressSinkbehaviour; they become live when the engine does.) runblocks until the workflow finishes; the server imposes no timeout of its own. Configure client-side timeouts accordingly for long workflows.- A
notifications/cancelledfrom the client suppresses the response, but does not abort the workflow — the run completes on Temporal and its trace is persisted to~/.cori/runs/either way (inspect it withruns_list).
Trace sizes
Traces returned by run and runs_show elide any single activity output
larger than ~2 KB (workflows that shuttle row sets between steps produce
traces in the hundreds of kilobytes — far past tool-result limits). The
output_summary fields, statuses, durations, and costs are always intact,
and each elided output carries a note with the exact runs_show call to
fetch it. runs_show also accepts activity (one step's full output) and
full: true (everything inline). The trace persisted on disk is never
trimmed.
Prompts and resources
The server ships an embedded copy of the cori-save-workflow skill so any MCP
client receives the capture procedure without a separate skill install:
- Prompt
cori-save-workflow— the full skill body. - Resources
cori://skill/SKILL.mdplus the four references (activity_kinds,example_workflow,manifest_schema,trace_interpretation).
Each resource description is stamped with the cori version it was embedded in.
The npx skills add cori-do/cori copy may be newer; when in doubt, the installed
skill wins.

