Skip to main content
Glama
ThoughtProof

thoughtproof-mcp

Official
by ThoughtProof
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

verify_before_action

Verify any consequential AI agent action before execution. Call this gate before paying, trading, writing, or deploying to get a verdict and structured objections, preventing costly mistakes and irreversible exits.

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.6/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavior: the return envelope fields, fail-closed contract ('execute is true ONLY on ALLOW'), the camera mandate to omit overshoot from proposed_action/reasoning, routing to DQL/Sentinel, and the rule that a new receipt invalidates prior ALLOW. This is far beyond a minimal statement.

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

Conciseness5/5

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

The description is long but dense; every sentence carries operational necessity, from call timing to fail-closed rules, repair flow, routing, and camera mandate. It front-loads the core purpose and layers essential details without filler.

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?

For a high-stakes tool with 9 parameters and no output schema, the description covers invocation timing, return envelope fields, failure semantics, repair loop, routing, and parameter usage. Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds crucial operational meaning: the camera mandate explains how to populate mandate/proposed_action/reasoning, in_reply_to is tied to structured_objections with a new receipt, and action_kind/mandate_kind should be omitted rather than guessed.

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 states a specific purpose: a pre-action verification gate before payments, trades, writes, or deploys, and clarifies it returns a verdict and execute flag. However, it does not explicitly differentiate from sibling tools like verify_claim or verify_trade beyond listing verify_decision as an alias.

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?

Explicitly instructs to call before any consequential tool (payment, trade, transfer, publish, delete, deploy, irreversible write) and defines the repair flow with in_reply_to. It does not state when not to use it or point to alternatives for other verification tasks.

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