Tu agente de IA hizo 847 llamadas a herramientas ayer. ¿Puedes verificar lo que hizo?
Registro de auditoría a prueba de manipulaciones para llamadas a herramientas de agentes de IA.
Antes:
{
"command": "npx",
"args": ["@modelcontextprotocol/server-github"]
}Después:
{
"command": "npx",
"args": ["mcp-audit", "wrap", "--", "npx", "@modelcontextprotocol/server-github"]
}Cada llamada a herramienta ahora está firmada criptográficamente y encadenada por hash. Nada más cambia. El servidor MCP funciona exactamente igual que antes.
Related MCP server: Agent Audit Trail MCP Server
$ mcp-audit tail
✓ 14:32:01 github/create_pr 234ms bf7a2f62
✓ 14:32:03 github/list_issues 89ms a1c4e890
✗ 14:32:05 fs/delete_file 12ms c3d9f012
✓ 14:32:08 github/merge_pr 456ms e5f6a7b8Cada entrada está firmada con HMAC-SHA256 y encadenada al registro anterior. Si manipulas cualquier entrada, la verificación falla. Si eliminas una entrada, la cadena se rompe.
$ mcp-audit verify ~/.mcp-audit/audit.jsonl
Results:
Total records: 847
Valid: 847
Invalid: 0
All records verified successfully.┌────────────┐ ┌───────────┐ ┌────────────┐
│ MCP Client │──────▶│ mcp-audit │──────▶│ MCP Server │
│ (Claude, │◀──────│ wrap │◀──────│ (any) │
│ Cursor) │ └─────┬─────┘ └────────────┘
└────────────┘ │
▼
~/.mcp-audit/
audit.jsonlEl comando wrap inicia tu servidor MCP como un proceso hijo y se sitúa entre el cliente y el servidor en stdio. Reenvía TODOS los mensajes de forma transparente. Solo las respuestas de tools/call se firman y registran. Todo lo demás pasa sin cambios.
En la primera ejecución, se genera automáticamente una clave de firma en ~/.mcp-audit/key.hex. No se necesita configuración.
{
"id": "bf7a2f62-4d0f-4cce-afd2-cbfbf7bca2a5",
"timestamp": "2026-08-16T14:32:01.000Z",
"method": "tools/call",
"toolName": "github/create_pr",
"args": {"title": "Fix bug", "body": "..."},
"durationMs": 234,
"success": true,
"previousHash": "8a3f2b...",
"attestation": "7c4d9e..."
}La attestation es una firma HMAC-SHA256 sobre los campos canónicos del registro. El previousHash es el SHA-256 del registro anterior. Juntos detectan manipulación, orden y completitud.
claude_desktop_config.json:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["mcp-audit", "wrap", "--", "npx", "@modelcontextprotocol/server-github"]
},
"filesystem": {
"command": "npx",
"args": ["mcp-audit", "wrap", "--", "npx", "@modelcontextprotocol/server-filesystem", "/tmp"]
}
}
}.claude/hooks/mcp-servers.json o directamente en el comando de tu servidor MCP — prefija con mcp-audit wrap --.
mcp-audit wrap -- <cmd> [args] # Wrap any MCP server
mcp-audit tail # Live stream of tool calls
mcp-audit verify <log> # Verify chain integrity
mcp-audit serve [config] # Full gateway (policy + OTel)
mcp-audit keygen [dir] # Generate Ed25519 key pairPara equipos que también necesitan control de acceso, limitación de velocidad y enrutamiento multi-servidor:
mcp-audit serve gateway.config.jsonEl gateway completo añade:
Motor de políticas (ACL basadas en glob, límites de velocidad por principal)
Espaciado de nombres de herramientas entre múltiples servidores MCP ascendentes
Exportación de trazas y métricas OpenTelemetry
Gestión de salud de servidores ascendentes con reconexión automática
Firmas Ed25519 (más fuertes que HMAC, verificación portátil)
Consulta configuración del gateway para el esquema completo.
npm install -g @mcp-audit-gateway/coreEsto instala el CLI mcp-audit globalmente. O úsalo sin instalar:
npx @mcp-audit-gateway/core wrap -- <your mcp server command>El subsistema de firma y verificación va más allá del HMAC por registro. Proporciona evidencia de manipulación a través de rotación de registros, recuperación de fallos y cadenas de múltiples archivos.
Los registros de punto de control permiten que un consumidor detecte truncamiento de cola guardando un solo hash externamente. La cadena continúa a través de rotaciones de archivo (sin reinicios silenciosos). Los reinicios forzados emiten registros chain_break firmados en lugar de comenzar de nuevo silenciosamente.
La forma canónica está etiquetada por tipo y es inyectiva, evita el problema de formato de flotantes de JCS al rechazar números no seguros por completo, y ha demostrado paridad entre lenguajes mediante 46 vectores de conformidad (JS + Python). Consulta SECURITY-DESIGN.md para la especificación completa y el modelo de amenazas.
MCP tiene 10 SDK oficiales y no hay pruebas de conformidad entre SDK. Construimos un arnés diferencial estilo Wycheproof que ejecuta 40 pruebas de casos límite de serialización en los 10 SDK e informa dónde discrepan.
Resultados: 26 divergencias a nivel de cable en 8 serializadores distintos. Seis representaciones diferentes de 1e20. Tres algoritmos de ordenación de claves incompatibles. TypeScript pierde silenciosamente precisión de enteros en 2^53+1. C# escapa caracteres HTML que ningún otro SDK escapa. El SDK de Python produce bytes diferentes entre versiones de pydantic-core para la misma ruta de código.
./test/vectors/cross-sdk-diff.sh # full matrix (stdlib + SDK)
./test/vectors/cross-sdk-diff.sh --layer sdk # SDK-wire-level only
./test/vectors/cross-sdk-diff.sh --json # structured outputLa canonicalización del gateway de auditoría fue diseñada para ser inmune a las 26 clases de divergencia: solo enteros seguros, orden de campos explícito, rechazo de sustitutos. Consulta SDK-AUDIT.md para la tabla completa de divergencias y la metodología.
Esta implementación satisface las siguientes propiedades (verificadas mediante vectores de conformidad entre lenguajes y pruebas unitarias):
Forma canónica inyectiva (sin colisiones de resumen entre tipos)
Equivalencia de ordenación entre lenguajes (orden de unidades de código UTF-16)
Rechazo de sustitutos no emparejados
Continuidad de la cadena de hash a través de rotación de registros
Detección de estado plantado al inicio
Sin falsos positivos después de una ruptura de cadena legítima
Cierre seguro ante entrada corrupta o demasiado grande
Monotonicidad segmentada en los límites de chain_break
Completitud anclada al consumidor mediante registros de punto de control
Inicialización con memoria limitada (tope de 1MB)
Conformidad APS action-ref-v1: 51/51 vectores aprobados (recomputación JCS + comparación de resumen con cierre seguro).
npm test # unit tests
node test/vectors/verify-checkpoint.mjs # JS conformance vectors
python3 test/vectors/verify-checkpoint.py # Python conformance vectors
node test/vectors/aps-action-ref-v1.mjs # 51 APS vectors
./test/vectors/cross-sdk-diff.sh # 10-SDK differential testMIT
Los fixtures de conformidad APS (test/vectors/aps-action-ref-v1-vectors.json)
están adaptados de fuentes upstream con licencia Apache-2.0. Consulta
test/vectors/SOURCE.md para la procedencia y los términos.
Report current audit chain health: total records, last verified timestamp, chain integrity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully indicates the tool reports total records, last verified timestamp, and chain integrity, and 'Report' implies a read-only snapshot. However, it does not explicitly state side-effect-freedom, failure behavior, or what 'chain integrity' means operationally.
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 sentence that front-loads the action and resource, then concisely lists the three report contents. There is no redundant or wasted text.
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 parameterless status tool, the description is nearly complete: it names the purpose and the expected output fields. It lacks sibling-selection guidance, but the low complexity and zero-parameter signature make that a relatively small 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?
The tool has zero parameters, so the baseline is 4. The description adds value by clarifying what the status report contains, which is the only semantic information needed for a parameterless tool.
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 verb and resource: 'Report current audit chain health.' It also enumerates the report contents, making the tool's purpose unambiguous. However, it does not explicitly distinguish this tool from the sibling tools audit_verify and audit_tail.
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?
No usage guidance is provided. The description does not mention when to use audit_status versus audit_verify or audit_tail, nor does it state any exclusions or prerequisites. Selection among siblings is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the most recent audit log entries with verification status.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of entries to return (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Show' implies a non-destructive read operation, but the description does not explicitly state read-only behavior, permissions, or any other side effects or limitations. Minimal behavioral context is disclosed.
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?
A single sentence that front-loads the core action and resource with no filler or redundancy. Every word earns its place.
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 tool with one optional parameter and no output schema, the description sufficiently communicates what is returned (recent audit log entries with verification status). It lacks sibling routing and caveats, but is functionally complete for the simple use case.
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% for the single 'count' parameter, which already includes its default value. The tool description itself adds no additional meaning about the parameter, so the baseline score of 3 applies.
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 uses a specific verb ('Show'), a clear resource ('audit log entries'), and a scope qualifier ('most recent'), while adding a distinctive output feature ('verification status'). This differentiates it from siblings like audit_verify and audit_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 implies usage for viewing recent audit logs but provides no explicit guidance on when to use this tool over audit_verify or audit_status. There are no alternatives or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify integrity of an MCP audit log. Returns chain status and any broken links.
| Name | Required | Description | Default |
|---|---|---|---|
| logPath | Yes | Path to the audit log file (JSONL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does disclose that the tool returns chain status and broken links, which is valuable, but it does not mention whether the operation is read-only, if there are side effects, or how failures are reported.
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 two concise sentences with no filler. The core action is front-loaded, and the return behavior is stated immediately after, making it easy to scan.
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 single-parameter tool with no output schema, the description gives the essential purpose and return information. It is slightly incomplete on when to choose this over sibling tools, but the overall definition is sufficient for basic invocation.
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 only parameter, logPath, is already described in the schema as 'Path to the audit log file (JSONL)'. The tool description adds no additional parameter-level detail, so the schema provides the necessary semantics.
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 uses a specific verb ('Verify integrity') with a clear resource ('MCP audit log') and states the outcome ('Returns chain status and any broken links'). It clearly distinguishes this from sibling tools like audit_tail and audit_status, which have different operational purposes.
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?
No explicit guidance is provided on when to use this tool versus audit_tail or audit_status. The description only states what the tool does, leaving the agent to infer the appropriate selection context without any exclusions or alternatives.
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.
audit_statusaudit_tailaudit_verifyThis server cannot be deployed
Scored across 3 tools
audit_tail is clearly distinct, showing recent entries. audit_verify and audit_status overlap somewhat in reporting integrity, but verify focuses on running a chain verification while status provides a summary snapshot.
All tools share the consistent audit_ prefix and lowercase single-word suffixes. The suffixes mix a verb (verify), a command-style word (tail), and a noun (status), but the pattern remains predictable.
Three tools is well-scoped for an audit gateway surface. Each tool covers a distinct aspect of interacting with the audit log without unnecessary bloat.
The set covers the core audit operations: verifying integrity, tailing recent entries, and reporting chain health. It lacks operations like fetching a single entry or exporting records, but those are reasonable minor gaps.
Signed, publicly logged records of what your AI agent did, with proofs anyone can check offline.
Bitcoin-anchored, tamper-evident audit log for AI agents — record, disclose and verify actions.
Signed, append-only receipts of an AI agent's decisions and outcomes, with public proof links.
Hash-chained HMAC-signed audit log MCP for A2A (agent-to-agent) calls. Every tool-call, agent-ha...