Skip to main content
Glama
ThoughtProof

thoughtproof-mcp

Official
by ThoughtProof
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

verify_decision

Verify any high-impact action before execution—payments, trades, writes, deployments. Submit the user goal, intended action, and plan to receive an ALLOW or HOLD verdict with structured objections for safe, fail-closed decisions.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoRouting override. auto (default) picks DQL for spend/checkout language and Sentinel for high-blast irreversible exits; unsure → DQL. Explicit mode wins.
quoteNoOptional verbatim excerpt of the user's mandate (copy the user instruction, do not paraphrase). Wired into Sentinel evidence for provenance. Must be at least 20 characters and an exact substring of mandate; otherwise the full mandate is used as the quote.
contextNoOptional extra evidence, tool outputs, or prior turns.
mandateYesThe user's stated goal or instruction the agent is acting on.
reasoningYesThe agent's own plan or reasoning. Do not include the overshoot; the verifier has to find the mismatch.
action_kindNoOptional host-declared Sentinel ActionKind for the proposed action (action.kind). Values: informational | value_transfer | permission | deploy_ship | unknown. Sentinel prefers this over prose classification. Omit rather than guess.
in_reply_toNoobjection_id from a prior envelope structured_objections item. Marks this call as a repair. New receipt; prior ALLOW does not carry.
mandate_kindNoOptional host-declared Sentinel ActionKind for the mandate (mandate.kind). Values: informational | value_transfer | permission | deploy_ship | unknown. Sentinel prefers this over prose classification. Omit rather than guess.
proposed_actionYesWhat the agent is about to do (pay/trade/write/deploy/…). Do not include the overshoot or constraint violation here.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explains the fail-closed semantics ('execute is true ONLY on ALLOW — on any other result do NOT execute'), the receipt/repair model, the camera mandate about not revealing overshoot in proposed_action/reasoning, and that replanning requires a new call. This goes well beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but dense with critical behavioral rules—fail-closed behavior, camera mandate, repair flow, routing, and aliases. Each sentence earns its place, and the core purpose is front-loaded. A modest amount of redundancy exists around the camera mandate, but overall it is appropriately structured for a high-stakes verification tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool with 9 parameters, 3 required, and no output schema. The description covers the return envelope fields, the execute flag semantics, the repair flow, routing modes, and the camera mandate—everything an agent needs to call it correctly. Nothing critical for safe invocation appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds valuable usage semantics beyond the schema: it tells the agent to put the user goal in mandate, the action in proposed_action, and the plan in reasoning, and to omit rather than guess the optional kind fields. It could go further with concrete examples, but it meaningfully enhances the placeholder descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: it is a pre-action verification gate called before consequential actions like paying, trading, writing, or deploying. It is unambiguous about what the tool does, but it does not explicitly differentiate itself from sibling tools such as verify_claim or verify_trade—it lists aliases instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: 'Call this BEFORE any consequential tool (payment, trade, transfer, publish, delete, deploy, irreversible write).' It also explains internal routing between DQL and Sentinel and the repair flow. It does not name alternative sibling tools or state when NOT to use this tool, so it misses the full when/when-not comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools