Cori
Reference

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:

  1. mcp_tool steps — a workflow activity kind that calls a tool on an external MCP server at runtime.
  2. The broker's MCP client — the Cori worker component that executes those steps.
  3. ~/.cori/mcp-servers.json — the worker's configuration listing external MCP servers that mcp_tool steps may call.
  4. 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:

ToolCLI equivalentDescription
checkcori checkPer-step readiness + capability auth status
runcori runExecute a workflow, return the full run trace
showcori showManifest, steps, required capabilities
runs_listcori runs listRecent run history
runs_showcori runs showOne run's persisted trace
statuscori statusEndpoint, 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.

MCP run has a stricter consent model than the CLI, because the caller is an agent rather than a human:

  • CORI_ASSUME_YES is ignored. An MCP server inherits the environment it was launched with; honoring the variable would silently auto-approve agent-initiated runs. cori mcp strips it at startup.
  • Every run asks 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:
    1. MCP elicitation, when the client declares the capability at initialize;
    2. otherwise a native dialog on the machine running cori mcp (macOS dialog, Windows message box, zenity on Linux) — possible because local MCP servers run on the host, so the dialog reaches the same human who owns the machine;
    3. if neither channel exists (headless, or CORI_MCP_DISABLE_NATIVE_CONFIRM=1), run is 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 run and the Cori desktop app, stored in the same trust.json.
  • check, show, runs_*, and status work everywhere with no confirmation; on an untrusted remote ref, check reports consent_required instead 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, run emits notifications/progress — a plan message, then one notification per completed step. (Step events are currently emitted when the workflow completes, mirroring the engine's ProgressSink behaviour; they become live when the engine does.)
  • run blocks until the workflow finishes; the server imposes no timeout of its own. Configure client-side timeouts accordingly for long workflows.
  • A notifications/cancelled from 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 with runs_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.md plus 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.

On this page