execution-proofs
Use this MCP server to verify that an AI agent's claimed output files actually exist and are fresh enough.
Verify completion claims by extracting path-like tokens from claim text.
Check file existence under search_roots; absolute paths outside are out_of_scope.
Relocate missing files by leaf filename under search_roots, ignoring node_modules, .git, _backup.
Enforce freshness with since_minutes and task_started_at; stale files yield STALE.
Return verdicts: NO_CLAIM, PSEUDO_DONE, STALE, TRUE_DONE with item counts.
Does not judge file contents, only existence and freshness.
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., "@execution-proofsCan you verify my claim that the output file result.jsonl was actually generated in the last half hour?"
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.
Execution Proofs
Execution Proofs is a local MCP server that verifies whether an AI agent's completion claim is source-bound to real output artifacts at runtime. It checks the existence of claimed files and, when requested, whether those files were modified within a freshness window.
The core verifier supports both ESM import and CommonJS require consumers.
Positioning: Execution Proofs is a lightweight physical telemetry gate. It checks that claimed files exist, and that they are fresh. It does not judge whether the contents are right.
Tool / pattern | Primary layer | What it catches | Execution Proofs difference |
Guardrails | Soft semantic filtering | Policy or format violations in model output | Runtime hard artifact verification: claimed files must exist and optionally be fresh. |
DeepEval | Test-time evaluation | Quality regressions measured by evaluation cases | Runtime gate for completion claims, independent of offline eval suites. |
soplint | Static behavior checks | Process or SOP drift before or around execution | Runtime proof that claimed output artifacts are physically present. |
AgentLiar | Static diff analysis + optional LLM judge | Placeholders / weak tests / scope-narrowing inside a supplied git diff | It checks that claimed files exist, and that they are fresh. It does not judge whether the contents are right. AgentLiar requires an externally supplied diff and has no file-existence check. |
MCP Usage
Build once:
npm install
npm run buildAdd the server to an MCP client configuration:
{
"mcpServers": {
"execution-proofs": {
"command": "node",
"args": [
"<repo>/dist/server.js"
]
}
}
}The server exposes one tool:
{
"name": "verify_claim",
"arguments": {
"claim_text": "Done: C:\\AIWFF\\outbox\\result.jsonl",
"search_roots": ["C:\\AIWFF"],
"since_minutes": 30,
"task_started_at": "2026-06-12T08:40:00.000Z"
}
}Response shape:
{
"verdict": "TRUE_DONE",
"total": 1,
"bound": 1,
"relocated": 0,
"unbound": 0,
"stale": 0,
"out_of_scope": 0,
"items": []
}Verdicts:
NO_CLAIM: no path-like output artifact token was found.PSEUDO_DONE: at least one claimed artifact could not be source-bound, or an absolute path is outsidesearch_roots.STALE: all in-scope claimed artifacts exist, but at least one is older thansince_minutesor predatestask_started_at.TRUE_DONE: all claimed artifacts exist and pass the optional freshness check.
Related MCP server: TruthGate
What It Checks
Token extraction follows the AIWFF source-binding gate semantics:
absolute Windows paths such as
C:\AIWFF\outbox\result.jsonl(example path, replace with your own)absolute POSIX paths such as
/home/x/out.txtbacktick-wrapped filenames or relative paths that include a path separator or extension, such as
result.jsonloroutbox/result.jsonl
Obvious non-path tokens such as version numbers (1.2.3), short labels (v0), and code symbols are ignored. Tokens in negative contexts such as "未修改 X", "did not touch X", or "no changes to X" are also ignored, because they are not completion claims.
For each token, Execution Proofs first checks the claimed path directly, but only inside search_roots. Absolute paths outside search_roots are marked out_of_scope and are not stat'ed. If an in-scope token does not exist directly, it searches by leaf filename under search_roots, excluding node_modules, .git, and _backup. A relocated match is still considered source-bound.
When since_minutes is greater than 0, a bound file must have an mtime within the last N minutes. Older files become stale.
When task_started_at is supplied as an ISO timestamp, a bound file must have an mtime at or after that baseline. Files older than the task baseline become stale, even if they are within the rolling since_minutes window.
Honest Boundary
Execution Proofs verifies whether claimed output artifact files really exist and whether they are fresh enough. It does not verify that file contents are correct, useful, safe, complete, or semantically aligned with the task. Content correctness still needs tests, review, semantic evaluation, or domain-specific validators.
It also proves existence at check time, not throughout. If an artifact was produced and then deleted, overwritten, or moved before the check, the gate sees only "not present now" and cannot distinguish that from "never produced". For workflows where that gap matters, stamp a receipt (path + content hash + timestamp) at production time and reconcile against it later. An opt-in mode, deliberately kept out of the zero-config core.
It can be deliberately bypassed. An agent can change its claim format, avoid mentioning paths, or otherwise omit artifact tokens so the gate has nothing concrete to verify.
Container, VM, and host filesystem isolation can produce false negatives. If the agent writes artifacts inside an isolated environment but Execution Proofs runs on the host, the host-side check may not see those files and may incorrectly mark the claim unbound.
Development
npm install
npm testRelated. The discipline toolchain
Part of a small set of tools for making AI agents finish work and stay disciplined. Engine + guardrails:
aiwff-runtime. The local agent runtime (the engine that runs disciplined agents)
soplint. Static SOP-compliance audit for AI work nodes
execution-proofs. MCP telemetry gateway: force agents to prove "done" with real files and timestamps (this repo)
引擎(跑得動的 agent)+護欄(審紀律、逼證明),同一套「讓 AI 守紀律」哲學的兩面。
Beyond the gate
This tool catches one shape of failure: a completion claim that isn't bound to a real file.
There are other shapes it cannot see, and they are quieter:
a health check whose predicate is structurally impossible to satisfy, so the ring stays yellow forever and everyone assumes the work just isn't done yet
a writer and a reader using different fields or different channels, so one column is silently null for weeks
an alert rule whose "false positive" branch requires a state the subject can never be in at first observation, so it fires every single time
a green dashboard where the checker itself returned null and null compared as pass
None of these surface as errors. They surface as nothing at all. That is why they survive for months.
We hit all four while building our own agent system, and we keep a catalogue of the shapes with the mechanical root cause for each. If your agents report success and your dashboards are green, but you cannot actually prove the work happened. Open an issue and describe what you're seeing. A rough description is fine; these cases are hard to put into words, which is exactly why they survive.
Two other things you're welcome to open an issue for:
Drop a repo link and ask what it actually does, and whether it's worth adopting. We check whether it is alive. Recent commits, whether issues get answered, whether anything actually depends on it. That is instead of just restating the README. If it looks abandoned, we'll say so.
Tell us about a silent failure shape we haven't catalogued. New shapes are genuinely useful to us, and we'll add them here with credit.
授權是 MIT。不在這頁寫價格,也不在這頁賣稽核服務。
Available Tools
1 toolverify_claimC
Verify whether claimed output artifacts exist and optionally whether they are fresh enough.
| Name | Required | Description | Default |
|---|---|---|---|
| claim_text | Yes | Completion claim text that may contain artifact paths or backtick-wrapped filenames. | |
| search_roots | No | Roots used to relocate missing claimed paths by leaf filename. Defaults to current working directory. | |
| since_minutes | No | Freshness window in minutes. 0 disables freshness checks. | |
| task_started_at | No | Optional ISO timestamp. Claimed artifacts older than this baseline are stale. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not state whether the tool returns a boolean, throws errors, or what happens on missing artifacts. It also omits auth or permission needs, which is important for a verification tool.
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, clear sentence that immediately conveys the core function. It is front-loaded and efficient, though could be improved with structured details.
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 output schema, the description should explain return behavior, but it does not. For a 4-parameter tool, the description lacks details on how verification results are presented (boolean, list, etc.) and other edge cases.
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 the baseline is 3. The description adds minimal context ('existence' and 'freshness') beyond the schema, but does not elaborate on parameter semantics or usage nuances.
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 clearly states the tool verifies existence and freshness of claimed output artifacts. It uses a specific verb-resource pair ('verify claimed output artifacts'), which is unambiguous. However, without sibling tools, differentiation is not tested.
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 on when to use this tool versus alternatives, nor any prerequisites or when-not-to-use. The description only implies usage context ('to verify claims'), which is minimal guidance.
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.
1 tool update
v0.1.0- First observed
verify_claim
TDQS
Scored across 1 tool
Only one tool exists, so there is no risk of ambiguity. The tool's purpose is clearly defined.
The single tool uses a clear verb_noun pattern with snake_case, which is consistent with common conventions.
Having only one tool for a server named 'execution-proofs' feels insufficient. Most servers in this domain would have multiple tools for different operations, making this count too low for the apparent scope.
The tool set is severely incomplete for execution proofs. It only verifies claims but lacks tools to submit proofs, create claims, list proofs, or manage any lifecycle, leading to dead ends for agents.
Maintenance
Related MCP Connectors
Verifies AI agent work end to end: real artifacts and outcomes checked, not self-reported success.
Verified AI-agent outcomes: secret scanning, JSON cleanup, dedupe, anomaly and schema checks.
Watchdog for unattended AI agents: alerts, evidence checks and a verifiable proof per run.
Verify AI work against criteria and get signed receipts. From Spoolis, guarantees for AI work.
Related MCP Servers
- AlicenseCqualityDmaintenanceEnables acceptance gates for AI coding-agent runs by recording evidence, running deterministic validation, applying a quality gate, and rendering auditable outcomes.7Apache 2.0
- AlicenseCqualityBmaintenanceA fail-closed preflight, approval, evidence, and verification runtime for agents, preventing unsupported output from being treated as verified completion.3MIT
- FlicenseNot gradedqualityCmaintenanceVerifies AI agent actions by exercising public web surfaces and returning evidence-based pass/fail verdicts on real outcomes, rather than trusting self-reported success messages.-
- AlicenseAqualityCmaintenanceAudits coding agents' claimed actions against the actual Git working tree, blocking completion if any claimed changes are unverified.2MIT