dhp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | The DHP data directory root passed to the MCP server, e.g. `dhp-mcp --root ~/.dhp` (stdio). Used to store handoff envelopes, checkpoints, and the JSON-lines log. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| dhp_dispatchC | Dispatch durable work. Returns a handoff_id. The work survives worker death from here on. |
| dhp_claimB | Claim a handoff for a worker. Returns the lease and the last checkpointed state (resume point). |
| dhp_checkpointC | Checkpoint worker progress. Call per chunk of work. |
| dhp_heartbeatB | Heartbeat: prove the worker is alive. Call frequently; a silent worker is assumed dead. |
| dhp_completeC | Complete the handoff with a schema-validated result. |
| dhp_recoverB | Recover an orphaned handoff (worker died). Returns the lease and the last checkpointed state to resume from. |
| dhp_statusB | Status of a handoff: state, checkpoints, owner, result if completed. |
| dhp_last_checkpointC | Last checkpointed state, or null if none yet. |
| dhp_healthB | Server health: uptime, store stats. |
| dhp_record_effectA | Record a side effect by step_id. First write wins; returns recorded=true if this call stored it, false if a previous attempt already did (do NOT re-fire the effect). |
| dhp_effect_doneA | Check whether a side effect already happened. Returns the recorded result, or null. Call before re-executing a side effect after recovery. |
| dhp_note_spendB | Record spend in USD against the handoff budget. The supervisor fails the handoff closed on budget breach. |
| dhp_note_activityB | Report an activity digest (hash of tool name + args). The supervisor orphans the handoff as stalled if the digest repeats with no new checkpoint (livelock detection). |
| dhp_request_approvalA | Request approval for a destructive/financial action. Fail-closed: returns an approval_id; the action must NOT run until dhp_await_approval reports approved. |
| dhp_approval_statusA | Check an approval's status: pending/approved/denied/expired. Only approved means the action may run. |
| dhp_approveC | Approve a pending approval request (human / policy engine). |
| dhp_denyC | Deny a pending approval request (human / policy engine). |
| dhp_require_capabilityA | Fail-closed capability check: verify the handoff's contract grants (domain, resource) before touching network, filesystem, or external services. Every check is audited. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools target distinct protocol actions (claim, checkpoint, complete, recover, approve/deny), but several read/write or lifecycle pairs (claim vs recover, checkpoint vs last_checkpoint, record_effect vs effect_done, status vs approval_status) require careful reading. Descriptions clarify the boundaries, and no true duplicates exist.
All names use a consistent dhp_ prefix and snake_case, which is easy to parse. The verb_noun pattern is not universal (heartbeat, status, health, approve, deny, dispatch, last_checkpoint), so it is mostly rather than perfectly consistent.
18 tools is on the heavy side for a single protocol server, but each maps to a distinct lifecycle, safety, or observability concern (lease, checkpoint, effects, approvals, budget, capabilities). The surface is defensible, though it could likely be consolidated slightly.
Core durable handoff lifecycle (dispatch, claim, recover, checkpoint, complete), approvals, side-effect deduplication, budget tracking, and capability checks are all covered. Minor gaps remain, such as no explicit cancel/abandon handoff or list-handoffs operation, but agents can largely work around these via status and recover.