あなたの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フルゲートウェイは以下を追加します：
ポリシーエンジン（グロブベースの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 の6つの異なる表現。3つの互換性のないキー順序アルゴリズム。TypeScriptは2^53+1で整数精度を静かに失います。C#は他のSDKがエスケープしない文字をHTMLエスケープします。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...
