This server acts as a permission and approval layer for AI actions, gating consequential operations and maintaining a receipt trail for all activity.
Check gate status (mission_status): Retrieve the current Mission permission layer status, version, and the full list of Trust Graduation action classes — recommended as the first call in any session.
Request approval for consequential actions (request_approval): Trigger an approval ceremony before executing high-stakes actions such as sending email, posting publicly, sending DMs, scheduling meetings, spending money, publishing artifacts, modifying external records, or changing trust policy. The action is blocked until approved, and a receipt is written.
Log safe internal actions (log_action): Record non-external, lower-risk actions with Mission to produce a permanent receipt for audit/traceability purposes.
Fetch receipts (get_receipt): Retrieve a previously written Mission receipt by its ID, enabling traceability and audit of past actions.
Query Mission's operating intelligence (mission_ask): Ask Mission's AI brain about the user's work context — including open loops, draft queue, voice profile, weekly proof state, and active focus. Useful for questions like what to approve, who to follow up with, or what to prepare next (requires a local Mission instance running on port 8814).
Mission’s open MCP interception adapter for exact-action authority.
It has one narrow job: sit before a wrapped MCP provider, classify a proposed tool call, and hold consequential calls with an immutable Trust Graduation action binding. Low-risk calls may pass through. A chat message saying “approve” is never treated as authority.
Status: experimental beta. Apache-2.0. Zero runtime dependencies.
Requirements: Node.js 20 or newer.
npx -y @gomission/mcp@beta demoThe command uses a fake email provider and prints one machine-readable
DEMO_RESULT. It proves that:
the consequential provider function was called zero times;
the hold contains an exact action and input hash;
changing the reviewed input changes the commitment;
chat text grants no execution authority.
This proves interception, not completed authorization or production adoption.
The portable grant/replay proof lives in @trust-graduation/core:
npx -y @trust-graduation/core@beta demoRelated MCP server: agentpassport
Primitive | Responsibility | Portable object |
Mission Gate | Decide before a provider effect | action decision |
Trust Profile | Track earned authority per principal and action class | evidence profile |
Mission Key | Authorize one exact action until expiry or revocation | single-use grant |
The MCP adapter implements the pre-provider hold. It does not mint a trusted Mission Key and it cannot resume a held call. A trusted approval host and executor must validate and atomically consume the matching key. The experimental A2A continuation is published at:
https://trustgraduation.org/extensions/a2a/action-authorization/v1
The package root exposes the stable, zero-dependency binding bridge used by an external approval host and executor:
import { providerActionFromMcpBinding } from "@gomission/mcp";
import { createProviderGate } from "@trust-graduation/core";
const gate = createProviderGate({
store: sharedAtomicGrantStore,
authenticateGrant: verifyApprovalIssuer,
provider: existingProviderFunction,
writeReceipt: durableReceiptSink
});
// Re-read the actual provider input at the final seam; never trust a preview.
const action = providerActionFromMcpBinding(
heldReceipt.action_binding,
actualProviderInput
);
const execution = await gate.execute({
binding: heldReceipt.action_binding,
approval: authenticatedMissionKey,
action
});The bridge verifies binding integrity and maps the intercepted identities, target, constraints, expiry, and nonce into the core executor shape. The core then re-hashes the actual provider input, authenticates and atomically consumes the Key, calls the provider, and writes result-linked evidence. Mutation or replay never reaches the provider.
For a generated adapter and objective provider-call counters:
npm install @trust-graduation/core@beta
npx trust-graduation init-adapter
npx trust-graduation conformance ./mission-gate-adapter.mjs --jsonWith both packages installed, the included compatibility proof is:
node node_modules/@trust-graduation/core/examples/mcp-provider-roundtrip.mjsThe MCP proxy still never resumes a held call merely because chat says "approve". This bridge is for the separately authenticated approval host and provider-bound executor.
npx -y @gomission/mcp@beta install-claudeThe installer inspects the existing Claude Desktop MCP configuration:
if it finds consequential MCP servers, it selects --wrap;
otherwise it selects --local, an advisory exact-binding demonstration;
it never auto-selects the hosted read-only mode.
Restart Claude Desktop after installation, then verify:
npx -y @gomission/mcp@beta verifyverify probes modern MCP with server/discover and tools/list, falling back
to the initialize-era protocol for older endpoints. Add --json for a
machine-readable report or --no-probe to inspect configuration only.
Mode | What it enforces | What it does not do |
| Intercepts selected child MCP servers; holds high/critical or low-confidence calls before the child; fails closed if a child is unavailable | Does not resume a held call or trust chat approval |
| Records an advisory exact-action hold and local review receipt | Is not between another tool and its provider |
| Exposes hosted read-only Mission context | Does not intercept other MCP servers |
Choose explicitly when needed:
npx -y @gomission/mcp@beta install-claude --wrap
npx -y @gomission/mcp@beta install-claude --local
npx -y @gomission/mcp@beta install-claude --remoteUseful flags:
--workspace <path> — store local receipts in an existing workspace.
--dry-run — print the configuration change without writing it.
--force — create configuration even when Claude Desktop is not detected.
--remote-url <url> — override the hosted endpoint.
MISSION_DONT_WRAP="name1,name2" — exclude selected MCP children.
For a consequential wrapped call, the adapter writes a local receipt containing:
action class;
privacy-preserving local workspace identifier;
requesting MCP child;
target when one can be inferred;
SHA-256 input commitment;
one-execution constraints;
expiry and nonce;
SHA-256 commitment over the complete binding.
Receipts are written atomically with owner-only file permissions. The adapter never stores the raw workspace path inside the binding. A local argument summary remains in the receipt for human review, so treat the receipt directory as sensitive workspace data.
Preferred protocol: 2026-07-28.
stateless per-request _meta with client capabilities;
mandatory server/discover;
one JSON-RPC message per HTTP POST; modern batches and client notifications fail closed;
HTTP binding for MCP-Protocol-Version, Mcp-Method, and Mcp-Name;
protocol-defined HeaderMismatch and unsupported-version errors;
resultType: "complete" and cache metadata;
initialize-era compatibility for 2025-11-25 and 2024-11-05.
The authority manifest is advertised through MCP discovery under the
experimental mission-authority/v1 capability.
The adapter does not claim:
that a model or chat UI authenticated the principal;
that a review receipt is an approval grant;
exactly-once behavior at an external provider;
independent conformance or production validation;
global trust in an agent.
Use @trust-graduation/core to create and validate exact grants. The executor
must authenticate the grant issuer, re-bind the actual provider input, atomically
consume the key, invoke the provider at most once, and reconcile unknown
provider outcomes.
Free and open:
this MCP adapter;
@trust-graduation/core and its schemas;
@gomission/mission-schemas conformance vocabulary;
the A2A exact-action authorization extension;
Mission Lite’s local focus app.
Commercial Mission may provide managed policy, trusted approval surfaces, hosted audit/receipt operations, organization controls, support, and provider integrations. Product entitlements never grant action authority.
Protocol: https://trustgraduation.org/
A2A extension: https://trustgraduation.org/extensions/a2a/action-authorization/v1
Mission: https://gomission.io/
Source: https://github.com/gomission/mcp
Apache-2.0. Mission names and logos are trademarks; the code license does not grant permission to imply endorsement.
Fetch a Mission receipt by id.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states a basic fetch operation without disclosing any behavioral traits such as read-only nature, error handling, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste, but it could benefit from a bit more detail without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is minimally adequate but lacks information on return format, error conditions, or how receipt_id is obtained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (receipt_id) with no description, and the tool description only mentions 'by id' without explaining format, examples, or how to obtain the id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a Mission receipt by id' uses a specific verb and resource, clearly distinguishing it from sibling tools like log_action or mission_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, and no exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a safe internal action with Mission. Returns a receipt id. Use for non-external actions that still benefit from a permanent receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | ||
| evidence | No | ||
| action_class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'safe internal action' and output, but omits details about authentication, side effects, or error conditions. The term 'safe' is vague and insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences, no filler. Key information is front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is too sparse. It provides no parameter guidance, no return value details beyond receipt id, and no error handling. The complexity is not matched by the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema). The description does not mention any parameters, their purpose, or constraints. It fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action 'log a safe internal action' and output 'returns a receipt id'. It gives a specific verb and resource, but does not explicitly differentiate from siblings like 'get_receipt' or 'request_approval', though the internal purpose is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use: 'Use for non-external actions that still benefit from a permanent receipt.' This gives a clear context, but lacks explicit exclusions or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Talk to Mission's hero chatbox brain. Mission is the user's operating intelligence: it knows the user's open loops, draft queue, voice profile, weekly proof state, learning evidence, and active focus. Use this when the user asks anything about their work, their week, what to approve, what to prepare, who to follow up with, or what Mission thinks. Requires a local Mission running (mission web 8814). Returns the brain's reply array and any prepared actions. Always use this BEFORE drafting a reply or proposing work — Mission already knows what the user is doing.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A natural-language question or instruction for Mission. Examples: 'what should I approve today?', 'who am I dropping?', 'prepare a reply to Sandro', 'show me my weekly proof', 'what did I just learn?' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return type ('reply array and any prepared actions') and notes it requires a running Mission. Lacks explicit statement about side effects (e.g., read-only), but the query nature implies safety. No annotations provided, so description carries burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then context, guidelines, prerequisite, return type, and final advice. Each sentence adds value, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, prerequisite, return type, and behavioral context. No output schema, but description gives reasonable completeness for a 1-param tool. Could detail the format of the reply array.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter description and examples. The tool description does not add significant new semantic information beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Talk to Mission's hero chatbox brain' and explains what Mission knows. It distinguishes itself from sibling tools (e.g., get_receipt, log_action) by being a general query/chat tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use this when the user asks anything about their work...' and 'Always use this BEFORE drafting a reply or proposing work'. Also mentions prerequisite (local Mission running). Clear when and when-not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Mission gate status, version, and the current Trust Graduation action classes. Call this first in any session to introduce the permission layer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the return values but does not explicitly state that it has no side effects or that it is read-only. However, the nature of returning status information implies safety, so it is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states what it returns, the second gives usage guidance. No unnecessary words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately lists the three return categories (gate status, version, action classes). It could provide more detail on the format, but it is sufficient for a simple tool with no parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. The description does not need to add parameter meaning; it correctly omits parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Mission gate status, version, and the current Trust Graduation action classes'. It distinguishes itself from siblings by instructing to call it first in any session to introduce the permission layer, making its unique role obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'Call this first in any session'. This implies it is a prerequisite for other tools, though it does not explicitly state when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mission gates any consequential action. Call this BEFORE executing actions in classes like send_email, post_public, send_dm, schedule_meeting, spend_money, publish_artifact, modify_external_record, change_trust_policy. Mission returns an approval-required ceremony and writes a receipt. Do not proceed without approval.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | One-line plain-English summary of the action. | |
| evidence | No | Optional evidence supporting the action. | |
| action_class | Yes | One of: send_email, post_public, send_dm, schedule_meeting, spend_money, publish_artifact, modify_external_record, change_trust_policy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that the tool 'returns an approval-required ceremony and writes a receipt,' explaining the core behavior and output. It could elaborate on side effects or error conditions, but the description is sufficient for basic understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences that front-load the purpose. Every sentence adds value, and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value ('approval-required ceremony' and 'receipt'). It mentions sibling tools and lists all relevant action classes. It could include more on error handling but is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the baseline is 3. The description adds minor context by stating that 'summary' is a one-line plain-English summary and listing allowed values for 'action_class', but does not provide substantial new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to request approval before consequential actions. It specifies the verb ('request approval'), the resource ('approval ceremony'), and lists the exact action classes that require approval, distinguishing itself from sibling tools like 'get_receipt' and 'log_action'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this BEFORE executing actions in classes like...' and 'Do not proceed without approval,' providing clear when-to-use guidance. It could be more specific about when not to use, but the list of action classes implicitly defines the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_receiptlog_actionmission_askmission_statusrequest_approvalScored across 5 tools
Each tool has a clearly distinct purpose: fetching receipts, logging actions, querying Mission's AI, checking system status, and requesting approval for consequential actions. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (get_receipt, log_action, mission_ask, mission_status, request_approval), making them predictable and easy to understand.
With 5 tools covering status, queries, approvals, logging, and receipt retrieval, the count is well-suited for a permission and AI interaction layer. Neither too sparse nor excessive.
The set covers core operations for interacting with Mission's system. A minor gap is the lack of a tool to list or manage receipts, and the approval tool implies external actions not directly handled here, but the surface is complete for its intended role.
Decision-assurance for AI agents: an auditable action boundary + receipt before it acts.
Trust gate for AI agents: multi-model adversarial consensus, signed and verifiable verdicts.
Independent effect verification and signed receipts for consequential AI agent actions.
Pre-execution policy gate for consequential agent actions with durable trust receipts.
