DoneProof MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DONEPROOF_ALLOWED_ROOTS | No | Constrains project roots. The server will only operate within these allowed root paths. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_taskB | Create a bounded task and persist a redacted objective. |
| list_tasksA | List persisted proof tasks without reading their projects. |
| get_taskA | Return task, active criteria, verifier profile, evidence, and current assessment. |
| derive_criteriaA | Ask the host model for observable criteria and persist only a draft proposal. |
| set_criteriaA | Replace active criteria with the user-reviewed statements and evidence policies. |
| discover_verifiersA | Derive verifier argv and working directories from live project manifests. |
| prepare_verificationA | Create an evidence-linked verifier plan and a one-time execution token. |
| execute_verificationB | Consume one token, run the candidate verifier, and append observed command evidence. |
| record_file_evidenceB | Hash a project file; only an explicit expected hash produces observed pass or fail. |
| record_attestationA | Record a human-reviewed claim, explicitly labelled as attested rather than observed. |
| assess_completionB | Compute completion from fresh evidence policies and ledger integrity. |
| build_proof_reportB | Write a Markdown proof report containing the matrix and hash-linked evidence ledger. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| proof_prompt |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.