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

Annotations already declare readOnly/destructive/openWorld, so the safety profile is covered; the description goes further by disclosing page size defaults (20), the 100-row cap, and that 'each page costs one data unit' — a real cost/quota signal an agent needs before paginating. It stops short of explaining cursor expiry or ordering, which keeps it from 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?

Two sentences: a dense field enumeration followed by pagination/cost rules, with the tool's identity front-loaded. The field list is long but each item is information an agent would otherwise have to infer, so little is wasted.

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, the description carries the return-value burden and does so by enumerating the returned columns and noting canonical identifiers plus provider-level summaries. Pagination and cost are covered; only ordering and auth/quota context are missing.

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% and the nested page object already documents limit (1-100, default 20) and cursor (nextCursor reuse). The description restates the default and maximum and adds the data-unit cost per page, but adds no new meaning about cursor semantics or filter reuse 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?

Opens with a specific verb+resource ('List GPU cloud providers') and enumerates exactly which fields come back (name, slug, counts, price range, egress, links, update time), so an agent knows this is the provider-catalog endpoint rather than a GPU- or price-level one. It does not explicitly name the sibling it is not (e.g. list_gpus), so it falls short of a 5.

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 never says when to reach for this tool versus get_prices, list_gpus, or get_market_snapshot, nor any prerequisite or exclusion. The only guidance present is mechanical pagination/cost behavior, not usage selection.

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