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

Annotations already cover the safety profile (readOnly, non-destructive), so the description is free to add the operationally important details it does: the unknown-vs-zero semantic trap for missing days, and the cost model (20 default rows, 100 max, one data unit per page). Cost and data-interpretation caveats are exactly the context annotations cannot express.

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 sentences, front-loaded with what the tool returns and how to read it, then the use case, then the two behavioral caveats. No sentence is filler and nothing is buried.

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 steps in to explain the return shape (observed-available vs total per day) and the meaning of absent days, which is what an agent needs to interpret results. Minor gaps remain around response envelope/error behavior, but the essential interpretive context is present.

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 gpu, provider, and the pagination object are already fully documented. The description only restates the optional provider limit and the pagination defaults/maximum, adding no syntax or format meaning beyond the schema; baseline 3 applies.

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 with precise scope: day-by-day stock availability for one GPU over the last seven days, broken out by provider and node size. It distinguishes itself from siblings by explicitly assigning price data to get_prices, so an agent can tell the two apart without opening either 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 intended use ("judge how reliably a GPU can be found in stock") and routes price questions to get_prices, which is a real alternative. It stops short of stating when not to use it or how it relates to get_price_history / get_market_snapshot beyond the price hand-off.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false). The description adds real context beyond them: the call 'costs one data unit' (a quota/billing constraint) and that it is 'not an anonymous health check,' implying credential/quota requirements. It does not describe response format or any rate limits, so it stops short of 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?

Three sentences, each earning its place: scope of the report, the decision it supports, and the cost/caveat. The core purpose is front-loaded and nothing is 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?

With no input params and no output schema, the description carries the full burden and does so: it enumerates the returned fields (collection completion, per-provider last success/run/failures/error), provides the decision context, and warns about cost and non-anonymity. An agent has everything needed to call and interpret it.

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?

The tool takes zero parameters (additionalProperties: false), so per the rubric the baseline is 4. The description correctly implies a parameterless call by framing it as a single status report, and there is no schema surface area it fails to cover.

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 specific verb and resource ('Report how fresh GPU Finder's data is') and enumerates exactly what is reported: collection completion time plus per-provider last success, last run, consecutive failures and last error. It is clearly distinguished from the sibling read tools (get_prices, get_availability) because it reports collection metadata, not prices or availability themselves.

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?

It gives an explicit decision context: 'Use it to decide whether a price or availability answer may be stale,' which tells the agent when to call it relative to the pricing tools. It also clarifies what it is not ('not an anonymous health check') and flags the cost, but it never names an alternative tool or a condition under which to skip it entirely.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), but the description adds real operational context: the whole snapshot costs one data unit (billing) and 'collected stock is not a capacity guarantee' (data freshness caveat). It does not, however, discuss pagination, caching, or failure modes.

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?

Front-loaded with the question and the recommendation framing, followed by the field list and the routing sentence. The enumeration of return fields is long but justified because no output schema exists; the trailing cost/caveat sentence earns its place.

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 burden of describing return values and does so thoroughly (provider, region, whole node and per-GPU price, availability, check time, provider count). Combined with the billing and capacity caveats, an agent has enough to call and interpret it correctly; only edge-case behavior is unaddressed.

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%, so the schema already documents both gpu and count, including the whole-node pricing semantics of count. The description restates the 'one GPU model and node size' scoping but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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 opens with the exact question the tool answers ('what is the cheapest way to rent this GPU now') and specifies the resource scope (one GPU model and node size) plus the returned fields. It is immediately distinguishable from get_prices, which it names.

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?

Explicit routing: 'Use it for a single recommendation; use get_prices for every offer.' This gives both the when-to-use condition and the named alternative, leaving nothing to inference.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=false), so the description's contribution is the operational cost model: 'each page costs one data unit' and the 20/100 page bounds. This is meaningful context beyond structured data, though it omits anything about data freshness or latency, and never addresses the non-idempotent hint.

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?

Front-loaded with the primary capability, then routing, then pagination/cost mechanics. Four compact sentences, all load-bearing, though the pagination sentence is dense enough that it packs several distinct facts into one clause.

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?

