Agent Transaction Trust

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

With no annotations, the description carries the full burden and does real work: it discloses the monetary cost ($0.001 via x402), the return value (authorization_token), the binding semantics, and failure behavior ('if authorization is denied, the Trust fee is not settled/charged'). It does not cover auth/signing prerequisites for the payer wallet or any rate limits, so it falls short of a 5.

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?

Front-loaded with the tool's identity and routing position, then cost and failure behavior. Five sentences, all informative, though the ordering instruction is dense enough that it could be tightened slightly.

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?

For a 7-parameter, nested-schema, no-output-schema tool, the description supplies the return value, the cost, the failure path, and the surrounding workflow. Error modes other than denial and any signature/auth prerequisites are unstated, so it is strong but not exhaustive.

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 description coverage is 100%, so every parameter is already documented in-schema, including the binding warning on `request` and the provenance of `challenge_token`. The description's mention of binding approval to 'the exact merchant challenge and HTTP request' restates what the schema already conveys, so baseline 3 is appropriate.

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?

States a specific verb and resource ('Paid pre-payment trust gate' that 'Verifies AP2 v0.2 authority and binds approval'), and explicitly distinguishes itself from the create_ap2_challenge and verify_settlement siblings by position in the flow. An agent can tell what this does and when it sits relative to other tools without opening any schema.

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?

Gives an explicit ordered recipe: 'Use after create_ap2_challenge and after receiving the merchant's real x402 PAYMENT-REQUIRED challenge, but before paying the merchant,' then 'next pay the merchant, then call verify_settlement.' The when-not and the alternatives are both named, leaving nothing to inference.

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

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

With no annotations, the description carries the burden and does well: it discloses the machine price ($0.001 via x402), the verification scope (AP2 v0.2 authority, request/challenge integrity, merchant-risk evidence), and that it returns a signed clearance_token. It omits idempotency, whether repeated calls are billed, and any rate limits or auth prerequisites.

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?

Front-loaded with the core purpose, then sequencing, then verification scope, then return semantics and pricing. Every sentence is load-bearing with no filler.

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?

No output schema exists, so the description correctly supplies the return contract (clearance_decision values and signed clearance_token). Given 7 params, nested ap2_authority, and no annotations, it is nearly complete, though it says nothing about the nonce parameter or failure/error behavior.

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 71%, so most parameters are already documented in the schema. The description references the key concepts (PAYMENT-REQUIRED challenge, AP2 authority, exact request) but adds no syntax, format, or constraint detail beyond what the schema already provides, so the baseline of 3 applies.

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?

States a specific verb+resource ('Paid transaction-clearance decision for an autonomous x402 purchase') and its scope is distinguishable from siblings like authorize_x402_ap2 and create_ap2_challenge.

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?

Gives explicit sequencing: use after create_ap2_challenge and after the merchant's PAYMENT-REQUIRED challenge, but before paying. It also prescribes behavior per outcome (APPROVED may proceed automatically, REVIEW should not auto-pay, DENIED should not pay), leaving nothing to inference.

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

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

No annotations are provided, so the description carries the full burden; it discloses that the call is free, that the challenge is short-lived, and that it is single-use per purchase flow, plus what to do with the returned token. It stops short of auth/permission requirements or error behavior, which is the only remaining gap.

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?

Three sentences, front-loaded with what the tool is, then the call order, then the usage constraint. Every sentence carries distinct information with no repetition.

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?

No output schema exists, and the description compensates by explaining what is returned (a challenge bound into the Payment Mandate proof) and where the token goes (ap2_authority.challenge_token). Auth requirements and failure modes are unstated, but for a one-parameter prerequisite token tool this is close to complete.

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 description coverage is 100% and ttl_seconds is fully documented in the schema (30-300s), so the schema does the heavy lifting. The description adds no parameter-level detail beyond it, which matches the baseline 3 for high coverage.

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?

States a specific verb+resource (create an AP2 challenge) and immediately positions it as a prerequisite, naming the two siblings it feeds (clearance_x402_ap2, authorize_x402_ap2). An agent can distinguish it from every sibling without opening a schema.

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?

Explicit ordering guidance: call before clearance_x402_ap2 or authorize_x402_ap2, then bind the returned challenge into the AP2 Payment Mandate proof and pass the token as ap2_authority.challenge_token. It also states the scope limit ('one purchase flow'), so when-not-to-reuse is covered.

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

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

With no annotations, the description carries the burden well: it discloses the three possible firewall actions, says a signed proof is returned, qualifies what ALLOW means, and notes the call itself costs $0.001 via x402. It does not cover idempotency, failure behavior, or authentication requirements.

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 front-loaded, with each sentence serving a purpose: purpose, timing, return shape, ALLOW semantics, and price. There is no filler.

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?

