DoneProof MCP
**English** | [한국어](README.ko.md)
# DoneProof MCP
[](https://github.com/efficjump/doneproof-mcp/actions/workflows/ci.yml)
[](https://www.python.org/)
[](LICENSE)
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.
```mermaid
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
## Install
```bash
uv tool install "git+https://github.com/efficjump/doneproof-mcp.git"
doneproof-mcp --transport stdio
```
For source development:
```bash
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
```json
{
"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
```bash
doneproof-mcp --transport streamable-http --host 127.0.0.1 --port 8767
```
The default endpoint is `http://127.0.0.1:8767/mcp`.
## Development
```bash
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](docs/architecture.md), [security policy](SECURITY.md), and
[contribution guide](CONTRIBUTING.md).
## License
[MIT](LICENSE)
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.