Captures read-only Git repository state, including current branch, HEAD commit, and working tree cleanliness, so evidence bundles can be verified against the repository state.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Evidence MCP create an evidence bundle for the auth refactor, capture git state, and hash the changed files"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Verifiable evidence collection and validation MCP server for AI coding agents.
Replace unverified agent claims ("Tests pass", "Bug fixed") with tamper-evident, reproducible proof.
Modern AI coding agents frequently output declarations like:
"I have executed the test suite and all 42 tests passed."
"I fixed the null pointer bug in auth.ts."
"The repository working tree is clean and ready to deploy."
In practice, agents may hallucinate command outputs, report results from outdated runs, or edit files without running the necessary verifications. Human reviewers and downstream agents have no systematic way to distinguish authentic execution results from plausible text assertions.
Related MCP server: action-ledger
Evidence MCP introduces the Evidence Bundle pattern. Instead of trusting raw text claims, coding agents assemble a structured, machine-verifiable audit trail stored locally in the workspace:
Git State Capture: Snapshots commit hashes, current branch, and clean status without mutating repository state.
Command Recording: Logs exact commands, exit codes, stdout, and stderr from executions previously conducted by the agent.
File Snapshots & Hashes: Computes SHA-256 hashes and file byte sizes within strict workspace boundaries.
Substantiated Assertions: Requires every claimed achievement to be backed by at least one valid evidence reference.
Freshness & Integrity Verification: Allows reviewers or subsequent agents to re-evaluate the bundle against disk state. If any tracked file is modified or deleted, or if the Git branch/HEAD has moved, the bundle is instantly flagged as stale or failed.
+-------------------------------------------------------------+
| EVIDENCE BUNDLE |
| - Task: "Refactor total discount calculation" |
| - Status: verified | stale | failed |
+-------------------------------------------------------------+
| | |
v v v
+--------------+ +---------------+ +--------------+
| Git State | | Command Logs | | File Hashes |
| - Branch | | - Exit Code | | - SHA-256 |
| - HEAD SHA | | - stdout | | - File Size |
| - Status | | - stderr | | - Path |
+--------------+ +---------------+ +--------------+
\ | /
\ | /
+---------------------+-------------------+
|
v
+-----------------------+
| Assertions & Claims |
| (Must link to proofs) |
+-----------------------+All data is stored locally in human-readable JSON files inside the workspace root:
<workspace>/
├── .evidence-mcp/
│ ├── .gitignore # Automatically ignores .evidence-mcp/ from Git
│ └── bundles/
│ └── bundle_<id>.json # Individual evidence bundle fileZero Remote Dependencies: Operates entirely offline with standard Node.js runtime.
Atomic Writes: Bundle updates are written to temporary files and renamed atomically to prevent corrupted files.
Clean Git Integration: The .evidence-mcp/ folder creates its own internal .gitignore so bundle persistence never pollutes repository status.
Evidence MCP provides seven focused tools through the Model Context Protocol:
Tool | Purpose | Key Inputs | Output |
| Initializes a new evidence bundle for a task |
|
|
| Safely records Git HEAD, branch, and status |
|
|
| Logs the result of a previously executed command |
|
|
| Computes SHA-256 and size for target files |
|
|
| Attaches a claim linked to supporting evidence |
|
|
| Validates file hashes and Git state against disk |
|
|
| Generates a shareable Markdown or JSON report |
| Formatted report ready for PR or handoff |
Here is how an agent interacts with Evidence MCP during a coding assignment:
// Call: create_evidence_bundle
{
"task": "Add email validation to user registration schema",
"workspacePath": "/path/to/project"
}Returns: { "bundleId": "bundle_9a41f0bc", "status": "in_progress" }
// Call: capture_git_evidence
{
"bundleId": "bundle_9a41f0bc"
}Returns: { "evidenceId": "git_7b2e11d0", "branch": "feat/email-validation", "headCommit": "4f9d2a1...", "isClean": true }
// Call: snapshot_files
{
"bundleId": "bundle_9a41f0bc",
"paths": ["src/validators/email.ts", "test/email.test.ts"]
}Returns:
{
"snapshots": [
{
"evidenceId": "file_81c4e101",
"path": "src/validators/email.ts",
"sha256": "5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8",
"sizeBytes": 482
}
]
}// Call: record_command_result
{
"bundleId": "bundle_9a41f0bc",
"command": "npm test -- email.test.ts",
"exitCode": 0,
"stdout": "PASS test/email.test.ts\n✓ validates standard emails (12ms)\n✓ rejects missing TLD (4ms)",
"stderr": ""
}Returns: { "evidenceId": "cmd_43a0e991", "exitCode": 0 }
// Call: add_assertion
{
"bundleId": "bundle_9a41f0bc",
"claim": "Email validation logic implemented and passes all unit tests",
"evidenceIds": ["file_81c4e101", "cmd_43a0e991", "git_7b2e11d0"]
}Notice: Submitting claims without supporting evidence IDs is strictly rejected.
// Call: verify_evidence_bundle
{
"bundleId": "bundle_9a41f0bc"
}Returns:
{
"status": "verified",
"summary": "All 3 evidence items and assertions are verified and fresh.",
"reasons": [],
"items": [...]
}// Call: export_evidence_report
{
"bundleId": "bundle_9a41f0bc",
"format": "markdown"
}Returns a structured GitHub Flavored Markdown report ready to paste directly into a PR description or issue.
Zero Telemetry & Tracking: Evidence MCP contains no analytics, telemetry, or network calls.
Strict Path Sandboxing: Prevents path traversal (../) and verifies that every snapshotted file strictly resides within the declared workspacePath.
Sensitive File Blocklist: Automatically blocks snapshotting of secret files:
Environment variables: .env, .env.* (e.g., .env.local, .env.production)
Private keys: id_rsa, id_ed25519, *.pem, *.key, *.pfx, *.p12
Secrets and credentials: credentials.json, service-account*.json, token.json
VCS & auth configs: .git/config, .npmrc, .pypirc
Safe Read-Only Git: Uses strict execFile without shell invocation and only runs non-mutating Git inspection commands (status, rev-parse, diff --check).
Node.js >= 20.0.0
Git >= 2.25.0
git clone https://github.com/mokashreef/Evidence-MCP.git
cd Evidence-MCP
npm install
npm run buildAdd Evidence MCP to your client configuration file:
{
"mcpServers": {
"evidence-mcp": {
"command": "node",
"args": ["/absolute/path/to/Evidence-MCP/dist/cli.js"]
}
}
}Or run directly with npx after linking:
{
"mcpServers": {
"evidence-mcp": {
"command": "npx",
"args": ["-y", "evidence-mcp"]
}
}
}# Typecheck
npm run typecheck
# Run test suite
npm test
# Run tests in watch mode
npm run test:watch
# Compile TypeScript
npm run buildLocal file persistence under .evidence-mcp/bundles/.
Safe Git state capture (read-only).
Recording command outputs provided by the agent.
Workspace-confined SHA-256 file snapshots.
Mandatory evidence-linked assertions.
Live verification of file hashes and Git status.
Markdown and JSON report exporting.
Direct Shell Command Execution: In v0.1, record_command_result records results provided by agents. The server does not execute arbitrary shell strings from client inputs.
Remote Publishing / Cloud Syncing: Evidence bundles are local to the workspace. There is no auto-pushing to remote cloud APIs or external issue trackers.
Cryptographic Signatures (PKI): Bundles rely on SHA-256 content hashes and Git commit trees; asymmetric GPG/Ed25519 bundle signing is reserved for v0.2.
v0.2: Containerized sandbox execution runner for reproducible verification.
v0.3: Asymmetric cryptographic signatures for bundle author attestation.
v0.4: Multi-workspace support for cross-repository monorepo changes.
v0.5: Diff-level syntax tree (AST) evidence capturing.
This project is licensed under the MIT License.
Links a stated claim to one or more supporting evidence IDs. Rejects assertions with zero evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | The claim or statement being asserted. | |
| bundleId | Yes | The unique identifier of the evidence bundle. | |
| evidenceIds | Yes | Array of evidence IDs (git, cmd, file) that substantiate the claim. | |
| workspacePath | No | Optional workspace path hint. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose one real behavior — assertions with zero evidence are rejected — but says nothing about whether this mutates the bundle, requires prior evidence capture, permissions, or idempotency for duplicate claims.
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 sentences, zero filler, action stated first and the constraint second. Nothing could be cut without losing information.
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?
A complete parameter schema and no output schema keep requirements modest, but for an unannotated write-ish operation the description should say what the added assertion affects in the bundle and what happens on success. It is adequate rather than sufficient.
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 100%, so all four parameters are already documented, including minItems=1 on evidenceIds. The description's 'one or more supporting evidence IDs' merely restates the schema and adds no new semantics such as ID format or ordering rules.
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?
Specific verb (links) plus resource (claim → evidence IDs), which is clear on its own. It doesn't differentiate itself from siblings like create_evidence_bundle or capture_git_evidence, though the evidence-ID linkage implicitly places it downstream of those.
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 statement of when to use this versus creating or verifying a bundle, and no prerequisites such as 'evidence must exist first'. The only usage-like content is the rejection rule, which is a constraint rather than guidance on choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Safely inspects and captures Git state (status, branch, HEAD commit, diff check) without mutating the repo.
| Name | Required | Description | Default |
|---|---|---|---|
| bundleId | Yes | The unique identifier of the evidence bundle. | |
| workspacePath | No | Optional workspace path hint if running outside default cwd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the tool is safe and non-mutating ('without mutating the repo'), but it does not describe permissions, failure behavior, or what happens if the workspace is not a Git repository.
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 front-loaded sentence with zero wasted words. The most important constraints, Git capture and non-mutation, appear immediately.
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?
The description is adequate for a two-parameter tool with full schema coverage, but with no annotations and no output schema it should say more about what is returned or how the captured state is represented. It is minimally viable rather than complete.
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 both parameters are already documented in the input schema. The description does not add meaning about bundleId or workspacePath beyond what the schema provides, so the baseline 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 states a specific verb and resource: it inspects and captures Git state, and it enumerates the relevant Git fields (status, branch, HEAD commit, diff check). It does not explicitly differentiate itself from siblings such as snapshot_files or record_command_result, so it is clear but not fully differentiated.
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 gives no explicit guidance on when to use this tool versus alternatives like snapshot_files, record_command_result, or create_evidence_bundle. Usage is only implied by the phrase 'captures Git state' and the mention of an evidence bundle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new evidence bundle for a task and workspace with in_progress status.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The task or objective being addressed by the agent. | |
| metadata | No | Optional key-value metadata. | |
| workspacePath | Yes | Path to the workspace root directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the resulting status (in_progress), but omits the return value (presumably a bundle identifier needed by downstream calls), duplicate/conflict behavior, and any permission requirements.
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 with zero filler, and the key facts (resource, scope, resulting status) are front-loaded. Nothing is repeated from the title or wasted.
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?
With no annotations and no output schema, the description should say what a successful call returns (e.g., the new bundle's identifier) since the agent needs it for add_assertion, verify_evidence_bundle, and other siblings. That information is entirely absent, as is any error/failure behavior.
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 all three parameters (task, workspacePath, metadata) are already documented. The description adds only the implicit link between task/workspace and the created bundle, and says nothing about the nested metadata object beyond what the schema states; baseline 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?
States a specific verb and resource (create -> evidence bundle) plus the initial lifecycle state, so the agent knows exactly what is produced. It does not explicitly contrast with siblings like verify_evidence_bundle or add_assertion, but the create-vs-verify distinction is unambiguous from the verb.
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 says nothing about when to call this versus the sibling tools: no mention that it is the entry point before add_assertion/record_command_result, no prerequisite that a task and workspace must already exist, and no guidance on what to do if a bundle already exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produces a comprehensive evidence report in Markdown or JSON format suitable for pull requests, issues, or handoffs.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format: "markdown" or "json". | markdown |
| bundleId | Yes | The unique identifier of the evidence bundle to export. | |
| workspacePath | No | Optional workspace path hint. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. 'Produces' leaves ambiguous whether the report is returned inline or written to disk, whether the operation has side effects, and what happens with the workspacePath hint. Only the format enum is conveyed.
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 front-loaded sentence with no filler, leading with the action and resource. It is efficient, though it trades away the depth that a mutation-free-but-ambiguous tool might warrant.
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 three-parameter tool with no annotations and no output schema, the description is functional but thin. It never clarifies the return behavior (inline content vs. file write) or that the bundle must pre-exist, which are the main things an agent needs beyond the well-documented schema.
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 100%, so bundleId, format, and workspacePath are all documented in the schema, making the baseline 3. The description's mention of Markdown/JSON largely restates the enum parameter and adds nothing about bundleId or the workspacePath hint.
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 ('Produces') and resource ('evidence report') and enumerates the two formats it emits. It doesn't explicitly contrast with siblings like create_evidence_bundle or verify_evidence_bundle, so the agent must infer that export happens on an existing bundle rather than creating one.
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 usage context ('suitable for pull requests, issues, or handoffs'), which implies why you'd choose this tool. However, it names no alternative and states no prerequisites (e.g., that a bundle must already exist via create_evidence_bundle), so the when-not guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Records the execution result of a command previously run by an agent (does not execute shell commands).
| Name | Required | Description | Default |
|---|---|---|---|
| stderr | Yes | The standard error captured from the command. | |
| stdout | Yes | The standard output captured from the command. | |
| command | Yes | The exact command string that was executed. | |
| bundleId | Yes | The unique identifier of the evidence bundle. | |
| exitCode | Yes | The exit code returned by the command execution. | |
| workspacePath | No | Optional workspace path hint. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior on its own. It usefully states that the tool records rather than executes commands and depends on a previously run command, but it does not describe persistence, permissions, overwrite behavior, or how the result relates to an evidence bundle.
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 front-loaded sentence with no wasted words. The key clarification that it does not execute shell commands is placed immediately after the main action.
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?
The input schema is fully described and there is no output schema, so return values need not be covered. Still, for a mutation-like recording tool with no annotations, the description omits important context such as how the recorded result joins or affects an evidence bundle.
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 all six parameters are documented in the schema. The description adds no parameter-level details beyond the schema, so the baseline of 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 uses a specific verb and resource: recording the execution result of a command previously run by an agent. It also rules out command execution, which prevents a likely misuse. However, it does not explicitly differentiate this tool from sibling evidence-bundle tools such as add_assertion or verify_evidence_bundle.
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 phrase 'previously run by an agent' implies the tool should be used after a command has already been executed elsewhere. The parenthetical clarifies that this tool does not run commands, but there is no explicit guidance on when to use this versus related evidence tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes SHA-256 hashes and file sizes for files strictly inside the workspace. Rejects sensitive files.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | List of file paths relative to workspace root. | |
| bundleId | Yes | The unique identifier of the evidence bundle. | |
| workspacePath | No | Optional workspace path hint. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It usefully discloses the hash algorithm, that sizes are included, the workspace boundary, and that sensitive files are rejected — but does not define 'sensitive', say whether rejection causes failure or skip, or state that this is a read-only operation.
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 tight sentences, zero waste, and the core computation is front-loaded before the scoping constraints. Every sentence 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?
No annotations and no output schema, so the description should explain return shape and failure semantics. It names the outputs (hash, size) but doesn't describe result structure, partial results, or what happens to a call containing a sensitive path.
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 100%, so all three parameters are already documented. The description adds only a constraint on paths (must be strictly inside workspace) and says nothing about bundleId or workspacePath, so 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?
States a specific verb and resource: computes SHA-256 hashes and file sizes for workspace files. Clear and distinct from sibling evidence-bundle tools, though it doesn't explicitly name any sibling or contrast with them.
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 when-to-use guidance, no exclusions, no alternatives. The only constraints mentioned (workspace-scoped, rejects sensitive files) describe behavior, not when an agent should choose this tool over capture_git_evidence or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-checks Git state and file hashes against live workspace. Returns verified, stale, or failed status.
| Name | Required | Description | Default |
|---|---|---|---|
| bundleId | Yes | The unique identifier of the evidence bundle to verify. | |
| workspacePath | No | Optional workspace path hint. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the three possible outcomes (verified, stale, failed), which is genuinely useful. However, it never says whether the operation is read-only or whether verification mutates the bundle's stored state, nor what distinguishes 'stale' from 'failed'.
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 tight sentences with zero filler, and the core action is front-loaded before the outcome list. Every clause 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 two-parameter verification tool with no annotations and no output schema, the description covers the action and the status vocabulary but leaves side effects, failure semantics, and the meaning of the workspace hint unexplained. Adequate but with clear gaps for an agent deciding whether it is safe to call.
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 both bundleId and workspacePath are already documented in the schema. The description adds no meaning about what the optional workspacePath hint changes or how it interacts with the live workspace check; baseline 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?
States a specific verb ('Re-checks') and precise resources ('Git state and file hashes against live workspace'), which clearly separates it from the creation/recording siblings like create_evidence_bundle or capture_git_evidence. It does not name a sibling explicitly, so it stops short of full differentiation.
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 name and 'Re-checks ... an evidence bundle' framing imply this is the post-hoc verification counterpart to bundle creation, but the description never states when to choose it over re-snapshotting or when verification is unnecessary. No alternatives or exclusions are named.
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.0add_assertioncapture_git_evidencecreate_evidence_bundleexport_evidence_reportrecord_command_resultsnapshot_filesverify_evidence_bundleScored across 7 tools
Each tool maps to a distinct action in the evidence lifecycle: create bundle, capture Git state, snapshot files, record command results, add assertions, verify evidence, and export reports. The closest overlap is capture_git_evidence versus verify_evidence_bundle, but one captures live Git state while the other re-checks stored evidence against the workspace, so the boundary is clear.
All tool names use snake_case with a verb-first pattern: add_assertion, verify_evidence_bundle, export_evidence_report, create_evidence_bundle, capture_git_evidence, record_command_result, and snapshot_files. The convention is consistent throughout, with only natural variation in object length.
Seven tools is well within the ideal range for a focused server and each tool supports a clear stage of the evidence workflow. There are no obviously redundant or filler tools.
The surface covers bundle creation, evidence capture from Git, files, and command results, assertion linking, verification, and report export. Minor gaps remain: there is no list/get operation for existing bundles or stored evidence/assertions, and no update/delete/archive path, which may limit discovery and maintenance for long-lived or multiple bundles.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Signed, publicly logged records of what your AI agent did, with proofs anyone can check offline.
Issue & verify signed (ed25519), hash-chained, timestamped provenance receipts for agent actions.
Bitcoin-anchored, tamper-evident audit log for AI agents — record, disclose and verify actions.