For a tool with no annotations and no output schema, the description supplies the critical return values and decision meaning. It is still somewhat thin on error handling, repeat-call behavior, and parameter-specific usage, but the core invocation context is complete.

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 description coverage is 75%, so the schema already documents most fields. The description reinforces that the PAYMENT-REQUIRED challenge and merchant request must be bound to the decision, but it adds no detail about the optional category, merchant_id, or request-body semantics beyond what the schema provides.

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 states a specific verb and resource: a before-payment firewall gate for x402 clients that returns ALLOW/REVIEW/BLOCK plus signed proof. It is clear what the tool does, but it does not explicitly distinguish itself from nearby siblings such as preflight_x402, clearance_x402_ap2, or authorize_x402_ap2.

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 gives precise sequencing: call after receiving the merchant's real PAYMENT-REQUIRED challenge but before creating or signing the merchant payment. It lacks explicit when-not-to-use guidance or named alternatives among the sibling tools.

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

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

With no annotations, the description carries the full burden and does disclose key behavioral traits: 'Free, read-only entry point,' which tells the agent there is no cost and no mutation risk. It also enumerates the returned payload categories (capabilities, authority modes, proof key, price/network info, endpoints), though it omits auth requirements or rate limits — likely moot for a free read.

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?

Two sentences, front-loaded with the critical 'call this first' instruction and the cost/safety profile, followed by a compact enumeration of return contents. No wasted words.

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?

There is no output schema, so the description must characterize the return, and it does so by listing the returned fields (capabilities, authority modes, proof key, price/network, endpoints). It is complete enough to act on, though it does not describe the structure or format of those values.

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?

The tool takes zero parameters, which sets the baseline at 4. The description correctly does not invent input options and instead redirects attention to what the call yields, matching the empty schema.

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?

States a specific verb+resource ('get_trust_manifest') and positions it as the read-only discovery entry point, which cleanly separates it from the action-oriented siblings (authorize_x402_ap2, clearance_x402_ap2, verify_settlement). An agent can tell exactly what this returns without opening the schema.

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?

Explicitly says 'Call this first when deciding whether Agent Transaction Trust fits an x402 purchase,' giving a clear ordering signal relative to the authorize/clearance/verify siblings. It stops short of stating when NOT to use it or naming a fallback alternative, so it is clear context rather than full when/when-not guidance.

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

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

With no annotations, the description carries the burden well: it discloses no account/API key/policy token/AP2 mandate is required, the $0.001 x402 price, returned decision values, a signed preflight_token, and the conditional meaning of APPROVED. It does not explain REVIEW or DENIED handling.

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?

Front-loads the purpose, then access requirements, inputs, return values, the key approval caveat, and price. Dense but efficient, with no filler.

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?

No output schema exists, but the description explains the main return values and the critical APPROVED condition. It is nearly complete for invocation, though it could clarify what preflight_token is used for and what REVIEW means.

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 100%, so the schema already documents all four parameters. The description reinforces that payment_required must be the merchant's real challenge and request must be exact, but adds little syntactic or semantic detail beyond the schema.

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?

States a specific verb and resource: a paid public preflight for an autonomous x402 payment. It also implicitly distinguishes itself from authorization siblings by saying APPROVED only permits proceeding if separate delegated authority allows the spend.

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?

Explains the context clearly: submit the merchant's real PAYMENT-REQUIRED challenge and exact intended HTTP request before proceeding. It does not explicitly name when to use it versus authorize_x402_ap2 or clearance_x402_ap2, but the delegated-authority caveat supplies useful positioning.

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

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

With no annotations supplied, the description carries the full burden and does real work: it discloses the verdict taxonomy (signed ALLOW/WARN/BLOCK evidence), the risk categories screened, and the paid x402 model at $0.005 per call. It does not cover failure behavior, such as what happens on payment or upstream lookup failure, or latency, which keeps it below 5.

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?

Four short sentences, front-loaded with the purpose and the call trigger, followed by return values and price. No filler, and the pricing detail is placed last where it does not obstruct the primary decision.

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?

For a 4-parameter tool with no output schema, the description supplies the missing return semantics (signed ALLOW/WARN/BLOCK) and the payment model. What remains thin is the x402 mechanics — how payment is actually settled during the call — which an autonomous agent would benefit from knowing.

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 description coverage is 100%, so every parameter including token_address, amount_usd, pay_to and source is already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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 states a specific action and object: an ERC-20 safety screening on Base that checks honeypot, sell-restriction, tax, blacklist/pause and admin-risk signals. That is far more specific than the name alone and clearly separates it from the payment-oriented siblings like firewall_before_payment or preflight_x402, though it never names a sibling explicitly.

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?

