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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds important behavioral guarantees: 'AgentResolver never requests a private key, signs the target payment, or custodies/forwards target funds,' and mentions 'fail-closed reason codes.' This goes beyond annotations and clarifies safety posture and failure behavior.

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 only two sentences but is not front-loaded; the first sentence 'Paid $0.001 USDC on Base or Solana transaction-path gate for autonomous buyers' is a garbled noun phrase that consumes attention without clear meaning. The actionable purpose appears in the second sentence. It is compact but not well-structured or unambiguous.

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?

Given 7 parameters and complex security implications, the description omits critical usage context: what inputs must be supplied, how maxPriceUsd or expectedPayTo work, or what allowUnpaidPostProbe does. An output schema exists, so return values are covered, but the tool's role in a payment flow and its exact modifier behavior are under-specified. The $0.001 ambiguity further reduces completeness.

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 0%, and the description does not explain any of the 7 parameters (url, body, method, maxPriceUsd, expectedPayTo, expectedNetwork, allowUnpaidPostProbe). It only hints at network names ('Base or Solana') and 'target payment terms' but fails to map these to specific parameters, leaving agents without semantic guidance.

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 clear function: returns eligible/blocked status, payment terms, reason codes, and verifiable evidence before authorization. It is distinct from generic tools via the x402 payment context and title, though it does not explicitly name sibling tools or differentiate them. The opening phrase 'Paid $0.001 USDC...' is ambiguous but the second sentence anchors the purpose.

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?

The description implies usage as a pre-payment gate ('before caller authorization') but provides no explicit guidance on when to choose this over siblings like payment_guard, x402_ping, or mcp_preflight. There is no statement of exclusions or alternatives, so usage is inferred rather than explicit.

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