A
licenseA
qualityA
maintenanceEnables verification of AI coding agent self-reports against git diff truth and a deterministic gate, producing pass/regenerate/reject directives to ensure claimed work matches actual changes.
6
AGPL 3.0
did-it
Audits claimed actions (edits, creates, deletes) against the actual Git working tree, verifying which claimed changes are truly present and rejecting those with no evidence.
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., "@did-itverify the changes I claim to have made"
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.
did-it
Stop letting coding agents congratulate themselves.
When a coding agent finishes a task, you review a summary the agent wrote about itself. Research on 5,851 real developer sessions found that those self-reports referred to about one action in eleven — and a reader working from the report alone recovered roughly a fifth of the action log (arXiv:2609.12205).
did-it is the missing gate: an autonomous self-auditing MCP server. The agent must call verify_claimed_actions against your Git working tree before it is allowed to say "Done." Ghost claims are a hard rejection. The user never sees a victory lap that Git cannot back.
Agent finishes coding
↓
.cursorrules mandates verify_claimed_actions
↓
MCP tool checks git status / diff
↓
Ghost claims → 🛑 hard rejection (fix or admit failure)
Verified → ✅ completion allowed30-second verification
git clone https://github.com/preprint-labs/did-it.git
cd did-it
npm install
npm test
npm run build
node dist/index.js --cli --text "I created src/index.ts"You should see a receipts table, an honesty score, and can_report_completion: true|false. Exit code 1 means a ghost claim.
Related MCP server: execution-proofs
Install in Cursor (mcp.json)
Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (user):
{
"mcpServers": {
"did-it": {
"command": "node",
"args": ["<FULL_PATH_TO_DID_IT>/dist/index.js"]
}
}
}Point args at your built dist/index.js. Windows example: "C:\\path\\to\\did-it\\dist\\index.js". In this repo, .cursor/mcp.json uses a relative dist/index.js so no machine-specific absolute path is committed.
The server audits process.cwd() of the host workspace (the project the agent is editing), not the did-it repo itself. Override with DID_IT_WORKSPACE if needed.
2-line rule (paste into .cursorrules)
Before declaring a task complete or outputting your final summary, you MUST call `verify_claimed_actions` with a list of all changes you claim to have made. If any ghost claims are flagged, you must execute the missing changes before responding to the user.Claude Code
claude mcp add did-it -- node "<FULL_PATH_TO_DID_IT>/dist/index.js"Or in ~/.claude.json / project MCP config:
{
"mcpServers": {
"did-it": {
"command": "node",
"args": ["<FULL_PATH_TO_DID_IT>/dist/index.js"]
}
}
}Windows example: "C:\\path\\to\\did-it\\dist\\index.js".
Add the same 2-line rule to CLAUDE.md.
GitHub Copilot (VS Code)
mcp.json in .vscode/mcp.json or your Copilot MCP settings:
{
"servers": {
"did-it": {
"command": "node",
"args": ["<FULL_PATH_TO_DID_IT>/dist/index.js"]
}
}
}MCP tools
Tool | What it does |
| Audit claimed edits/creates/deletes/installs against |
| Raw list of files that actually changed. Use this instead of guessing. |
Hard rejection text:
🛑 [did-it Verification Failed]: You claimed to have completed tasks that have zero evidence in Git: ${ghost_claims}. You are PROHIBITED from reporting completion to the user until these actions are physically executed or explicitly admitted as failed.
honesty_score is verified / (verified + ghost) in [0.0, 1.0]. UNVERIFIABLE rows (e.g. "ran tests" with no artifact) are shown but excluded. can_report_completion is true iff there are zero ghost claims.
CLI fallback
MCP is primary. For a one-off local audit:
node dist/index.js --cli
node dist/index.js --cli --text "I updated src/index.ts and created src/ghost.ts"
echo "created README.md" | node dist/index.js --cli--cli with no claims prints the real uncommitted file list. --root <path> sets the workspace.
Cite
@article{kraishan2026plans,
title = {Plans They Abandon, Reports They Author: The Narrative Layer of Autonomous Agents},
author = {Kraishan, Obada and Jitkajornwanich, Kulsawasd},
journal = {arXiv preprint arXiv:2609.12205},
year = {2026}
}License
MIT
Available Tools
2 toolsinspect_actual_changesA
Return the raw list of files that are actually modified, created, deleted, or untracked in Git. Use this instead of guessing what changed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states that the tool returns raw, actual file changes, which transparently describes the operation and output nature. It does not go into performance or error behavior, but for a simple zero-parameter read tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no redundant phrasing. The core action and result are front-loaded, and the usage hint adds value without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only Git inspection tool, the description covers what the tool returns, the domain, and why it should be used. There is no output schema, but 'raw list' gives enough shape to the return value. Minor details like formatting or execution cost are not essential here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there is nothing for the description to clarify. With schema coverage at 100% and zero parameters, the baseline for this dimension is 4, and the description correctly implies no arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Return') and a clear resource ('raw list of files ... in Git'), and it enumerates the change types (modified, created, deleted, untracked). It is clearly distinct from a generic 'inspect' or 'status' tool, though it does not explicitly differentiate from the sibling verify_claimed_actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this instead of guessing what changed' gives clear contextual guidance: this is the tool to call when you need ground-truth file changes rather than assumptions. It does not name specific alternatives or conditions for when not to use it, but the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_claimed_actionsA
Verify a list of claimed coding actions against the local Git working tree before reporting completion. Call this with every file you claim to have created, edited, deleted, or every package you claim to have installed. Ghost claims are a hard rejection: you must execute the missing work or admit failure before the user sees a completion summary.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| claims | Yes | Actions you claim to have completed, e.g. ["updated src/index.ts", "created README.md", "installed lodash"] |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job: it reveals that verification is against the local Git working tree, that ghost claims cause a hard rejection, and that the agent must complete missing work or admit failure. It does not detail the exact output or failure format, but the behavioral contract is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and every sentence adds meaningful guidance. The description is compact without being vague.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, and the description covers invocation trigger, claim content, and rejection consequences. It could be slightly more complete by describing what the response looks like on success or failure, but the essential context for calling it correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the 'claims' parameter. The description adds value by telling the agent what kinds of claims to include (files created/edited/deleted, packages installed), reinforcing correct usage beyond the schema example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('verify') and resource ('claimed coding actions against the local Git working tree'). It is easy to understand what the tool does, but it does not explicitly distinguish itself from the sibling tool 'inspect_actual_changes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong, explicit guidance on when to use the tool: call it with every claimed created, edited, deleted file or installed package before reporting completion. It does not mention alternatives or when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
inspect_actual_changes - First observed
verify_claimed_actions
TDQS
A4.3/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: one inspects raw Git changes, the other verifies claimed actions against the working tree. No overlap or ambiguity; an agent can easily select the right tool.
Naming Consistency5/5
Both tool names follow a consistent verb_noun pattern: 'inspect_actual_changes' and 'verify_claimed_actions'. The verbs are descriptive and the structure is uniform.
Tool Count4/5
With only 2 tools, the server feels minimal, but its purpose is narrowly scoped to Git verification. The two tools cover the core inspection and verification workflows, so the count is appropriate for the domain, though it edges toward thinness.
Completeness5/5
The tool surface fully covers the server's stated purpose of checking actual Git state and verifying claims against it. There are no obvious dead ends or missing operations for this verification-focused domain; it provides the essential inspect and verify capabilities.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Verifies AI agent work end to end: real artifacts and outcomes checked, not self-reported success.
Git-native policy layer for AI agents: check_action verdicts against rules approved via PR.
Deterministic AI code review, with an audit record. Governance inside the agent loop.
Deterministic operations reconciliation for AI agents: COMPLETE, INCOMPLETE, or NEEDS_REVIEW.
Related MCP Servers
- AlicenseBqualityCmaintenanceVerifies AI agent completion claims by checking that claimed output files exist and are fresh, acting as a lightweight physical telemetry gate.13 npm4MIT
- AlicenseNot gradedqualityDmaintenanceDetects and reports when AI coding agents modify files outside their declared task scope, comparing declared globs and categories with actual changes.MIT
- FlicenseAqualityAmaintenanceEnables coding agents to perform workspace-confined file operations, read-only Git inspection, and structured shell commands, while requiring out-of-band human approval for mutations and external executions and maintaining an audit trail.143-
