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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: per-call cost in USDC, payment rail, ~10 ms challenge latency, ~1.5 s average processing, and the exact auth header and endpoint. That is exactly the payment/auth/latency context an agent needs before calling.

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 functional purpose is front-loaded in the first clause, but the payment boilerplate is verbose and repetitive (x402 named three times, cost restated, the URL broken out as if separate from the header instruction). It could lose a third of its length without losing information.

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?

With no output schema and a non-trivial payment handshake, the description supplies the endpoint, price, required header, and latency expectations, so an agent can invoke it. It stops short of describing the response shape or failure modes, which would matter for a paid call.

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%, so the description carries the burden. It names two of three parameters (max_words, target language) and restates the 40k text limit, but omits the max_words 20–1000 range, the default, and the language enum values (auto/en/fr), leaving meaningful gaps.

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 ('Summarize text') with an explicit input bound (up to 40k chars) and output character ('faithful, tight summary'). No agent could confuse this with siblings like translate, extract, or pkg_meta.

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 explains the invocation precondition (pay-per-call over x402, cost, required PAYMENT-SIGNATURE header, endpoint URL), which is real context. It gives no guidance, however, on when to choose summarize over translate or extract, so usage routing is only implied.

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