Mission 的开放 MCP 拦截适配器，用于精确动作授权。
它的职责单一：位于被封装的 MCP 提供者之前，对提议的工具调用进行分类，并使用不可变的信任毕业动作绑定来保留有后果的调用。低风险调用可以放行。一条包含“批准”的聊天消息永远不会被视为授权。
状态：实验性 beta。Apache-2.0。零运行时依赖。
要求：Node.js 20 或更高版本。
npx -y @gomission/mcp@beta demo该命令使用一个虚假的电子邮件提供者，并打印一条机器可读的 DEMO_RESULT。它证明了：
有后果的提供者函数被调用了零次；
保留中包含了精确动作和输入哈希；
更改已审查的输入会改变承诺；
聊天文本不授予执行权限。
这证明了拦截，而非完整的授权或生产采用。便携的授权/重放证明存在于 @trust-graduation/core 中：
npx -y @trust-graduation/core@beta demoRelated MCP server: agentpassport
原语 | 职责 | 可移植对象 |
Mission Gate | 在提供者效果之前做出决定 | 动作决策 |
Trust Profile | 跟踪每个主体和动作类别的已获授权 | 证据档案 |
Mission Key | 授权一个精确动作，直到过期或撤销 | 一次性授权 |
MCP 适配器实现了提供者前的保留。它不会生成受信任的 Mission Key，也无法恢复被保留的调用。受信任的审批主机和执行器必须验证并原子性地消耗匹配的密钥。实验性 A2A 延续发布在：
https://trustgraduation.org/extensions/a2a/action-authorization/v1
包根目录暴露了稳定、零依赖的绑定桥接，供外部审批主机和执行器使用：
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
});桥接验证绑定完整性，并将拦截的身份、目标、约束、过期时间和随机数映射到核心执行器形状。然后核心重新对实际提供者输入进行哈希，验证并原子性地消耗密钥，调用提供者，并写入结果关联的证据。篡改或重放永远不会到达提供者。
对于生成的适配器和客观的提供者调用计数器：
npm install @trust-graduation/core@beta
npx trust-graduation init-adapter
npx trust-graduation conformance ./mission-gate-adapter.mjs --json同时安装两个包后，包含的兼容性证明是：
node node_modules/@trust-graduation/core/examples/mcp-provider-roundtrip.mjsMCP 代理仍然不会仅仅因为聊天说“批准”就恢复被保留的调用。此桥接用于单独认证的审批主机和绑定提供者的执行器。
npx -y @gomission/mcp@beta install-claude安装程序检查现有的 Claude Desktop MCP 配置：
如果发现存在有后果的 MCP 服务器，则选择 --wrap；
否则选择 --local，即建议性的精确绑定演示；
它永远不会自动选择托管只读模式。
安装后重启 Claude Desktop，然后验证：
npx -y @gomission/mcp@beta verifyverify 使用 server/discover 和 tools/list 探测现代 MCP，对于较旧端点回退到初始化时代协议。添加 --json 获取机器可读报告，或 --no-probe 仅检查配置。
模式 | 强制执行的内容 | 不执行的内容 |
| 拦截选定的子 MCP 服务器；在子服务器之前保留高/关键或低置信度调用；如果子服务器不可用则安全失败 | 不恢复被保留的调用或信任聊天批准 |
| 记录建议性的精确动作保留和本地审查收据 | 不在另一个工具与其提供者之间 |
| 暴露托管只读 Mission 上下文 | 不拦截其他 MCP 服务器 |
需要时显式选择：
npx -y @gomission/mcp@beta install-claude --wrap
npx -y @gomission/mcp@beta install-claude --local
npx -y @gomission/mcp@beta install-claude --remote有用的标志：
--workspace <path> — 将本地收据存储在现有工作区中。
--dry-run — 打印配置更改但不写入。
--force — 即使未检测到 Claude Desktop 也创建配置。
--remote-url <url> — 覆盖托管端点。
MISSION_DONT_WRAP="name1,name2" — 排除选定的 MCP 子节点。
对于有后果的包装调用，适配器写入包含以下内容的本地收据：
动作类别；
保护隐私的本地工作区标识符；
请求的 MCP 子节点；
可以推断出的目标；
SHA-256 输入承诺；
单次执行约束；
过期时间和随机数；
完整绑定的 SHA-256 承诺。
收据以原子方式写入，并设置仅所有者可读的文件权限。适配器不会在绑定内存储原始工作区路径。本地参数摘要保留在收据中以供人工审查，因此请将收据目录视为敏感工作区数据。
首选协议：2026-07-28。
无状态的每个请求 _meta 包含客户端能力；
强制要求 server/discover；
每个 HTTP POST 一个 JSON-RPC 消息；现代批处理和客户端通知安全失败；
MCP-Protocol-Version、Mcp-Method 和 Mcp-Name 的 HTTP 绑定；
协议定义的 HeaderMismatch 和不受支持的版本错误；
resultType: "complete" 和缓存元数据；
兼容 2025-11-25 和 2024-11-05 的初始化时代协议。
权限清单通过 MCP 发现，在实验性的 mission-authority/v1 能力下公布。
适配器不声明：
模型或聊天 UI 已认证主体；
审查收据是授权批准；
在外部提供者处恰好一次行为；
独立合规性或生产验证；
对代理的全局信任。
使用 @trust-graduation/core 创建和验证精确授权。执行器必须认证授权发行者，重新绑定实际提供者输入，原子性消耗密钥，最多调用一次提供者，并协调未知的提供者结果。
免费且开源：
此 MCP 适配器；
@trust-graduation/core 及其模式；
@gomission/mission-schemas 合规性词汇；
A2A 精确动作授权扩展；
Mission Lite 的本地焦点应用。
商业版 Mission 可能提供托管策略、受信任的审批界面、托管审计/收据操作、组织控制、支持和提供者集成。产品授权从不授予动作权限。
A2A 扩展：https://trustgraduation.org/extensions/a2a/action-authorization/v1
Mission：https://gomission.io/
Apache-2.0。Mission 名称和徽标是商标；代码许可证不授予暗示认可的权利。
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.
Check the explicitly selected local Mission workspace for chat availability. Requires MISSION_WORKSPACE and an explicit loopback MISSION_LOCAL_URL or MISSION_LOCAL_PORT. Chat is currently unavailable until a workspace-scoped authentication handoff is supported; this tool does not forward queries or prepare actions.
| 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?
With no annotations, the description carries the full burden and delivers unusually candid behavior: it discloses required environment variables and, critically, that chat is currently unavailable pending a workspace-scoped authentication handoff. It also states the tool has no side effects (no query forwarding, no action preparation). It falls short of a 5 only because it does not describe what the call actually returns in its unavailable state.
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?
Three sentences with the core purpose front-loaded and no obvious padding. It is dense but efficient; minor jargon ('loopback', 'workspace-scoped authentication handoff') slightly slows comprehension.
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 is a non-functional availability probe with no output schema, the description is largely complete: it covers required env configuration, the blocked state, and the absence of side effects. It would be fully complete if it pointed the agent at mission_status or otherwise told it what to do instead.
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 description coverage is 100% and the single required 'query' parameter is fully documented with examples in the schema, so the baseline is 3. The line 'does not forward queries' does tell the agent the parameter is effectively inert, which is useful, but otherwise the description adds no syntax or format detail 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 states a specific action and scope: checking the explicitly selected local Mission workspace for chat availability, and explicitly narrows it by saying it 'does not forward queries or prepare actions.' This distinguishes it from request_approval and log_action. It loses a point because the name 'mission_ask' implies a working Q&A tool, creating tension the description only partially resolves, and it never contrasts itself with 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?
Preconditions are stated clearly (MISSION_WORKSPACE plus an explicit loopback MISSION_LOCAL_URL or MISSION_LOCAL_PORT), which is real context. However, there is no explicit when-to-use vs when-not-to-use guidance relative to siblings like mission_status, and the reader must infer that this tool is effectively a no-op probe.
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.
Legacy-named advisory hold. Call before a consequential action to produce an exact action binding and local review receipt. This tool does not grant authority or resume execution; the executor must validate a matching single-use Mission Key.
| 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?
With no annotations, the description carries the full burden and discharges much of it: it discloses that the call is advisory-only, non-authoritative, does not resume execution, and that the executor must validate a matching single-use Mission Key. It omits auth requirements and what the receipt actually contains, which are notable gaps for a zero-annotation tool.
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?
Three sentences with no filler, and the most consequential caveat (legacy name, advisory-only) is front-loaded before the invocation condition. Every sentence changes how an agent would behave.
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?
For a 3-parameter, no-annotation, no-output-schema tool, the description covers the critical semantics: advisory scope, non-authority, and the Mission Key handoff. It does not describe the receipt's contents or the full Mission Key flow, which leaves a small but real gap.
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 description coverage is 100%, so action_class, summary, and evidence are already documented with their allowed values. The description adds no syntax or format guidance beyond the schema, so the baseline 3 is appropriate.
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 names a concrete deliverable (an exact action binding and a local review receipt) for a consequential-action workflow, and flags that the tool name 'request_approval' is legacy and misleading. It does not, however, position itself against siblings like mission_ask or get_receipt, so the agent gets the function but not the sibling routing.
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?
It gives clear positive timing ('Call before a consequential action') and an explicit negative boundary ('does not grant authority or resume execution'). It stops short of naming which sibling to use instead when the agent actually needs authority or status, so the alternative-routing half of the guidance is missing.
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 targets a distinct action: request_approval for consequential holds, log_action for internal receipts, get_receipt for retrieval, mission_status for gate status, and mission_ask for chat availability. The overlap between request_approval and log_action (both producing receipts) is clarified by descriptions, but the legacy advisory nature of request_approval could still cause confusion.
Most tools use a verb_noun pattern (request_approval, get_receipt, log_action), but mission_ask and mission_status use a noun-prefix convention, and request_approval is explicitly labeled legacy-named. The mix is readable but not fully consistent.
Five tools is a reasonable size for a focused permission-layer server. However, mission_ask is currently non-functional and request_approval is legacy, so one tool does not fully earn its place, making the count slightly heavy rather than ideal.
The core lifecycle of status, approval request, action logging, and receipt retrieval is covered, but there are notable gaps: no way to list or search receipts, no tool to validate the single-use Mission Key that request_approval requires the executor to check, and mission_ask only checks unavailable chat functionality.
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.
