Mneme Decision MCP
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| decision.proposeA | Submit one candidate architectural decision. The proposal enters the Mneme decision index as a non-authoritative proposal with status 'proposed'. This grants NO authority: the proposal is never enforceable and can only become canonical through separate Mneme human authority (D2C), which this MCP does not expose. Repeated identical source/version/content submissions are idempotent. Use decision.propose_batch when submitting multiple candidates. |
| decision.propose_batchA | Submit multiple candidate architectural decisions from one producer output. Each candidate receives its own independent proposal identity and enters as a non-authoritative proposal with status 'proposed'. There are no batch acceptance semantics: batch submission grants NO authority, and every proposal remains independently reviewable. Use decision.propose for a single candidate. |
| decision.getA | Read one record by stable id. Returns record_type 'proposal', 'canonical_decision', or 'not_found'. Read only: this tool never mutates any state. Use decision.search when you do not already have a stable id. |
| decision.searchA | Deterministic text/exact-metadata search. Proposals (lifecycle proposed/accepted/rejected) and canonical decisions (lifecycle active/superseded/deprecated/inactive) are returned in separate lists and never merged. Read only: this tool never mutates any state. Search rank has no enforcement meaning. Use decision.get when you already have a stable id. Within each record domain, all applicable filters combine with AND semantics; proposal-only filters do not exclude canonical results, and vice versa. |
| decision.applicable_toA | Return proposals and canonical decisions whose scope hints or context scope overlap the supplied context/paths. This is retrieval/context applicability only: proposal scope hints are NOT typed-rule applicability (ADR-020) and paths are never glob-evaluated. Read only: this tool never mutates any state and returns no rules or enforcement data. When both inputs are omitted or empty, both match lists are empty. |
| decision.traceA | Return the deterministic lineage actually known for a proposal id or canonical decision id. The result_type is explicit (proposal_trace / canonical_trace / trace_not_found); unresolved ids stay type-unknown. Read only: this tool never mutates any state. Canonical rule-lineage integrity failures fail closed as protocol errors and are never returned as partial traces. Use decision.get for the record alone; use decision.trace when you need provenance, acceptance, rule, or declared-evidence lineage. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct action-resource pair: propose/propose_batch differ only in cardinality and cross-reference each other, while get/search/applicable_to/trace are clearly separated by input type (stable id vs text vs context/path vs provenance). No two tools would be confused for the same operation.
All tools share the decision.* namespace and use short, imperative verbs (propose, get, search, trace). The two compound names (propose_batch, applicable_to) use the same underscore convention, so the naming feels systematic and predictable.
Six tools is a tight, purposeful surface for a decision index: two write paths (single/batch), three read/retrieval paths (by id, text search, context overlap), and one provenance trace. Each tool has a distinct role and none feels redundant.
The core write-once proposal plus retrieval workflow is well covered, including batch submission and lineage tracing. However, there is no way to update, withdraw, or transition a proposal's status within the MCP; this is explicitly delegated to external human authority, but agents still cannot correct or retire a mistaken proposal.