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

Annotations already handle readOnly=false and idempotent=false, so the description does not need to repeat those. It adds meaningful context beyond the annotations: the operation requires a private key, performs a USDC spend, and is a single combined payment-and-fetch action. It doesn't discuss error or refund behavior, but that level of detail is less critical given the schema and output schema.

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, each earning its place: the first states the core action, the second gives prerequisite and the relevant alternative. No filler, no repetition of schema details, and the most important decision point is front-loaded.

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 description covers the essential selection context: the one-call payment-and-fetch behavior, the private-key prerequisite, and the no-spend probe alternative. For a 7-parameter tool with a rich input schema and annotations, this is sufficient for an agent to select and invoke correctly. It could spell out how to pick a network or what can go wrong, but those are delegated to schema and sibling tools without leaving a critical gap.

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 all seven parameter including url, body, method, headers, agent_id, max_price_usdc, and preferred_network. The description does not add per-parameter meaning beyond the schema; the only extra contextual thing is EVM_PRIVATE_KEY, which is an environment prerequisite rather than a parameter. 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?

Description uses a concrete verb+resource structure: 'Pay USDC via x402 and fetch a protected HTTP resource in one call.' It clearly scopes the action and distinguishes it from the sibling x402.probe by contrasting the paid with the no-spend behavior.

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?

Description explicitly states 'Requires EVM_PRIVATE_KEY on this host; otherwise use x402.probe for a no-spend 402.' This names the exact condition and alternative, making both the when-to-use and when-to-avoid crisp.

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