El adaptador de intercepción MCP abierto de Mission para autoridad de acción exacta.
Tiene un trabajo concreto: situarse antes de un proveedor MCP envuelto, clasificar una llamada de herramienta propuesta, y retener llamadas consecuentes con un enlace de acción inmutable de Graduación de Confianza. Las llamadas de bajo riesgo pueden pasar. Un mensaje de chat que diga "aprobar" nunca se trata como autoridad.
Estado: beta experimental. Apache-2.0. Cero dependencias en tiempo de ejecución.
Requisitos: Node.js 20 o superior.
npx -y @gomission/mcp@beta demoEl comando usa un proveedor de correo electrónico falso e imprime un resultado
DEMO_RESULT legible por máquina. Demuestra que:
la función del proveedor consecuente fue llamada cero veces;
la retención contiene una acción exacta y un hash de entrada;
cambiar la entrada revisada cambia el compromiso;
el texto del chat no otorga autoridad de ejecución.
Esto prueba la intercepción, no la autorización completada o la adopción en producción.
La prueba portátil de concesión/reproducción reside en @trust-graduation/core:
npx -y @trust-graduation/core@beta demoRelated MCP server: agentpassport
Primitiva | Responsabilidad | Objeto portátil |
Mission Gate | Decidir antes de un efecto del proveedor | decisión de acción |
Trust Profile | Rastrear autoridad ganada por principal y clase de acción | perfil de evidencia |
Mission Key | Autorizar una acción exacta hasta caducidad o revocación | concesión de un solo uso |
El adaptador MCP implementa la retención previa al proveedor. No acuña una Mission Key de confianza y no puede reanudar una llamada retenida. Un anfitrión de autorización de confianza y un ejecutor deben validar y consumir atómicamente la clave correspondiente. La continuación experimental A2A se publica en:
https://trustgraduation.org/extensions/a2a/action-authorization/v1
La raíz del paquete expone el puente de enlace estable y sin dependencias utilizado por un anfitrión de autorización externo y ejecutor:
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
});El puente verifica la integridad del enlace y mapea las identidades interceptadas, objetivo, restricciones, caducidad y nonce a la forma del ejecutor principal. El núcleo vuelve a calcular el hash de la entrada real del proveedor, autentica y consume atómicamente la Clave, llama al proveedor y escribe evidencia vinculada al resultado. La mutación o reproducción nunca llega al proveedor.
Para un adaptador generado y contadores objetivos de llamadas al proveedor:
npm install @trust-graduation/core@beta
npx trust-graduation init-adapter
npx trust-graduation conformance ./mission-gate-adapter.mjs --jsonCon ambos paquetes instalados, la prueba de compatibilidad incluida es:
node node_modules/@trust-graduation/core/examples/mcp-provider-roundtrip.mjsEl proxy MCP aún no reanuda una llamada retenida solo porque el chat diga "aprobar". Este puente es para el anfitrión de autorización autenticado por separado y el ejecutor vinculado al proveedor.
npx -y @gomission/mcp@beta install-claudeEl instalador inspecciona la configuración MCP existente de Claude Desktop:
si encuentra servidores MCP consecuentes, selecciona --wrap;
de lo contrario, selecciona --local, una demostración de enlace exacto consultiva;
nunca selecciona automáticamente el modo de solo lectura alojado.
Reinicie Claude Desktop después de la instalación, luego verifique:
npx -y @gomission/mcp@beta verifyverify sondea MCP moderno con server/discover y tools/list, recurriendo al
protocolo de la era de inicialización para endpoints antiguos. Añada --json para un
informe legible por máquina o --no-probe para inspeccionar solo la configuración.
Modo | Lo que impone | Lo que no hace |
| Intercepta servidores MCP hijo seleccionados; retiene llamadas altas/críticas o de baja confianza antes del hijo; falla cerrado si un hijo no está disponible | No reanuda una llamada retenida ni confía en la aprobación del chat |
| Registra una retención de acción exacta consultiva y un recibo de revisión local | No está entre otra herramienta y su proveedor |
| Expone el contexto MCP de Mission alojado de solo lectura | No intercepta otros servidores MCP |
Elija explícitamente cuando sea necesario:
npx -y @gomission/mcp@beta install-claude --wrap
npx -y @gomission/mcp@beta install-claude --local
npx -y @gomission/mcp@beta install-claude --remoteBanderas útiles:
--workspace <ruta> — almacena recibos locales en un espacio de trabajo existente.
--dry-run — imprime el cambio de configuración sin escribirlo.
--force — crea configuración incluso cuando no se detecta Claude Desktop.
--remote-url <url> — anula el endpoint alojado.
MISSION_DONT_WRAP="nombre1,nombre2" — excluye hijos MCP seleccionados.
Para una llamada envuelta consecuente, el adaptador escribe un recibo local que contiene:
clase de acción;
identificador de espacio de trabajo local que preserva la privacidad;
hijo MCP solicitante;
objetivo cuando se puede inferir;
compromiso de entrada SHA-256;
restricciones de una ejecución;
caducidad y nonce;
compromiso SHA-256 sobre el enlace completo.
Los recibos se escriben atómicamente con permisos de archivo solo para el propietario. El adaptador nunca almacena la ruta del espacio de trabajo sin procesar dentro del enlace. Un resumen de argumentos locales permanece en el recibo para revisión humana, por lo que se debe tratar el directorio de recibos como datos de espacio de trabajo sensibles.
Protocolo preferido: 2026-07-28.
_meta sin estado por solicitud con capacidades del cliente;
server/discover obligatorio;
un mensaje JSON-RPC por POST HTTP; los lotes modernos y las notificaciones del cliente fallan cerrados;
enlace HTTP para MCP-Protocol-Version, Mcp-Method y Mcp-Name;
errores HeaderMismatch y de versión no soportada definidos por el protocolo;
resultType: "complete" y metadatos de caché;
compatibilidad con la era de inicialización para 2025-11-25 y 2024-11-05.
El manifiesto de autoridad se anuncia a través del descubrimiento MCP bajo la capacidad
experimental mission-authority/v1.
El adaptador no afirma:
que un modelo o interfaz de chat haya autenticado al principal;
que un recibo de revisión sea una concesión de aprobación;
comportamiento exactamente una vez en un proveedor externo;
conformidad independiente o validación de producción;
confianza global en un agente.
Use @trust-graduation/core para crear y validar concesiones exactas. El ejecutor
debe autenticar al emisor de la concesión, re-vincular la entrada real del proveedor,
consumir atómicamente la clave, invocar al proveedor como máximo una vez y reconciliar
los resultados desconocidos del proveedor.
Gratuito y abierto:
este adaptador MCP;
@trust-graduation/core y sus esquemas;
vocabulario de conformidad @gomission/mission-schemas;
la extensión de autorización de acción exacta A2A;
la aplicación de enfoque local Mission Lite.
Mission Comercial puede proporcionar políticas gestionadas, superficies de aprobación de confianza, operaciones de auditoría/recepción alojadas, controles organizativos, soporte e integraciones con proveedores. Los derechos de producto nunca otorgan autoridad de acción.
Protocolo: https://trustgraduation.org/
Extensión A2A: https://trustgraduation.org/extensions/a2a/action-authorization/v1
Mission: https://gomission.io/
Código fuente: https://github.com/gomission/mcp
Apache-2.0. Los nombres y logotipos de Mission son marcas comerciales; la licencia del código no otorga permiso para implicar respaldo.
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.