"Call immediately before buying or swapping an unfamiliar ERC-20 token" gives a concrete trigger condition and timing. It stops short of stating exclusions — e.g. whether to skip it for known/whitelisted tokens or how it relates to the sibling preflight/firewall tools.

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

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

With no annotations supplied, the description carries the full burden and does well: it discloses that the call is paid ($0.002 via x402), that it returns a signed verdict (EXECUTE/REVIEW/BLOCK), and what evidence is included (simulation, gas, revert, balance, nonce, approval risk). It omits practical mechanics such as how payment is settled, what happens on non-payment, and whether repeated calls are charged each time.

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?

Four short sentences, front-loaded with what the tool is, then when to call it, then what comes back, then cost. Nothing is repeated from the schema and no sentence is filler.

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?

No output schema exists, so the description must describe returns — and it does, enumerating the verdict tokens and evidence categories. It falls slightly short on result structure and on what a BLOCK/REVIEW verdict implies for next steps, but for a 5-parameter simulation call this is close to sufficient.

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 description coverage is 100% (to, from, data, value, source each documented with patterns and defaults), so the schema already does the parameter work. The description adds no extra semantics about required minimums, wei encoding, or how 'source' affects output — baseline 3 is appropriate.

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 gives a specific verb+resource pair: 'pre-sign simulation for an unsigned Base transaction,' which tells an agent exactly what is computed and on which chain. It stops short of naming which sibling (preflight_x402, token_transaction_verdict, firewall_before_payment) should be used instead in overlapping cases, so differentiation is implied by 'Base transaction' rather than stated.

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?

'Call immediately before the wallet signs' gives a clear temporal trigger for invocation. However, there is no when-not guidance, no naming of alternatives among the many similarly named sibling tools, and no note about behavior when the wallet has already signed or when the transaction is already on-chain.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses cost (free, no additional Trust fee), the on-chain verification action, the ordering prerequisite, and the signed settlement receipt returned on match. It still omits auth/permission requirements, rate limits, and behavior on mismatch (no receipt? error?), which keeps it short of a 5.

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?

Front-loaded and dense, with the critical precondition stated early. Minor waste: 'Free post-payment step' and 'No additional Trust fee is charged' convey the same cost information twice.

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?

For a 2-parameter, fully documented schema with no output schema, the description supplies the ordering constraint, cost, parameter provenance, and the nature of the return value (signed settlement receipt). Only failure/mismatch handling and any auth requirements are left unstated.

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 description coverage is 100%, so the schema already documents both parameters including provenance and optionality, making 3 the baseline. The description restates that authorization_token comes from clearance_x402_ap2 or authorize_x402_ap2 and that payment_response is the merchant PAYMENT-RESPONSE 'when available', adding only marginal nuance.

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?

States a specific verb (verify) and resource (Base USDC settlement on-chain) and frames it as a post-payment step, which cleanly separates it from the pre-payment siblings authorize_x402_ap2 and clearance_x402_ap2.

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?

Gives an explicit gating condition ('Call only after the merchant x402 payment for a previously approved authorization or transaction clearance') and names which sibling tools produce the required authorization_token, so the ordering and prerequisites are unambiguous.

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

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

With no annotations, the description carries the full burden and does disclose several traits: the check is free, it is read-only, and it is limited to signature/expiry rather than settlement. It does not describe failure behavior (what an invalid or expired token yields) or any rate/limit constraints, which is the remaining gap.

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 safety/cost profile ('Free, read-only token check') is front-loaded as a scannable lead, followed by one dense sentence covering validation targets and the explicit non-goal. No filler sentences.

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?

For a single-parameter verification tool with no output schema and no annotations, the description covers purpose, scope, and cost/safety. It omits any hint of the result shape (valid/invalid, expiry info), which is a minor gap since no output schema exists to fill it.

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?

Only one parameter and schema coverage is 100%, so the schema already documents 'token' fully. The description restates the accepted token origins, which mirrors the schema text rather than adding format or syntax detail beyond it. Baseline 3 applies.

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?

States a specific verb+resource ('verify/validate ... a Trust token') and enumerates the token types it handles (policy, authorization, clearance, settlement receipt). It also carves out scope against the sibling verify_settlement by declaring it does NOT perform on-chain settlement verification, so an agent can separate the two without opening a schema.

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?

'Use this to validate the signature and expiry of...' gives clear positive guidance and the closing clause states when not to use it (settlement verification). It stops short of naming the alternative tool (verify_settlement) as the replacement, so the routing is implied rather than explicit.

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