firewall

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

With no annotations, the description carries the full behavioral burden and meets it: it discloses automatic attachment of agent_id and wallet-ownership signature, trusted routing history, cost, and the meaning of eight output signals including when hard blocks are triggered. This is substantive operational disclosure, not schema repetition.

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

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

The description is long but dense and logically ordered: purpose, output signals, recommended context arguments, automatic auth, cost. Every sentence carries information, though the signal list could be slightly tightened without losing clarity.

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

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

The tool is complex — nested objects, many signals, no output schema, no annotations — and the description supplies the critical operational context: decision categories, signal semantics, recommended parameters, and automatic identity handling. It stops short of describing the exact response shape and the behavior of all policy sub-parameters, but the core calling requirements are adequately covered.

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

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

Schema coverage is low (25%), and the description compensates well for the most safety-critical context fields by explaining untrusted_text and intended with concrete injection/redirect examples. It also warns that agent_id must not be passed, although the schema still lists it — a minor internal inconsistency. Optional policy sub-parameters such as block_on and velocity_cap_usdc receive no explanation in either schema or description.

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

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

The description names a specific decision task — vetting a payment instruction in the context of the agent's own history and provenance — and clearly distinguishes it from assess_counterparty, which vets the seller. The 'should YOUR agent make THIS payment now?' framing makes the resource and intent unmistakable.

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

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

It explicitly positions this tool relative to assess_counterparty ('where assess_counterparty vets the seller, this vets the payment instruction'), giving an agent a basis for choosing between them. It also gives direct calling guidance: strongly recommend passing context.untrusted_text and context.intended to catch prompt-injection and mid-flight redirect payments.

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