DoneProof MCP
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., "@DoneProof MCP derive acceptance criteria for implementing user authentication"
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.
English | 한국어
DoneProof MCP
Convert an implementation objective into explicit acceptance criteria and a fresh, traceable evidence matrix. Completion is derived from active policies, current workspace fingerprints, and an intact hash-linked ledger—not from model confidence.
flowchart LR
A[Implementation objective] --> B[Reviewable criteria draft]
B --> C[Activated evidence policy]
C --> D[Discovered verifiers]
D --> E[Approved verification]
E --> F[Hash-linked evidence]
F --> G{Fresh and sufficient?}
G -->|Yes| H[Complete]
G -->|No| I[Failed or insufficient]Highlights
Host-model criterion proposals that remain drafts until explicitly activated
Evidence policies with required kinds and minimum pass counts
Dynamic verifier discovery from current project manifests
One-time approvals for direct argv verification commands
Workspace fingerprints that make old evidence visibly stale
Separate
observedandattestedprovenanceAppend-only SHA-256-linked evidence ledger with tamper detection
Deterministic completion assessment and Markdown proof reports
Related MCP server: Spec Kit Acceptance Gate MCP
Install
uv tool install "git+https://github.com/efficjump/doneproof-mcp.git"
doneproof-mcp --transport stdioFor source development:
git clone https://github.com/efficjump/doneproof-mcp.git
cd doneproof-mcp
uv sync --all-extras --locked
uv run doneproof-mcp --transport stdioGeneric MCP client configuration
{
"mcpServers": {
"doneproof": {
"command": "doneproof-mcp",
"args": ["--transport", "stdio"]
}
}
}No local checkout path is required after tool installation.
Tool workflow
Stage | Tools |
Task state |
|
Criteria |
|
Verification |
|
Evidence |
|
Decision |
|
record_file_evidence returns unknown unless an expected SHA-256 is supplied. File existence alone
does not prove semantic correctness. Manual review remains explicitly labelled as attestation.
Safety model
Project roots are constrained by
DONEPROOF_ALLOWED_ROOTS.Verifier commands must come from current project discovery.
Commands use argv execution, output limits, timeouts, and one-time plan tokens.
Workspace-writing commands need separate approval.
User text and command output are redacted before persistence.
Invalid or tampered evidence ledgers reject further appends.
This server is not an operating-system sandbox. Use an isolated environment for untrusted projects.
Streamable HTTP
doneproof-mcp --transport streamable-http --host 127.0.0.1 --port 8767The default endpoint is http://127.0.0.1:8767/mcp.
Development
uv sync --all-extras --locked
uv run ruff format --check .
uv run ruff check .
uv run mypy src
uv run pytest --cov --cov-report=term-missing
uv buildSee architecture, security policy, and contribution guide.
License
Available Tools
12 toolsassess_completionBRead-only
Compute completion from fresh evidence policies and ledger integrity.
Inputs: task_id (required). Returns: object
build_proof_reportB
Write a Markdown proof report containing the matrix and hash-linked evidence ledger.
Inputs: task_id (required). Returns: object
create_taskB
Create a bounded task and persist a redacted objective.
Inputs: name (required), objective (required), project_root (required). Returns: object
derive_criteriaA
Ask the host model for observable criteria and persist only a draft proposal.
Inputs: task_id (required). Returns: object
discover_verifiersA
Derive verifier argv and working directories from live project manifests.
Inputs: task_id (required). Returns: object
execute_verificationBDestructive
Consume one token, run the candidate verifier, and append observed command evidence.
Inputs: plan_id (required), task_id (required), approval_token (required), allow_workspace_write. Returns: object
get_taskARead-only
Return task, active criteria, verifier profile, evidence, and current assessment.
Inputs: task_id (required). Returns: object
list_tasksARead-only
List persisted proof tasks without reading their projects.
Inputs: no named parameters. Returns: result
prepare_verificationA
Create an evidence-linked verifier plan and a one-time execution token.
Inputs: task_id (required), verifier_id (required), criterion_ids (required), timeout_seconds, +1 more. Returns: object
record_attestationA
Record a human-reviewed claim, explicitly labelled as attested rather than observed.
Inputs: kind (required), result (required), summary (required), task_id (required), +2 more. Returns: object
record_file_evidenceB
Hash a project file; only an explicit expected hash produces observed pass or fail.
Inputs: task_id (required), criterion_ids (required), relative_path (required), expected_sha256. Returns: object
set_criteriaA
Replace active criteria with the user-reviewed statements and evidence policies.
Inputs: task_id (required), criteria (required). Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 12 tools
Each tool targets a distinct action in the proof workflow: task creation/retrieval, criteria derivation/setting, verifier discovery/preparation/execution, evidence recording variants, assessment, and report building. Even the two record_* tools are clearly separated by evidence source type: human attestation vs. file hashing.
All tool names follow a consistent snake_case verb_noun pattern, such as create_task, get_task, set_criteria, execute_verification, and build_proof_report. The naming makes the action and object immediately clear with no style mixing.
Twelve tools is well within the ideal range for a domain of this complexity. Each tool covers a meaningful step in the proof lifecycle without redundant or filler operations.
The tool surface covers the core lifecycle: task creation/read, criteria draft and activation, verifier discovery, verification preparation/execution, multiple evidence types, completion assessment, and report generation. Minor gaps exist around explicit task update/delete operations, but those may be intentionally omitted to preserve proof integrity.
Maintenance
Related MCP Connectors
Tamper-evident SHA-256 hash-chained decision notary for EU AI Act, NIST AI RMF & SOC2.
MCP-native AI evaluation: rubric audits, eval suites, and proof reports for AI/LLM output.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Policy-aware AI execution, verification, cost, and trajectory evidence for agents.
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.744 PyPIApache 2.0
- FlicenseNot gradedqualityDmaintenanceEnables spec-driven development acceptance gate with structured receipts, audit logs, and reviewer-ready evidence.-
- AlicenseAqualityCmaintenanceEnables traceable requirement discovery, technical alignment, and ISO-aligned process checking through deterministic MCP tools and resources, without requiring an embedded LLM.41Apache 2.0
- FlicenseNot gradedqualityDmaintenanceEnforces protocol-driven development by validating requirements, designs, scope, and acceptance evidence, while maintaining immutable, traceable governance archives.-