你的 AI 代理昨天发起了 847 次工具调用。你能验证它做了什么吗？
为 AI 代理工具调用提供防篡改审计追踪。
之前：
{
"command": "npx",
"args": ["@modelcontextprotocol/server-github"]
}之后：
{
"command": "npx",
"args": ["mcp-audit", "wrap", "--", "npx", "@modelcontextprotocol/server-github"]
}现在每次工具调用都经过加密签名并形成哈希链。其他一切不变。MCP 服务器的工作方式与之前完全相同。
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 e5f6a7b8每条记录都使用 HMAC-SHA256 签名，并与前一条记录链接。篡改任何一条记录，验证就会失败。删除一条记录，链条就会断裂。
$ 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.jsonlwrap 命令将你的 MCP 服务器作为子进程启动，并通过 stdio 位于客户端和服务器之间。它透明地转发所有消息。只有 tools/call 的响应会被签名和记录。其他所有内容都原样通过。
首次运行时，会在 ~/.mcp-audit/key.hex 中自动生成签名密钥。无需任何配置。
{
"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..."
}attestation 是对记录规范字段的 HMAC-SHA256 签名。previousHash 是前一条记录的 SHA-256 哈希。两者共同检测篡改、顺序和完整性。
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 或直接在你的 MCP 服务器命令中——加上 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 pair对于还需要访问控制、速率限制和多服务器路由的团队：
mcp-audit serve gateway.config.json完整网关增加了：
策略引擎（基于 glob 的 ACL、按主体限速）
跨多个上游 MCP 服务器的工具命名空间
OpenTelemetry 追踪和指标导出
上游健康管理，支持自动重连
Ed25519 签名（比 HMAC 更强，可移植验证）
有关完整模式，请参阅 网关配置。
npm install -g @mcp-audit-gateway/core这会将 mcp-audit CLI 全局安装。或者无需安装即可使用：
npx @mcp-audit-gateway/core wrap -- <your mcp server command>签名和验证子系统超越了逐条记录的 HMAC。它提供了跨日志轮转、崩溃恢复和多文件链的防篡改证据。
检查点记录允许消费者通过外部存储单个哈希来检测尾部截断。链在文件轮转时继续向前（不会静默重置）。强制重启会发出签名的 chain_break 记录，而不是悄悄重新开始。
规范形式是类型标记且单射的，通过完全拒绝不安全数字来避免 JCS 的浮点格式化问题，并已通过 46 个一致性向量（JS + Python）证明了跨语言等价性。有关完整规范和威胁模型，请参阅 SECURITY-DESIGN.md。
MCP 有 10 个官方 SDK，但没有跨 SDK 一致性测试。我们构建了一个 Wycheproof 风格的差分测试框架，在全部 10 个 SDK 上运行 40 个序列化边界测试，并报告它们之间的分歧。
结果：8 个不同的序列化器之间存在 26 处线上级分歧。1e20 有六种不同表示。三种不兼容的键排序算法。TypeScript 在 2^53+1 处静默丢失整数精度。C# 会转义其他 SDK 都不转义的字符。Python SDK 在相同的代码路径上，不同 pydantic-core 版本会产生不同的字节。
./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 output审计网关的规范化设计旨在免疫所有 26 类分歧：仅安全整数、显式字段顺序、拒绝代理项。有关完整的分歧表和方法论，请参阅 SDK-AUDIT.md。
此实现满足以下属性（通过跨语言一致性向量和单元测试验证）：
单射规范形式（无跨类型摘要冲突）
跨语言排序等价性（UTF-16 代码单元顺序）
拒绝未配对代理项
日志轮转时哈希链连续性
启动时检测植入状态
合法链断裂后无误报
对损坏或超大输入采取故障关闭
在 chain_break 边界处分段单调性
通过检查点记录实现消费者锚定的完整性
内存受限初始化（1MB 上限）
APS action-ref-v1 一致性：51/51 向量通过（JCS 重新计算 + 故障关闭摘要比较）。
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
APS 一致性测试夹具（test/vectors/aps-action-ref-v1-vectors.json）
改编自上游 Apache-2.0 来源。有关来源和条款，请参阅
test/vectors/SOURCE.md。
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...