No output schema exists, so the description carries the return-value burden and does reasonably: monthly granularity, per-provider rows, on-demand/spot columns, currency and unit, and nextCursor-based paging. A brief note on the response envelope (field names, ordering) would close the remaining 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 coverage is 100%, so baseline is 3. The description goes further by defining the output unit and granularity the parameters produce: USD per whole node hour, on-demand vs spot, capped at 12 UTC months, and per-provider breakdown. That clarifies what 'months' and 'count' actually yield, which the schema alone does not.

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 ('Show how one GPU model's price changed month by month per provider') with the exact unit and dimensions (on-demand/spot, USD per whole node hour). It directly names the sibling it differs from (get_prices), so an agent can disambiguate without opening either 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?

Explicit routing guidance: 'Use it for trends; use get_prices for current prices.' This names the alternative and the condition that selects it, plus the pagination continuation protocol (reuse filters and limit with nextCursor).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds beyond that: prices are collected data rather than a live capacity guarantee, and each page of up to 100 rows costs one data unit. That cost/freshness detail is genuinely useful, though return format beyond field names is not detailed.

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?

Three front-loaded sentences: scope, then sibling routing, then caveats and cost. Every clause carries information an agent needs, and the primary purpose precedes the routing and pricing caveats.

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?

For a read-only list tool with no output schema, the description covers what is returned, how to choose it over siblings, that prices are collected rather than live, and the pagination cost. Nothing needed to invoke it correctly is 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 description coverage is 100%, so the baseline is 3, but the description adds pricing-unit semantics not present in the schema ('on-demand and spot USD price per whole node hour') and restates the pagination default/limit in context. It does not document the cursor mechanics beyond what the schema already says.

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 opens with a specific verb and resource: 'List every provider offer for one GPU model and node size,' then enumerates the returned fields (provider, instance type, region, GPU count, on-demand and spot price, links, last update). This is enough to distinguish it from every sibling without opening any 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?

It explicitly routes the agent: 'Use it for the full price table; use get_market_snapshot for only the cheapest offer, get_availability for stock and get_price_history for trends.' This names the alternatives and the selecting condition for each, leaving nothing to inference.

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

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

Goes well past the annotations by disclosing cost behavior ('spends no monthly units'), a counterintuitive availability property ('works after the monthly allowance is exhausted'), and a residual constraint ('still rate limited'). These are exactly the facts an agent needs to decide whether to spend a call here, and none are inferable from readOnlyHint/destructiveHint.

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 dense sentences with no filler: the first defines the output, the second defines when and why to call it. Scoping and usage conditions are front-loaded rather than buried.

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, but the description enumerates the returned fields (allowance, units used, units remaining, UTC reset times), so an agent knows what it will get. With annotations covering the read-only safety profile and no parameters to document, nothing material is 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?

The tool takes zero parameters (empty object, additionalProperties false), so there is nothing to disambiguate; baseline 4 applies. The description correctly implies no input is required by scoping entirely to 'this API key.'

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 (Show) and resource (this API key's usage) and enumerates exactly what comes back: plan allowance, units used/remaining, and UTC reset times. None of the sibling tools (get_prices, list_gpus, get_availability, etc.) cover account/quota state, so an agent can distinguish it immediately.

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 two concrete triggering conditions: 'before large paginated reads' and 'after a quota_exceeded error.' That is explicit when-to-use guidance, though it names no alternative or when-not-to-use case (a minor omission given siblings operate in unrelated domains).

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

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

Annotations already cover the safety profile (readOnly=true, destructive=false, openWorld=false), so the bar is lower. The description adds value the annotations do not: page size limits and, crucially, that each page consumes one data unit — a cost constraint an agent must budget for. It does not mention ordering or cursor expiry, so it is not exhaustive.

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, no filler. The returned-field inventory is front-loaded, followed by usage guidance and then the pagination/cost caveat in descending priority order.

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 compensates by listing the returned fields and explaining pagination and cost, which is enough for a read-only listing tool. It is slightly thin on ordering guarantees and what a cursor points to across filter changes, but nothing critical to correct invocation is 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%, so the schema fully documents limit/cursor semantics; baseline would be 3. The description adds information the schema lacks — the per-page data-unit cost — which meaningfully affects how an agent should size and iterate pages. The 20/100 bounds themselves merely restate 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?

Names a specific verb (List) and resource (GPU models GPU Finder tracks) and then enumerates the returned fields — canonical name/slug, VRAM, memory type, bandwidth, interconnect, provider and instance counts, min/max hourly USD price. It also explicitly separates itself from get_prices, so an agent can distinguish it from siblings without inspecting schemas.

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?

States two concrete use cases (discovering valid GPU names for other tools, comparing specs) and names the sibling to use instead for per-provider offers (get_prices). Both the when and the when-not are explicit.

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

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

Annotations cover safety (readOnlyHint=true, destructiveHint=false), so the description's remaining burden is minor. It adds real operational context the annotations lack: one data unit charged per page and the 20/100 row pagination envelope.

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?

Front-loaded with the resource and its payload, then usage routing, then pagination/cost. The field enumeration sentence is long but each item is a distinct return field rather than filler.

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's field list effectively doubles as the return-value contract, and it covers pagination, defaults, and per-page cost. Nothing an agent needs to call this correctly is 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 description coverage is 100% (limit, cursor, defaults already documented), so the baseline is 3. The description adds the cost implication of paging ('each page costs one data unit') and the page-size range, which is meaningful context 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?

States a specific verb and resource ('List GPU cloud providers') and enumerates the returned fields (slug, counts, price range, egress cost, links, update time), which lets an agent know exactly what comes back without opening a 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?

Explicitly names both use cases ('find valid provider slugs or compare providers overall') and the alternative for a different need ('use get_prices for one GPU's offers'), routing the agent away from the wrong sibling.

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