Mission exposes a daemon-owned MCP server named open-mission-mcp as the preferred structured transport for Agent-authored messages from running Agent executions.

The MCP server starts and stops with the daemon. It is connected directly to daemon services and does not own Mission, Task, Repository, Artifact, AgentExecution, workflow, or state-store behavior. Its role is to accept MCP tool calls from an Agent execution process, validate them against the Agent execution message registry, and route accepted calls into the owning AgentExecution instance through the same observation path used by prompt-scoped stdout markers.

This keeps the architecture provider-neutral while making terminal and interactive Agent runtimes able to communicate with their owning Entity through structured tools. Stdout markers remain the declared baseline transport for Agent runtimes that do not support MCP.

Context

ADR 0004.04 established prompt-scoped stdout markers as the mandatory baseline for Agent execution message intake. That baseline works for print-mode runtimes because the daemon can prepend strict message instructions and parse the resulting stdout stream. It does not give terminal or interactive runtimes an equally reliable structured channel because terminal output is mixed with UI text, provider rendering, prompts, commands, and user interaction.

ADR 0004.05 defines Agent execution structured interaction as an owner-Entity-addressed conversation. The source of truth is the Agent execution message registry, which includes incoming and outgoing Agent execution message descriptors. Agent-authored messages remain observations until daemon-owned policy and the owning Entity path accept their effects.

MCP gives capable Agent runtimes a standard way to discover and call tools without relying on terminal text conventions. Mission should use that standard as a transport, not as a new domain model.

Decision

The daemon owns one local Mission MCP server named open-mission-mcp. The server lifecycle is daemon lifecycle: it is started as part of daemon startup, stopped during daemon shutdown, and treated as unavailable when the daemon is unavailable.

open-mission-mcp exposes Agent-authored message payloads as MCP tools for each registered Agent execution. The exposed tool set is dynamic and session-scoped: it is derived from the Agent execution message registry, the selected Agent adapter, the launch capabilities, and the owning Entity scope. There is no single global Mission MCP tool contract that every Agent execution must receive.

The baseline tool presentation may correspond one-to-one with the baseline message types:

  • progress
  • needs_input
  • blocked
  • ready_for_verification
  • completed_claim
  • failed_claim
  • message

The MCP tool payload schemas are generated from or directly backed by the canonical Agent execution message schemas. The implementation must not copy payload shapes, validation limits, policy rules, outcome mapping, or owner-routing logic into MCP-specific code. If later owner-specific message variants make one-tool-per-message too broad, open-mission-mcp may expose a smaller generic tool shape such as emit_message that accepts a descriptor-backed message type and payload. That would be a transport presentation change, not a new domain path.

An MCP tool call produces the same daemon-side observation and the same accepted Entity event path as the corresponding stdout marker message. The transport may differ, but the domain route is still:

Agent execution process structured message
  -> Agent execution observation
  -> AgentExecution observation policy
  -> AgentExecution log record
  -> owning Entity behavior
  -> AgentExecution state, Entity event, workflow event, or rejection

The MCP transport is preferred for Agent adapters that can receive MCP configuration. Stdout markers remain a supported declared transport for Agent adapters or Agent runtimes that cannot support MCP. The selected transport must be explicit in AgentExecution transport state so Open Mission and logs can distinguish MCP-backed structured message intake from marker-backed message intake.

MCP tools are not stable public APIs for external automation. They are execution-scoped transport affordances provisioned for a running Agent execution. Adapter provisioning negotiates or materializes the available tools for that execution, and Mission may evolve tool names, grouping, and transport presentation as long as the canonical message descriptors and owner-routing semantics remain coherent.

Ownership

open-mission-mcp is a daemon runtime adapter into Agent execution observation routing. It validates and translates transport calls, but it does not decide workflow legality or mutate owner state directly.

AgentExecution remains the single execution model and the owner of the Agent execution process. The MCP server routes through AgentExecution instances and their owner references. Scope remains data on AgentExecution, and owning Entity resolution remains derived from AgentExecution owner data rather than MCP-authored input.

Owning Entities receive the same accepted result they would receive from stdout marker observation. A task-scoped completed_claim called through MCP is still a claim for the Task-owning path to evaluate; it is not direct task completion. A needs_input tool call still becomes an input request observation and owner-visible event according to policy; it is not a direct surface command.

Tool Contract

The tool contract is message-registry-driven. The Agent execution message registry must be able to describe each delivery option without forking the message definition. If the implementation extends delivery modeling, it should model MCP as another delivery capability for the same descriptor, such as mcp-tool, rather than creating separate MCP-only message descriptors.

