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

Annotations only declare readOnlyHint and openWorldHint; the description adds the critical behavior an agent cannot infer: a $0.1 USDC x402 charge per call, that an unpaid call returns payment requirements rather than data, and the exact retry mechanisms (X-PAYMENT / PAYMENT-SIGNATURE header or params._meta["x402/payment"]). This is exactly the kind of operational context annotations cannot carry.

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 purpose before the payment mechanics, and nothing is decorative. The payment/retry sentence is dense with header syntax but every clause is operationally necessary, so the length is justified rather than padded.

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 should hint at what a successful call returns; it only describes the failure path (payment requirements). For a paid search tool, an agent knows how to pay and what it is searching, but not the shape or fields of the award records it will get back.

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 50% (keyword documented, limit not), so the description must compensate. It does add real meaning for the undocumented payment channel (header names and the _meta key), which are not in the schema at all, but it says nothing about limit behavior (default 5, cap 25) or what keyword matching actually covers.

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 ('Search public US federal award records (USASpending)') plus the research intent ('supplier and agency research'). It also explicitly disambiguates from a commonly confused source ('Not SAM.gov live solicitations'), so an agent can tell what this is and is not 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?

Gives a clear use context (supplier and agency research) and an explicit exclusion (not live solicitations), which prevents a common mis-selection. It does not name an alternative tool for the excluded use case, and none of the listed siblings covers USASpending, so the routing guidance stops just short of a 5.

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