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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is mostly covered. The description adds useful behavior by naming compared fields and stating results are ordered "best value first," but it does not explain the mode parameter or any limits beyond the 2-5 count.

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?

A single compact sentence with the key action, input range, compared fields, and ordering front-loaded. There is no wasted text.

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?

An output schema exists, so return-value details are less necessary in the description. Still, for a tool with an unexplained mode parameter and no schema descriptions, the definition leaves meaningful gaps about how the comparison behaves in different modes.

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 must compensate but only indirectly implies that the ids input should contain 2-5 deal identifiers. The mode parameter is completely undocumented, leaving an agent without guidance on what "full" means or what other values might do.

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 gives a clear verb and resource ("Compare ... deals") plus comparison fields and output ordering, so the core purpose is specific. It does not explicitly differentiate from siblings such as search_deals, get_deal, or compare_gpu_prices, 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 2-5 deal constraint gives some usage context, implying this is for small side-by-side comparisons rather than listing or retrieving one deal. However, it never says when to use this instead of search_deals or get_deal, nor does it mention exclusions or prerequisites.

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 only declare readOnly/openWorld, and the description adds substantial behavior beyond that: 'cheapest' is scoped to tracked providers not the whole market, reserved rates are excluded by default and never ranked as cheapest, tier_class taxonomy is enumerated, data_age_hours/degraded/stale thresholds are disclosed, and excluded_too_old is reported.

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-loads the core action and scope, and nearly every sentence carries operational detail. It is dense and slightly repetitive ('cheapest among tracked providers' restated as reserved 'never reported as cheapest') with awkward mid-sentence line breaks, but nothing is 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?

For a 7-parameter read tool it covers ranking semantics, tier classes, freshness cutoffs and the not_found fallback; return-field explanation is partly redundant given an output schema exists, but it doesn't hurt. The only real omission is the undocumented 'mode' parameter.

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 must carry all parameter meaning, and it does for gpu (with examples), limit (1-25), on_demand_only, include_reserved, include_history and max_data_age_hours. The 'mode' parameter (default 'full') is never mentioned, leaving one of seven parameters undocumented anywhere.

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 (compare), resource (tracked GPU rental prices), scope (one model, cheapest first) and gives example model strings. It is distinguishable from deal-oriented siblings like compare_deals and search_deals, though the overlap with get_price_changes (history/price-change data) is never explicitly addressed.

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 concrete conditions for the optional flags: on_demand_only keeps only on-demand rates, include_reserved pulls in reservation rates that are otherwise dropped, include_history adds history payloads, max_data_age_hours drops stale rates. It also states the unknown-model fallback. It stops short of naming siblings to use instead.

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 and openWorldHint=true, so safety and open-world nature are covered. The description adds that the record is public and surfaces redeem_url and agent_instructions, which is useful content disclosure, but it says nothing about failure behavior for a bad id or what the undocumented "mode" parameter changes.

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?

A single sentence with the lookup key and the notable returned fields front-loaded; no filler or redundant restatement of the tool name.

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?

An output schema exists, so return shape need not be explained, and the description does highlight the two most decision-relevant fields. But for a 2-parameter tool with zero schema description coverage, the unexplained "mode" parameter and absent usage/error guidance leave real gaps.

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 full burden. It clarifies that "id" identifies a single deal, but the second parameter "mode" (default "full") is never mentioned and has no enum, leaving the agent unable to know what modes exist or what they alter.

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 ("Get one deal's public record") and scopes it to a single item by id, which implicitly separates it from search_deals and compare_deals. It does not name any sibling explicitly, so differentiation relies on inference from the singular "one deal by id" framing.

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?

"by id" implies the usage condition (you already have a deal identifier), which is enough to infer this is a direct-lookup tool rather than a discovery tool. However, there is no explicit when-to-use statement, no mention of when to prefer search_deals/compare_deals, and no guidance on what to do if the id is unknown.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the backing endpoints, the ordering (newest first), the daily refresh cadence (~10:23 UTC), and that the response carries data_checked_at and next_refresh_utc for staleness reasoning. That is meaningful operational context an annotation cannot convey; only the unexplained 'mode' parameter 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?

The lead sentence front-loads the resource and output shape, followed by parameter behavior in decreasing order of importance. It runs long and the parenthetical endpoint paths are somewhat noisy, but each clause carries usable information 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 a read-only annotation set and an output schema already present, the description doesn't need to enumerate return values, yet it helpfully names the key fields and freshness markers. The single real hole is that 'mode' has no explanation anywhere, which for a 4-parameter tool is a modest but genuine 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 0%, so the description must carry the load and it does for three of four params: gpu is a substring filter with an 'H100' example, limit is bounded 1-200, and since has both format and semantics. The 'mode' parameter (default 'full') is never mentioned, leaving one documented-in-neither-place argument that an agent must guess at.

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+resource: 'GPU rental price changes among tracked providers, newest first, each with old/new hourly price, change_pct, direction and the vendor source_url.' That distinguishes it from the snapshot-oriented siblings (compare_gpu_prices, search_deals), though it never names an alternative explicitly, so differentiation is inferred rather than stated.

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 clearly states the conditional behavior of the two main arguments: since='YYYY-MM-DD' returns every change on or after that date, while omitting it returns only the latest day's moves. It also explains when to call again ('call again after the next refresh to see what moved'), giving the agent a polling strategy. What's missing is explicit routing against siblings like compare_gpu_prices.

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 only declare readOnly/openWorld; the description adds substantial behavior: deterministic keyword/regex parsing with no LLM, explicit override semantics for optional fields, cheapest-option-with-cited-price rule, 'no sourced price tracked' instead of estimating, totals showing math and completeness, exclusion of pulled listings, and full freshness state machine (degraded >48h, stale >7d, max_data_age_hours exclusion with excluded_too_old).

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 purpose, which is good, but the body is a dense run-on paragraph of semicolon- and parenthetical-separated field lists. Almost every clause carries information, yet the lack of structure makes it harder to scan than it needs to be for 15 parameters.

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?