Each tool call must carry or be bound to:

  • the Agent execution id
  • a fresh event id for idempotency
  • the message payload
  • session authorization or an equivalent daemon-issued capability

Owner identity is not trusted from Agent-authored input. Mission, Task, Repository, Artifact, and System ownership are resolved by the daemon from the registered AgentExecution scope. Calls for unknown executions, mismatched execution identity, stopped executions, duplicate event ids, invalid payloads, oversized payloads, unsupported message types, or unauthorized sessions are rejected or recorded as diagnostics according to the same policy discipline used for stdout marker parsing.

Agent execution observations are append-only and idempotent. Every accepted transport input becomes, at most once, a normalized observation for its Agent execution and event id in AgentExecution logs. Retries, reconnects, crashed Agent processes, MCP resend behavior, duplicated stdout markers, and adapter replay must not create repeated workflow effects, repeated owner Entity events, or repeated AgentExecution state transitions for the same event id. Duplicate detection belongs before policy effects are applied, and the acknowledgement for a duplicate must describe replay handling rather than pretending a new observation was accepted.

MCP acknowledgements are delivery feedback. They may report accepted, rejected, recorded-only, or policy-promoted outcomes, but they are not proof of workflow completion, verification success, or operator approval.

Adapter Provisioning

Agent adapters are responsible for translating Mission’s MCP access contract into each Agent runtime’s configuration mechanism. The shared contract is MCP availability and the open-mission-mcp server name; client configuration files and commands are adapter concerns.

Mission must not assume that every Agent runtime consumes one universal MCP config file. Claude Code, Copilot CLI, OpenCode, Codex, and future adapters may require different registration paths. Adapter-specific MCP setup belongs behind Agent adapter or Agent launch provisioning boundaries, not in Entity behavior, workflow logic, Open Mission surfaces, or the MCP tool handlers.

Generated per-execution configuration must be ephemeral or untracked when it contains session identity, capabilities, or credentials. Static repository configuration may reference open-mission-mcp only if live secrets stay outside tracked files.

If an adapter declares MCP for a launch mode, provisioning failure must fail launch explicitly. Mission must not silently degrade an MCP-declared launch into stdout markers. Agent runtimes that cannot support MCP must declare stdout-marker delivery before launch.

Security And Locality

open-mission-mcp is local to the daemon runtime. It must not expose a remote unauthenticated Mission mutation endpoint. Any network transport must be loopback-only or otherwise protected by daemon-issued session capabilities. Stdio bridge processes are acceptable when an Agent runtime requires stdio MCP, but they are bridges to the daemon-owned server contract, not independent Mission authorities.

Tool exposure is least-privilege and session-scoped. An Agent execution sees only the tools allowed by its current message registry and launch capability. MCP must not become a general Entity command surface, repository filesystem API, or workflow mutation API unless a future ADR explicitly expands the contract.

Consequences

  • Mission becomes MCP-first for capable Agent runtimes while preserving stdout markers as the universal declared baseline transport.
  • MCP tool exposure is dynamically materialized per Agent execution, not a static public API surface.
  • Message payload schemas, descriptor metadata, validation limits, idempotency, policy evaluation, and owner routing stay DRY and AgentExecution-owned.
  • MCP tool calls write the same AgentExecution log records as stdout-marker observations after transport validation.
  • AgentExecution needs a transport-neutral observation entry point so stdout markers, MCP tool calls, provider structured output, and terminal heuristics can converge before policy evaluation.
  • Agent adapters need a small MCP provisioning boundary that can inject open-mission-mcp into provider-specific launch configuration without leaking session secrets into tracked repository files.
  • Open Mission and logs can display whether an Agent execution has MCP-backed, marker-backed, or unavailable structured message intake.
  • The MCP server does not replace TerminalRegistry, PTY interaction, Agent execution messages, Entity commands, or workflow verification.

Implementation Rules

  • Do not duplicate the current message payload schemas as MCP-local schemas.
  • Do not let MCP handlers mutate Mission runtime data, workflow state, Task state, or AgentExecution state directly.
  • Do not make MCP support a hard dependency for all Agent adapters.
  • Do not treat MCP tool names as globally stable public APIs outside the provisioned Agent execution descriptor.
  • Do not infer owner Entity ids from MCP tool arguments when the AgentExecution scope already defines ownership.
  • Do not apply policy effects more than once for the same Agent execution event id, regardless of transport or replay source.
  • Do not store per-execution MCP secrets in tracked files.
  • Do keep stdout marker instructions available for Agent runtimes that declare stdout-marker delivery before launch.