Why expose decisions over MCP?

Architectural decisions often have to reach more than one coding agent, editor, or architecture system. Bespoke adapters make that decision context dependent on each tool. MCP gives those systems one local protocol boundary for querying the Decision Index and returning candidate decisions to Mneme.

That is why MCP matters to Mneme: it shows that decisions are addressable independently of any one coding harness. The protocol solves connection and exchange. Mneme still owns the meaning of a decision, its lifecycle, its scope, and the deterministic enforcement mechanisms built from it.

RetrievalWhat should the agent know?

MCP reads proposals and configured canonical decisions, searches them, finds contextual matches, and traces known lineage.

AuthorityWhat has the team adopted?

A human reviews and accepts or rejects proposals through the separate mneme decision CLI.

EnforcementWhat must a change obey?

Typed rules, applicability, hooks, and CI gates deterministically evaluate work. MCP does not replace them.

What ships in 0.9.0

The local server starts with mneme decision-mcp and communicates over stdio. It exposes exactly six tools:

decision.proposedecision.propose_batchdecision.getdecision.searchdecision.applicable_todecision.trace

The first two create non-authoritative proposal records. The remaining four are read-only. Canonical reads are available when the operator explicitly supplies a schema-valid ADR corpus with --adr-dir. Proposal persistence defaults to .mneme/decision_proposals.json.

For installation, configuration, exact input fields, result shapes, and error behavior, use the MCP server reference.

Proposals are not canonical decisions

An agent-generated architecture may contain useful decisions, but generation alone cannot make those decisions authoritative. MCP records each candidate as proposed, preserves source provenance, and returns a stable proposal ID. A person then inspects it and explicitly accepts or rejects it through the CLI.

producer or coding agent
        |
        v
decision.propose / decision.propose_batch
        |
        v
non-authoritative proposal store
        |
        v
human review: mneme decision show / accept / reject
        |
        v
canonical project-memory decision
        |
        v
Audit, modelling, protection, enforcement

Acceptance materializes the decision into project memory. It does not automatically install a typed rule, mark the decision Protected, run the Audit, or activate enforcement. Those remain deliberate downstream steps.

What MCP deliberately cannot do

  • Accept or reject a proposal.
  • Create, activate, deactivate, or supersede a canonical decision.
  • Install a typed rule or create an exception.
  • Turn scope hints into deterministic rule applicability.
  • Submit trusted evidence or claim that a decision is enforced.
  • Bypass human review or repair canonical lineage.

Authority-shaped input fields are rejected at the schema boundary rather than silently ignored. This is why the tool list is intentionally small and frozen for the 0.9.0 release.

Local interoperability, not a hosted control plane

The 0.9.0 server is a local stdio process. There is no remote endpoint, HTTP or SSE transport, cloud service, RBAC layer, organization-wide persistence, or client-specific installer in this release. An MCP host must be able to launch the local mneme decision-mcp process using its own configuration format.

This page does not claim verified support for named MCP clients. The released contract is the local process and six protocol tools; compatibility with a particular host should be established against that host's current stdio configuration behavior.

Known 0.9.0 boundaries

  • Canonical store unification: decisions accepted into .mneme/project_memory.json are visible to existing runtime and Audit surfaces, but are not automatically composed into MCP's ADR-backed canonical-read path.
  • Process refresh: an already-running MCP process does not observe an accept or reject performed by a separate CLI process until the MCP process is restarted.

Both behaviors are explicit rather than hidden: missing canonical records and links are returned as typed absent/not-found data, and no live file-watching behavior is implied.

Where MCP fits

MCP is an interoperability boundary for Mneme's decision layer. It lets heterogeneous systems exchange decision context without redefining governance in each system. The deterministic enforcement layer still operates at execution boundaries such as agent hooks and CI, where actual changes can be evaluated against applicable rules.

See Decision proposals for the full human review workflow and How enforcement works for the prevent, catch, and verify layers that MCP complements.

Related implementation paths include ADR import for compiling an existing decision corpus and the Claude Agent SDK integration for enforcement around agent execution. The released implementation is available in the Mneme source repository.

Decision layer for the wider agentic SDLC

Mneme is not a substitute for code review, CI, issue tracking, or change-management tooling. Those systems decide what changed, whether the implementation is correct, what risk it introduces, and which change deserves attention next. Mneme answers a different, earlier question: what has the organization already decided about the architecture this change has to obey?

Decision Index
        |
        v
       MCP
        |
        v
agent / review system / change-management system
        |
        v
      change

A downstream system that can launch the local server does not need Mneme's internals to use this. It calls the Decision Index through MCP, retrieves the architectural decisions applicable to a proposed action, and keeps its own responsibility for code quality, risk, prioritization, and workflow. The 0.9.0 transport is local stdio, so this composes today with tools running beside the checkout, not with hosted services.

Example, not a shipped integration: CodeRabbit's Triage feature, launched September 15, 2026, assigns every pull request a deterministic priority from P0 to P3 as the "prioritization layer" of what CodeRabbit calls Agentic Change Management — its system for governing change from both humans and agents (CodeRabbit, September 2026). A change-management system built this way could query Mneme's Decision Index over MCP to retrieve the architectural decisions governing a change, while continuing to own its own review, impact analysis, and prioritization. Mneme has no CodeRabbit integration today; this illustrates the interoperability pattern MCP was built for, not a supported connector.

Review systems govern changes. Mneme governs the decisions those changes have to obey.

Native integrations

MCP is one access path to the Decision Index. Several coding agents and IDEs integrate natively instead: Claude Code, Codex CLI, and Kiro, with an experimental adapter for Hermes. It is a retrieval and proposal surface only. Native integrations go further: they inject decision context at agent runtime and enforce applicable constraints at the write boundary through mneme check. Use MCP when you need decision context in a tool Mneme has no adapter for; use a native integration when you need enforcement.