An output schema exists so return values needn't be spelled out, and the description still usefully previews provenance fields (calc, source_url, verified_at, referral_disclosure) and freshness handling. It's nearly complete for a 15-parameter tool, missing only the semantics of `mode`, `workload` and `exclude_manual_signup`.

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?

With 0% schema description coverage, the description carries the burden and mostly succeeds: it gives units and examples for gpu_hours, gpu_model, model_size_b ('sets a minimum VRAM using FP16 x 1.2'), scrape_pages, js_rendering, proxy_gb, search_queries, emails_sent, llm_api, monthly_budget_usd and max_data_age_hours. Three parameters (`mode`, `workload`, `exclude_manual_signup`) are never explained, leaving a real gap.

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 concrete verb+resource: 'Estimate a monthly stack cost from a short description of the agent being built.' It names the siblings sharing the same data (optimize_stack, compare_gpu_prices, deal feed), which tells the agent this is a sibling entry point, but never states what distinguishes it from optimize_stack itself.

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?

There is a usage example for the `description` field, but no guidance on when to pick this over optimize_stack or compare_gpu_prices, and no prerequisites or exclusions. The agent must infer selection from the names alone.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses real behavioral traits: each result line carries plan, monthly_cost_usd, calc, vendor quote, source_url, checked_at, assumptions, plus alternatives. It also states that unpublished prices are 'unknown' and are never estimated, and that manual_signup_only means a human must sign up and must never be automated — an important safety constraint.

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 purpose and the core rule ('set quantities, rest 0') are front-loaded, followed by a compact parameter glossary and return-shape notes. It is dense but every line carries information; only the trailing URL self-reference adds little for an agent.

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 9 loosely-titled parameters and no schema descriptions, the description supplies the missing semantics and explains result fields well enough that an output schema is barely needed for interpretation. The one omission is the undocumented 'mode' argument, which an agent cannot reason about from this text.

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 full burden, and it defines nearly every parameter in domain terms: scrape_pages vs scrape_pages_js (JS rendering), proxy_gb (residential GB/month), emails_sent, search_queries, gpu_hours (1 GPU) and gpu_model with concrete examples like 'H100'. The notable gap is the 'mode' parameter, which defaults to 'full' but is never explained.

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 opening sentence states a specific outcome: the cheapest suitable stack across tracked providers for the given monthly usage quantities. It is clear what the tool returns, but it never distinguishes itself from the sibling optimize_agent_stack, which sounds nearly identical in intent.

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?

Usage is implied through the input framing ('set the quantities you need, rest 0') and the exclude_manual_signup exclusion rule, which tells the agent when plans get dropped. However, there is no statement of when to prefer this over compare_gpu_prices, compare_deals, or optimize_agent_stack, so the agent must infer routing.

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 and openWorldHint, so safety is covered; the description adds real behavior: max_price silently drops deals with unknown price, listed_discount values are unconfirmed (verified_at null), limit is bounded 1-25, and next_cursor must be passed back as cursor. These are non-obvious traits an agent would otherwise get wrong.

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?

Tight, front-loaded, and free of filler; the offer_type list is dense but carries necessary semantic distinctions. The line breaks make it scannable, though the taxonomy block could be trimmed of the parenthetical if the field were enumerated in the schema instead.

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?

An output schema exists, so return-value explanation is rightly omitted, and the pagination contract is given. But for an 8-parameter tool with zero schema descriptions, leaving mode/tags/query/category undefined is a meaningful completeness gap that the description should have closed.

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 0%, so the description must compensate, and it does for offer_type (full value list with semantics), max_price, limit, and cursor. However mode, tags, query, and category — half the parameters, including the opaquely named mode with default "full" — are entirely undocumented in both schema and description.

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?

Specific verb+resource ("Search ... deals") with a scoping qualifier ("agent work-stack") and example categories (compute, search, email, unblock, hosting). It does not distinguish itself from siblings like compare_deals, get_deal, or optimize_stack, so an agent must infer the boundary between lookup and comparison.

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?

Usage is only implied: the offer_type taxonomy and max_price caveat tell the agent how to filter, and the cursor sentence tells it how to page. There is no statement of when to prefer this over compare_deals or get_deal, and no prerequisite/exclusion guidance.

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