Mission will extend the daemon-owned open-mission-mcp server beyond Agent execution message tools by exposing Agent execution semantic operations.

An Agent execution semantic operation is a read-only daemon-owned operation made available to a registered Agent execution through its open-mission-mcp access. It gives the Agent structured access to Mission-approved context such as Artifact reads, repository code intelligence, symbol context, impact analysis, and route/tool maps without asking the Agent to rediscover the same information by repeatedly searching the filesystem.

This is an intentional expansion of ADR-0006.06. ADR-0006.06 kept open-mission-mcp narrowly framed as an Agent execution message transport so MCP could not become a hidden workflow authority or generic repository API. Mission now needs a second MCP-backed lane: scoped semantic reads that help an Agent perform its assigned Mission work while preserving daemon ownership, scope authorization, journaling, and provider neutrality.

Context

Spec-driven Mission work depends on an Agent understanding the repository, the Mission record, the current task, and the effects of code changes. Today an Agent must assemble much of that context through ad hoc searches, file reads, and terminal commands. That is slow, inconsistent, and hard for the daemon to audit semantically.

GitNexus proves there is real demand for MCP-accessible code intelligence: agents benefit from repository-aware tools for search, context, impact analysis, route maps, tool maps, and change analysis. Mission should provide those capabilities natively instead of requiring an external .gitnexus/ index and a separate MCP server, because Mission already owns Agent execution scope, Mission worktrees, daemon-observed Agent execution observations, and the daemon in-memory datastore direction.

Mission also already has the first seed of this model: read_artifact is implemented as a semantic operation rather than an Agent execution message. The architecture needs to promote that pattern deliberately before adding code intelligence tools.

Decision

open-mission-mcp may expose two classes of tools for a registered Agent execution:

  1. Agent execution message tools that route Agent-authored messages into daemon normalization and owner behavior.
  2. Agent execution semantic operations that perform scoped daemon-owned read operations and record daemon-observed Agent execution observations.

Both classes remain Agent-execution-scoped. The MCP server still starts and stops with the daemon, requires daemon-issued execution access, and is not a remote public API.

Semantic operations are materialized from a daemon-owned semantic operation catalog and filtered by Agent execution scope, selected Agent adapter capability, launch policy, and operation availability. An Agent execution must not receive a generic global repository toolset just because the daemon knows how to answer those questions.

The canonical route for semantic operations is:

Agent runtime MCP tool call
  -> open-mission-mcp tool ingress
  -> session authorization and operation input schema validation
  -> AgentExecutionRegistry route by Agent execution id
  -> AgentExecution semantic operation entry point
  -> AgentExecutionSemanticOperations
  -> operation-owned daemon service or read model
  -> AgentExecution journal observation record
  -> structured operation result

Semantic operations are read-only in this decision. They may read file-backed Artifacts, Repository roots, Mission worktree roots, daemon-owned read indexes, Git diff state, and Entity data views when the Agent execution scope allows that access. They must not mutate Mission workflow state, Entity storage records, repository files, Git refs, Mission records, Open Mission surface state, or Agent execution state except for recording authorized daemon-observed observations and activity records in the AgentExecution journal.

Mutation-like capabilities inspired by code intelligence tools, such as graph-assisted rename, are deliberately excluded from this ADR. If Mission later adds them, they must enter through Entity commands or another explicit mutation decision, not through read-only semantic operations.

Ownership

MissionMcpServer owns MCP ingress, session authorization, tool registration, request validation, transport shaping, and conversion to the semantic operation invocation contract.

AgentExecutionRegistry owns active Agent execution lookup. It must reject unknown or final executions before semantic operation effects are recorded.

AgentExecution owns the execution-scoped semantic operation entry point because it combines the active execution, scope, journal writer, process publication, and cleanup state. Narrow private capabilities may support the mechanical launch and IO work behind AgentExecution.

AgentExecutionSemanticOperations owns the semantic operation catalog, operation input schemas, operation result schemas, scope checks, daemon-observed observation recording, and dispatch to operation-specific services.

Operation-specific daemon services own their own read models. For example, Artifact access belongs to Artifact-owned services, while repository code intelligence belongs to a Repository code intelligence service and graph store. MCP handlers must not implement those domain reads inline.

AgentExecution owns the durable audit effect: every accepted semantic operation that reads meaningful context records a bounded daemon-observed observation in the AgentExecution interaction journal. The observation identifies the operation, target, scope, and bounded summary. It must not blindly dump large source files, secrets, embeddings, terminal scrollback, or raw prompts into the journal.

Tool Contract

Semantic operation descriptors must be schema-backed. Each descriptor includes:

  • operation name
  • title and description for Agent runtime presentation
  • input schema
  • result schema
  • scope requirements
  • read-only annotation
  • journal observation kind
  • size and redaction policy

Tool calls carry or are bound to:

  • Agent execution id
  • session token
  • optional event id for operation-level idempotency and journal correlation
  • operation-specific input

Owner identity and repository/worktree roots are resolved by the daemon from the AgentExecution scope. Agents may provide disambiguating query parameters such as symbol names, file paths, route names, relation directions, and depth limits, but they must not choose arbitrary roots outside their scope.

Security And Locality

Semantic operations inherit open-mission-mcp locality rules. A stdio bridge is allowed when an Agent runtime requires stdio MCP, but the bridge is only a transport adapter to the daemon-owned server.

Operations must be least-privilege and scope-bound. A task-scoped Agent execution may read the Mission worktree and task context that the daemon granted; a system-scoped execution does not automatically gain repository code intelligence. Repository and Mission worktree access must reject path traversal and must respect ignored, binary, oversized, generated, and sensitive-file policies defined by the code intelligence indexer.

Raw query escape hatches are not part of the baseline semantic operation surface. Mission may support a constrained code_query later, but exposing arbitrary SurrealQL over daemon-owned data would require a separate decision because it can leak data across scope boundaries and couple Agents to physical schema.

Consequences

  • Mission Agents can ask the Open Mission daemon for structured context instead of repeatedly searching the repository by hand.
  • open-mission-mcp becomes a scoped Agent execution context surface as well as a structured message transport, while remaining daemon-owned and local.
  • Artifact reads, code search, symbol context, impact analysis, route impact, and tool maps can share one semantic operation catalog.
  • AgentExecution journals gain durable daemon-observed observations for semantic reads, improving auditability and future replay/projection.
  • The MCP stdio bridge and adapter provisioning must support non-message semantic operation schemas and must stop assuming every MCP tool is an Agent execution message.
  • The operation catalog must stay small, purposeful, and scope-aware. Tool sprawl would recreate a generic repository API under another name.

Implementation Rules

  • Keep semantic read behavior in operation-specific daemon services behind AgentExecutionSemanticOperations.
  • Do not expose arbitrary filesystem, Git, Entity command, SurrealDB, or workflow mutation operations through semantic operation tools.
  • Do not let operation inputs choose filesystem roots when AgentExecution scope already defines accessible roots.
  • Do not record full source bodies or high-volume query output in AgentExecution journals by default; record bounded observations and return full requested content only in the MCP response when allowed.
  • Do not copy GitNexus source code into Mission without a separate licensing decision.
  • Do keep operation schemas in the owning operation module and infer TypeScript types from Zod schemas.
  • Do make the Mission MCP bridge transport semantic operation inputs directly instead of wrapping every tool call as an Agent execution message.
  • Do test each semantic operation through the MCP server boundary and through AgentExecutionSemanticOperations without requiring a real Agent runtime.