thoughtproof-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| verify_decisionA | ThoughtProof pre-action verification gate: verify before the agent pays, trades, writes, or deploys. Call this BEFORE any consequential tool (payment, trade, transfer, publish, delete, deploy, irreversible write). Returns { verdict, execute, objections, structured_objections, receipt_id, surface, loop, axes?, recommendation, in_reply_to? }. execute is true ONLY on ALLOW — on any other result do NOT execute (soft fail-closed; host must honor execute=false). If structured_objections have severity blocked_until, repair using repair_hints and call again with in_reply_to set to that objection_id (new receipt; prior ALLOW does not carry). Routes internally to DQL (spend/checkout) or Sentinel (irreversible exit). Camera mandate: you must NOT put the overshoot or constraint violation in proposed_action or reasoning (for example, do not write "price is above the cap"). Put the user goal in mandate, the action you are about to take in proposed_action, and your plan in reasoning — the verifier must find the mismatch. Optional mandate_kind / action_kind declare Sentinel ActionKind (informational | value_transfer | permission | deploy_ship | unknown) — omit rather than guess. Replan = new call = new receipt. Aliases: verify_decision, verify_before_action, verify_before_act. |
| verify_before_actionA | ThoughtProof pre-action verification gate: verify before the agent pays, trades, writes, or deploys. Call this BEFORE any consequential tool (payment, trade, transfer, publish, delete, deploy, irreversible write). Returns { verdict, execute, objections, structured_objections, receipt_id, surface, loop, axes?, recommendation, in_reply_to? }. execute is true ONLY on ALLOW — on any other result do NOT execute (soft fail-closed; host must honor execute=false). If structured_objections have severity blocked_until, repair using repair_hints and call again with in_reply_to set to that objection_id (new receipt; prior ALLOW does not carry). Routes internally to DQL (spend/checkout) or Sentinel (irreversible exit). Camera mandate: you must NOT put the overshoot or constraint violation in proposed_action or reasoning (for example, do not write "price is above the cap"). Put the user goal in mandate, the action you are about to take in proposed_action, and your plan in reasoning — the verifier must find the mismatch. Optional mandate_kind / action_kind declare Sentinel ActionKind (informational | value_transfer | permission | deploy_ship | unknown) — omit rather than guess. Replan = new call = new receipt. Aliases: verify_decision, verify_before_action, verify_before_act. |
| verify_claimD | – |
| check_agent_scoreD | – |
| verify_tradeD | – |
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 5 tools
verify_decision and verify_before_action are exact duplicates of the same tool exposed as separate entries, and verify_claim/verify_trade also overlap with the general verification concept. An agent cannot reliably distinguish which verification tool to call.
Most tools follow a verify_* pattern, but check_agent_score breaks it, and verify_before_action is just an alias of verify_decision rather than a distinct operation. The convention is readable but not cleanly consistent.
Five tools is a reasonable size for a focused verification server, though two are duplicates and three lack descriptions, so the effective distinct surface is smaller than the count suggests.
The core pre-action verification gate is described, but verify_claim, verify_trade, and check_agent_score have no descriptions, making their coverage unknowable. There are also no tools for managing receipts, reviewing prior objections, or repairing blocked decisions beyond the inline repair hints.