TANDIU AI infrastructure data

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds useful content cues (cadence, price basis, citation) but says nothing about return format, size, or whether the info is static or live. Adequate but minimal beyond the annotations.

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 terse fragments, no filler, and the content list is front-loaded before the imperative 'Call first.' Every word carries 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?

For a parameterless overview tool with no output schema, the description adequately previews what the agent will learn. It could note the response's structure, but the enumerated topics are sufficient to decide whether to call 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, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter guidance is needed or missing.

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 names the specific resource (TANDIU datasets) and enumerates the exact content returned: published data, refresh cadence, price basis, citation guidance. That clearly separates it from all siblings, which are quantitative query tools. It lacks a verb like 'describe' or 'explain', but the content is specific enough to identify the tool.

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?

"Call first" gives an explicit ordering directive: use this before the pricing/estimation siblings. It does not name a when-not condition or an alternative, but for a zero-argument overview tool that single instruction covers the practical decision.

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, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds that the threshold can be absolute or relative to the best score, which is useful, but it omits result ordering, tie-breaking, defaults, and behavior when no parameters are supplied.

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 front-loaded sentence with no filler or repetition. It is tight, though its brevity is partly the cause of the missing parameter and usage detail rather than a sign of completeness.

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 five-parameter tool with zero required params, no output schema, and no param descriptions, the definition is too thin. An agent cannot tell what happens with an empty call, which metric is default, or how limit and country constrain results.

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 only clarifies the two threshold parameters (absolute vs percent-of-top). The limit, metric (aa_index vs livebench), and country parameters are left entirely unexplained, along with which of the two threshold params is mutually exclusive.

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 names a specific verb+resource: it returns the cheapest models meeting a benchmark score threshold, which is distinct from siblings like list_llm_prices or get_price_index. It does not, however, explicitly differentiate itself from those price-oriented siblings.

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 no when-to-use guidance, no statement of prerequisites, and no mention of alternatives such as list_llm_prices for raw pricing or estimate_* tools for cost projections. Usage must be inferred entirely from the name and one-line description.

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, idempotent, non-destructive, closed-world), so the lower bar applies. The description adds genuine behavioral content by disclosing what the estimate computes and what it reports back (GPU count, cost per 1M tokens), which compensates somewhat for the absent output schema.

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 front-loaded sentence that leads with the core output (monthly AI cost) and then enumerates the comparison axes. Dense but every clause maps to a real dimension of the estimate; no 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 5-parameter tool with no required params and no output schema, the description covers scope and most metrics but does not explain the two bare boolean flags or the return shape. It is minimally adequate but leaves gaps an agent would have to probe by invocation.

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 60%, so the schema documents query, include_gpu_breakdown and include_hardware_table. The description adds the headcount tiers (10/100/1,000/10,000) matching the enum and the industry concept, but leaves include_team and part of the boolean semantics unaddressed, giving it only baseline value.

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 (estimate) and resource (enterprise AI cost), and scopes it precisely: API (per-role model choice or open model's official API) vs self-hosting on public/private/on-prem GPUs, across 10/100/1,000/10,000-person company samples. It never names the overlapping sibling estimate_self_hosting, so an agent must still infer the boundary, but the purpose itself is unambiguous.

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 by the scope statement ('monthly AI cost for company samples across industries'). There is no explicit when-to-use, no when-not-to-use, and no routing to the closely related estimate_self_hosting or estimate_role_token_budget siblings.

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, idempotentHint, non-destructive, and closed-world. The description adds useful context about the data returned (32 roles, three usage levels, best global and Chinese models, capability floor), but does not describe response structure, pagination, or any rate/auth behavior.

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, front-loaded sentence that packs the scope, usage levels, and model-selection criteria without any filler. Every clause adds useful 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?

There is no output schema, so the description should carry more of the return-value burden. It explains the core output content (monthly token usage and cost, best models) and scope, and annotations cover safety, but it leaves group and limit semantics unexplained and does not describe the response format.

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 only 25%. The description mentions 32 job roles and light/standard/heavy usage, which partially helps interpret the query and usage parameters, but it says nothing about the group categories or the limit parameter. With two of four parameters left undocumented, the description does not compensate for the low schema coverage.

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 clearly states the resource and scope: monthly token usage and cost for 32 common job roles at three AI usage levels, along with best model and best Chinese model meeting a capability floor. It does not explicitly differentiate from siblings such as estimate_enterprise_ai_cost or cheapest_model_for_score, but the job-role focus is specific enough.

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 no guidance on when to use this tool versus alternatives, when not to use it, or any prerequisite context. Usage is only implied by the description of what it returns.

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, idempotentHint/true, destructiveHint/false, and openWorldHint/false, so the safety profile is fully covered before the description speaks. The description adds the non-obvious dual behavior of the model parameter (omitting it switches the tool into a listing mode), which is genuinely useful context, but says nothing about units, estimation assumptions, or cost basis.

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 tight sentences with no filler, and the listing-mode instruction sits at the end where it is easy to miss but does not bloat the front. The first sentence is an output enumeration rather than a verb, so it is efficient but slightly less front-loaded on purpose.

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 usefully enumerates the returned metrics (VRAM, GPU count, throughput, hardware cost, API price/speed), which is exactly what the agent needs to judge relevance. Missing are units, estimation assumptions, and any hint of result format, but for a read-only 2-parameter estimator this is close to complete.

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?

Coverage is 50%: the schema documents gpus (including example ids) but leaves model bare. The description compensates by explaining model's optionality and the listing behavior when it is absent, which is meaning the schema does not carry.

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?

Enumerates exactly what the tool computes — VRAM, GPU count, single-stream and batched throughput, hardware cost, and vendor API price/speed — for self-hosting an open-weights model, which is far more specific than restating the title. It does not explicitly distinguish itself from the sibling estimate_enterprise_ai_cost, which is the only real gap.

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 one concrete usage rule ('Omit model to list available models') and implicitly routes GPU selection through list_gpu_prices, so usage is partly implied rather than stated. There is no guidance on when to choose this over estimate_enterprise_ai_cost or recommend_coding_pc.

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 establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description needn't cover that. It does add genuine context beyond the annotations: the data is documentary ('doc wording') with probe-based evidence for cross-border reachability, and results are unranked facts. It omits pagination, default page size, and whether an empty result is possible.

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?

Compact with no filler sentences, and the domain scope comes first. However, the entire definition is a single colon-led fragment with nested parentheses, and phrases like 'evidence=probe' read as internal shorthand rather than agent-facing prose, making it harder to parse than its length suggests.

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 does the necessary work of enumerating the returnable dimensions (transport, auth barrier, account requirements, pricing, free quota, cross-border status, registry/directory listing), so an agent knows what a record contains. Defaults, result count, and ordering are still missing, but the core need for a read-only catalog lookup is met.

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 only 17% (just `query`), so the description must carry weight. It partly compensates by explaining what `cross_border` actually measures (China<->US handshake via TANDIU, evidence=probe) and by enumerating the dimensions that map to `pricing_model` and `category`. The `limit`, `region`, and `category` semantics remain undefined beyond their enum values, and no default limit is stated.

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 identifies the resource precisely (official MCP servers of major US/Chinese/regional companies and the facts tracked about each), which clearly separates it from the pricing/cost siblings. But it never states the verb — that this is a searchable/filterable lookup over that catalog — so the agent must infer the operation from the name 'find_mcp' alone.

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?

No when-to-use statement, no exclusions, and no routing relative to the closest siblings (get_mcp_changes for change history, about_tandiu_data for methodology). The only implicit guidance is 'Facts only, no scores', which hints at a lookup rather than a recommendation tool, but that is inference rather than instruction.

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 (read-only, idempotent, closed-world), so the bar is lower, and the description adds real context on top: an API key is required, coverage starts July 2026, values are normalized to USD/RMB per 1M tokens, and source URLs are included. It does not mention pagination or row limits, which is the main remaining gap.

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, front-loaded with the Pro/API-key constraint and the data's scope, then the filter list. Dense and mostly waste-free, though the filter sentence largely restates parameter names already visible in the schema.

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 usefully describes the returned data (daily rows, currency units, source URLs) and the history window, which is what an agent needs to interpret results. It omits pagination and default/maximum limit behavior for a 6-parameter tool with zero required params.

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 50%, so the schema documents model/since/until while vendor, country and limit are bare. The description's 'filter by model, vendor, country and date range' confirms these are filters but adds no format, matching semantics or default behavior beyond what the schema already says, leaving the undocumented half only partly compensated.

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 unusual precision: daily official list-price history per model, from July 2026, in USD and RMB per 1M tokens, with source URLs. This clearly separates it from a current-price sibling like list_llm_prices, but it never names an alternative, so an agent must infer the split from the word 'history'.

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 an access precondition ('Pro (API key required)') and enumerates the filter dimensions, which implies how to narrow a query, but it never states when to prefer this over list_llm_prices or list_price_changes, nor any exclusions or rate limits. Usage is implied rather than directed.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new context: the stream is append-only and scoped to tracked official servers within a bounded recent window. It does not state what an omitted days value defaults to.

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 dense sentence with the core scope front-loaded and no filler. The parenthetical list is long but each item earns its place by defining what counts as a change event.

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?

Annotations are rich and parameters are few, but there is no output schema, so the description bears more of the burden for describing what an event record contains; it names event categories but not the event shape or ordering. The unstated default for days is a real gap for a zero-required-parameter tool.

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 must carry both parameters, and it does give both meaning: days as a lookback window and entry_id as an id sourced from find_mcp. However, it omits the default when days is omitted and never mentions the 1-90 bounds, so an agent must open the schema anyway.

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 ("append-only change events of tracked official MCP servers") and enumerates the dimensions tracked (terms/pricing pages, cross-border reachability, tools, status, directory listing). It also distinguishes itself from the sibling find_mcp, which supplies the entry_id rather than returning the events.

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?

"for the last N days, optionally for one entry id from find_mcp" makes the usage pattern and the chaining dependency on find_mcp explicit. It stops short of naming exclusions or when to prefer siblings like list_price_changes over this tool.

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, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description's added value is disclosing the payload contents (change, median, series) in the absence of an output schema, but it says nothing about units, currency, granularity, or how the series is ordered.

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 dense clause with the resource front-loaded and no filler; every phrase (chain-linked, group scope, 30-day change, median, series) carries 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?

For a zero-required-parameter, read-only aggregate lookup with no output schema, the description gives the essential shape of the answer (change, median, series). It falls short only on the 'since' window semantics and the default group, which an agent calling with no arguments would need.

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% ('group' has no description, 'since' only says YYYY-MM-DD). The description partially compensates by glossing the group enum as 'CN, US or all models', but it omits any meaning for 'since' (window start? cutoff?) and does not state the default group when the parameter is omitted.

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 concrete resource (a chain-linked LLM price index) and enumerates what it reports: 30-day change, median price and series. It is more precise than the bare name, though it never explicitly contrasts itself with siblings like list_llm_prices or list_price_changes, so the agent must infer the distinction from 'index' vs 'prices'.

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?

No explicit when-to-use or when-not-to-use statement, and no alternative is named. Usage is only implied by the vocabulary: an 'index ... series' with a '30-day change' suggests trend/aggregate analysis rather than per-model lookups, which overlaps with list_price_changes.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds one genuine behavioral trait, the 'newest first' default ordering, but says nothing about pagination, result caps, or how filtering combines.

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, dense and front-loaded: the resource and fields come first, then ordering and filters. Every clause carries information, though the field enumeration reads slightly list-like.

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 usefully previews the returned fields, and it covers most filter axes for a 7-parameter tool. The missing pieces (limit behavior, sort_by=amount, enum meanings for sector/region) are minor against what 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 coverage is only 29%, so the description must compensate, and it partially does by naming region, sector, company/investor, date, and minimum-amount filters. It leaves 'limit' and the sort_by enum values unexplained beyond the implied 'newest first' default.

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 the resource precisely (funding rounds of AI companies) and enumerates the returned fields (company, business, round, amount, valuation, investors, source links). No sibling tool touches funding data, so differentiation is implicit 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?

The description lists the available filter dimensions (region, sector, company/investor, date, minimum amount) and the default ordering, which implies when the tool is useful, but gives no explicit when-to-use framing or exclusions. No sibling is similar enough to require routing guidance, so the gap is modest.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered without description help. The description adds that results carry specs and monthly prices, which is modest useful context. It does not disclose ordering, pagination behavior despite a limit parameter, or the shape of returned records.

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 front-loaded sentence with no filler or repetition. It is economical, though the absence of a verb makes the brevity feel more like underspecification than tight writing.

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 three-parameter tool with 0% schema coverage, zero annotations needing supplementation aside, and no output schema, the description should at minimum explain the kind enum, the query semantics, and what the listing returns. As written it does not give an agent enough to call the tool correctly with confidence.

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% and there are three parameters. The description explains none of them: 'kind' is an enum but the allowed values (personal/work/platform) are never mentioned, 'query' is undocumented, and 'limit' is unexplained. The description must carry this burden and does not, leaving all three parameters opaque.

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 identifies the resource (cloud agents) and mentions specs and monthly prices, so the domain is discernible. However, it omits the verb entirely – is this a listing, comparison, or lookup tool? The title 'Cloud agents compared' hints at comparison but the description itself never states an action, and it's indistinguishable from a plain product listing versus a comparison tool without guessing.

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?

No when-to-use or when-not-to-use guidance is provided. Siblings like list_llm_prices and list_gpu_prices are adjacent in the pricing domain, and nothing in the description explains when an agent should pick this tool over those or over estimate_self_hosting. The task is left 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 read-only/idempotent/closed-world, so the description's contribution is output semantics: China SXM prices are quoted per 8-GPU node, cloud rentals carry 7-day change and daily median history since 2026-10-18, and few_samples flags thin markets. That is genuinely useful context an agent cannot get from annotations. It still omits result size, ordering, and what an omitted query or boolean toggles do.

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?

It is a single sentence, but a large fraction is a parenthetical model-name enumeration (B300/B200/H200/... RTX 5090/4090D) that could be compressed. The purpose is buried mid-sentence rather than front-loaded, though the coverage list does help an agent check whether its specific GPU is present.

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 appropriately describes returned fields (VRAM, bandwidth, FP16, list price, China price, cloud rental with change and history). However, for a 3-parameter, zero-required lookup tool it leaves the boolean semantics, default behavior, and response shape underspecified.

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 only 33%: query is documented, but with_cloud_rental and china_available_only are bare booleans. The description indirectly explains these by mentioning cloud rental data and China market prices, but never states that the booleans gate those sections or what the defaults are, so it only partially compensates for the 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?

The description enumerates the resource (GPU models, VRAM, bandwidth, compute, list/China/cloud prices) but never states a verb — it is a field inventory rather than a statement of what the tool does. An agent can infer it returns GPU price and spec data, and the GPU focus implicitly distinguishes it from list_llm_prices, but nothing is asserted explicitly.

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?

No guidance on when to call this versus list_llm_prices, estimate_self_hosting, or cheapest_model_for_score, all of which are plausible alternatives. No prerequisites, no mention that all parameters are optional, no statement about what happens with an empty query.

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 read-only, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds useful provenance (which benchmark datasets back the scores), but says nothing about result volume, pagination, or how prices are dated.

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, and the core purpose plus units are front-loaded before the filter/sort note. Slightly more spec-like than helpful, but appropriately sized.

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 five-parameter, no-required-args listing tool with no output schema, the description covers the domain and units well enough to call it, but the 40% schema coverage leaves parameter behavior under-specified and there is no note on pagination or default result size.

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 only 40% across five parameters, so the description should compensate and does not: "Filter and sort" is a generic gesture that adds no field-level meaning. The country hint ("US and Chinese LLMs") loosely maps to the country parameter and the score names loosely map to sort_by values, but limit and vendor remain unexplained in both places.

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 resource (official API list prices in USD per 1M tokens) plus the benchmark sources attached to it, which clearly separates it from siblings like list_gpu_prices and get_llm_price_history. It does not explicitly name a competing sibling or scope boundary, but the resource is unambiguous.

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?

"Filter and sort" gestures at how to drive the tool but gives no when-to-use guidance, no conditions that select it over get_llm_price_history or cheapest_model_for_score, and no prerequisites. The agent must infer its role from the sibling list 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description usefully adds what data is returned and how it is ranked, but says nothing about result size, the effect of limit, or pagination.

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 and a list with no filler; the subject of the listing is front-loaded before the returned fields. Slightly overloaded with field enumerations but every clause carries 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, the description correctly compensates by enumerating returned fields and sort order. However, for a 5-parameter tool it leaves the filter semantics (especially limit and tool_calling) and any result-size expectations 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 60%; model, platform and max_blended_usd carry positive descriptions already. The description adds meaning only by implication (tool calling, pricing dimensions) and never clarifies the filters, matching the baseline for partial coverage.

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: listing where Chinese open models are hosted on non-mainland platforms, and enumerates the returned dimensions (hosting type, regions, pricing vs official, context, tool calling). This clearly separates it from the general list_llm_prices sibling, though it never names that sibling explicitly.

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?

No when-to-use or when-not-to-use guidance. Nothing tells the agent whether to reach for this instead of list_llm_prices, get_price_index, or cheapest_model_for_score, even though those siblings overlap on pricing questions.

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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuinely useful behavior beyond that: this returns a change-log style feed (cuts, increases, newly added models) rather than a point-in-time price table, which is not derivable from the annotations.

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?

One efficient sentence with no filler, and the core scope is front-loaded. However, the single run-on phrase bundles two distinct result types (price changes and newly tracked models) without structural separation.

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 conveying returns and does so partially by naming the two result categories. But it leaves the default 90-day window, the limit cap, and the min_change_pct threshold semantics completely unexplained, which is a real gap for a 3-param tool.

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 only 33% — only 'since' is documented. The description does not mention limit, min_change_pct, or the 90-day default behavior at all, so it fails to compensate for the undocumented parameters.

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 the resource (official list-price changes and newly tracked models) and the specific semantic scope (cuts/increases observed in daily snapshots). It differentiates from list_llm_prices by being a change-event feed rather than a current-price listing, though it never states this contrast explicitly.

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?

No guidance on when to call this versus list_llm_prices, get_price_index, or the other sibling list tools. No mention of defaults, pagination, or result ordering, so the agent must infer usage 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 declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the scope of applicability (Codex / Claude Code hardware) but says nothing about output shape, ranking semantics, or result size — moderate added value only.

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, front-loaded clause with zero filler. However, dropping the verb makes it read as a label rather than a statement of what the tool returns.

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 three all-optional parameters, no output schema, and no annotation gaps, the description still leaves the agent unsure what a call without parameters does and what the response contains. For a recommendation tool the result contract is entirely unstated.

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% for three parameters. The description restates the tier enum values and implies the category values (mac/laptop/desktop), but never explains what 'tier' selects against, what 'category' filters, or what the free-text 'query' matches. It does not compensate for the coverage 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?

States a specific resource (Macs, laptops, desktops) and the dimension being reported (relative speed and tier) for a named use case (running Codex / Claude Code). It is distinguishable from the cost/price siblings, though the sentence is a fragment and never says it 'recommends' outright.

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?

No guidance on when to use this over the sibling pricing tools, and none on how to combine the three optional filters. Nothing explains what an unfiltered call returns versus a tier- or category-filtered one.

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