Skip to main content
Glama

English | 한국어

DoneProof MCP

CI Python 3.11+ License: MIT

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 observed and attested provenance

  • Append-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 stdio

For source development:

git clone https://github.com/efficjump/doneproof-mcp.git
cd doneproof-mcp
uv sync --all-extras --locked
uv run doneproof-mcp --transport stdio

Generic 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

create_task, list_tasks, get_task

Criteria

derive_criteria, set_criteria

Verification

discover_verifiers, prepare_verification, execute_verification

Evidence

record_file_evidence, record_attestation

Decision

assess_completion, build_proof_report

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 8767

The 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 build

See architecture, security policy, and contribution guide.

License

MIT

Available Tools

12 tools
assess_completionB
Read-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_verificationB
Destructive

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_taskA
Read-only

Return task, active criteria, verifier profile, evidence, and current assessment.

Inputs: task_id (required). Returns: object

list_tasksA
Read-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

    A3.8/5.0

    Scored across 12 tools

    Disambiguation5/5

    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.

    Naming Consistency5/5

    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.

    Tool Count5/5

    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.

    Completeness4/5

    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

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers