Trustbase Lab · Trusted Data Infrastructure for the AI Era

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

Beyond the readOnly/idempotent annotations, it discloses the key hidden behavior: when carbon_price is omitted, the tool falls back to the latest EU ETS EUA spot snapshot and cites it in the output. It also states the emission intensity is caller-supplied data rather than the service's own, which materially changes how the result should be trusted.

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?

Labeled sections (Purpose / Guidelines / Limits / Ex) make it scannable and the core formula is front-loaded. The Limits paragraph is dense but every clause carries a material caveat, so it is only mildly longer than needed.

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 calculation tool with an output schema already covering the return payload, the description supplies everything else an agent needs: inputs, the default-price behavior, scope exclusions, and example calls. Nothing required to invoke or interpret the tool 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 coverage is 100%, so the baseline is 3, but the description adds units and provenance semantics (tCO2e per tonne, tonnes, optional price with a cited fallback) plus two concrete example invocations that disambiguate argument meaning. It slightly exceeds what the schema alone conveys.

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 precise verb+resource and even the formula ('embedded emissions multiplied by a carbon price'), which uniquely separates it from siblings like compare_carbon_prices or get_cbam_timeline. An agent can tell instantly what it computes and what it does not.

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 explicit usage context ('order-of-magnitude questions about CBAM exposure') and a clear exclusion zone (not a declarable amount, excludes free-allocation and third-country deductions, not advice). It stops short of naming a sibling tool for the declarable calculation, so routing is implied rather than 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 already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description goes well beyond them by enumerating exclusions (auxiliary loads, transmission losses, demand/capacity charges, green-power premia, carbon cost) and stating the tariff must come from the caller. This is exactly the extra context an agent needs to interpret the number correctly.

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 labeled Purpose/Guidelines/Limits/Ex structure front-loads the formula and keeps the exclusions scannable. It is a dense single block with some run-on clauses, but nearly every clause carries distinct 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?

An output schema exists, so return formatting need not be described, and the description still covers scope limits, defaulting behavior, required inputs, and a worked example. Nothing material for 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 baseline is 3, but the description adds real meaning: the fallback-and-cite behavior of pue, the 8760-hour default, and the energy-only return when electricity_price is absent. language and response_format are left entirely to the schema, which is acceptable.

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 (calculate compute energy cost) and immediately exposes the formula it implements: IT load x PUE x hours (x tariff). This distinguishes it cleanly from siblings like get_pue_benchmarks (data lookup) and calculate_cbam_cost (different cost domain).

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 Guidelines sentence is explicit about what must be supplied (it_power_kw), what is optional, and the conditional behavior of each optional field (missing pue -> cited benchmark; missing electricity_price -> energy only). It does not name an alternative tool to use instead, but the conditions that select this tool are unambiguous.

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 readOnly/idempotent/non-destructive, and the description adds useful context beyond them: thresholds are parsed from regulation records, the source record ID is returned with each row, and the tool is deliberately scoped to one material. It doesn't discuss error behavior or precision/rounding, so not 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?

Front-loaded with labeled Purpose/Guidelines/Limits and a concrete example, so an agent can parse it quickly. It is dense but every sentence earns its place; the embedded example is slightly redundant with the schema but aids invocation.

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 an output schema present, return values needn't be explained, and the description covers scope limits plus the returned source record ID. For a read-only calculation tool the description is essentially complete, with only minor gaps around edge cases (e.g. out-of-range current_pct).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and enums are fully documented, so the schema already carries parameter meaning. The description restates material options and current_pct usage but adds no format or constraint detail beyond the schema; baseline 3 is appropriate.

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/calculate gap) and resource (recycled-content figure vs statutory minimum), scoped to one material and both stages. This is clearly distinguishable from siblings like get_recycled_content_requirements and query_battery_recycling_targets, which fetch requirements rather than compute a 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?

Explicitly says to supply material and current_pct, and adds strong negative guidance: one material at a time, NOT a whole-battery compliance finding, not advice or a declaration basis. It lacks a named alternative sibling (e.g. where to go for whole-battery compliance), which keeps it from a 5.

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 and idempotent behavior, and the description adds useful context: it is pure arithmetic, performs no market data access, and is not a price recommendation. This is consistent with the annotations and clarifies side-effect expectations well.

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 description is well structured with Purpose, Guidelines, Limits, and an Example. Every section adds useful information and the essential behavior is front-loaded before the example.

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 simple arithmetic tool with a complete input schema, output schema, and clear annotations, the description covers purpose, inputs, workflow, limits, and gives a concrete example. An agent has enough context to invoke it correctly and confidently.

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 baseline is 3, but the description adds meaning by identifying which price is the native price, which is the rCB price, and how the replacement ratio and annual volume fit into the calculation. The example with 'N330 12000 RMB/t vs rCB 8000 RMB/t, ratio 0.3, annual 5000t' clarifies units and usage 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?

The description clearly states a specific verb and resource: it computes per-ton saving and optional annualized value from native and rCB prices plus replacement ratio. It also distinguishes itself from data-fetching siblings by emphasizing 'pure arithmetic - no market data access'.

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 gives concrete guidance: supply your own quotes, or fetch market anchors via get_rcb_index first. It also states what the tool is not for ('not a price recommendation'), though it could more explicitly name sibling comparison/boundary tools as alternatives.

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, so the safety profile is covered. The description adds non-obvious behavior beyond that: same-currency spreads are computed values, currencies are deliberately not converted, and prices are dated snapshots rather than live quotes. It stops short of describing the response shape or snapshot freshness/staleness, but the added constraints are substantive.

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, then Guidelines, Limits, examples and a scoped summary; each section is one or two clauses and earns its place. It is on the long side for a zero-required-parameter tool, and the repeated 'same currency' constraint appears twice, but there is 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?

An output schema exists, so return structure needn't be explained. Given a two-optional-parameter, read-only comparison tool, the description covers scope, trigger conditions, the FX limitation, and the sibling alternative - everything an agent needs to select and invoke it correctly.

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% with enum values and defaults documented for both parameters, so the schema carries the semantics. The description only supplies example invocations (compare_carbon_prices(language='en')), which shows usage but adds no meaning about what language or response_format actually control. 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 ('put every carbon price snapshot side by side') and enumerates the compared dimensions (market/basis, value, unit, date, source, spread). It explicitly distinguishes itself from the sibling get_carbon_market_overview by labeling its scope as 'SIDE-BY-SIDE comparison only', so an agent can route 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 concrete triggering questions ('how do EU and China carbon prices compare', 'what is the spread between auction and secondary prices') and names the alternative tool with the condition that selects it. It also states exclusions - no cross-currency difference because no FX rate exists - so when-not-to-expect-output is 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 already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the methodology caveat: thresholds follow the site's anchored-benchmark approach, not customer specs. It also discloses that no lab data is on file and that it classifies rather than just returns numbers — useful context that annotations cannot carry.

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 labeled blocks (Purpose / Guidelines / Limits / Ex) and every sentence carries information; the key list is dense but necessary. Slightly long sentences in the Purpose block keep it from being maximally tight.

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 need not be explained, and the description covers inputs, threshold behavior, and methodology limits. The one gap is whether rcb_params may be partial or which keys are mandatory — the schema marks only the object as required, not its inner keys.

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%, but the schema example shows only one key for the nested rcb_params object; the description enumerates the exact eight accepted keys and explicitly warns off common wrong names (OAN/BET/ash), which materially prevents malformed calls. That is real value beyond the schema text.

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), the resource (measured rCB sample parameters vs a target native CB grade's spec ranges), and even the output form (pass / light deviation / significant deviation per parameter). It is clearly distinguishable from spec-lookup siblings like get_grade_spec, which return ranges rather than grade a sample against them.

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 concrete use case — grading incoming rCB lots against a native anchor before substitution decisions — plus a hard precondition (measured lab values must already exist). It does not name explicit alternatives (e.g. get_grade_spec for raw specs or get_substitution_boundary for limits), so the routing guidance is clear but not exhaustive.

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 the safety profile is covered. The description adds genuine non-annotation context: shares follow published tallies and agencies count families vs filings differently, so cross-source comparison needs care. That data-reliability caveat is exactly the kind of behavioral disclosure that helps an agent interpret results.

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/Guidelines/Limits/Ex structure is front-loaded and each labeled line earns its place. The trailing 'Ex: get_6g_patent_landscape()' is mildly redundant, showing a zero-argument call that adds little beyond the 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?

With an output schema present, return values need not be described, and annotations cover the safety profile. The description supplies purpose, usage trigger, and a data caveat, leaving little an agent needs missing before calling 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?

Schema description coverage is 100% with documented keyword, language, and response_format parameters, so the schema carries the parameter burden. The description adds no parameter detail beyond that, which is the expected baseline when structured fields are complete.

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 resource (the 6G core patent landscape) and its breakdown dimensions (by country and by company), which is far more precise than a tautology. The verb is nominal ('the landscape') rather than an explicit action verb, but the resource is unambiguous and no sibling covers patents, so routing is easy.

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 Guidelines line gives a clear trigger condition: 'use when a question needs the competitive patent picture.' It states when to use it but names no exclusions or alternative tools, which is forgivable since no sibling overlaps in the patent domain.

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 indicate read-only, idempotent, non-destructive behavior, so the description adds meaningful extra transparency: results are 'announcement-derived items only,' claims are 'not independently confirmed,' full press-release text is not served, and coverage depends on public announcements. These caveats go beyond what annotations convey.

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 description is organized into Purpose, Guidelines, Limits, and Ex sections, with the core purpose stated first and every sentence serving a distinct function. It is thorough without being verbose.

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?

Given the output schema, read-only annotations, and only four optional parameters, the description fully covers what the tool does, how to filter, when to use companion tools, what limitations exist, and how to call it with examples. No critical information 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 applies. The description adds usage examples and repeats the date format, but it does not meaningfully extend the parameter-level meaning already present in the schema descriptions.

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 action and resource: 'return a chronological timeline of company announcements across the rCB industry - results, capacity, certification and delivery approvals.' This makes the tool's function unmistakable and distinguishes it from the broader lookup and article 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?

The Guidelines section gives explicit usage context: filter by region and date range, and use alongside query_companies when tracking capacity build-out or with query_policies when regulatory dates matter. The Limits section further clarifies when the data should not be over-interpreted, such as absence not being evidence of inactivity.

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, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it explicitly states the full article body is not served, one record per call, and that the output is metadata plus an AI-readable summary. This is useful because an agent might otherwise assume it gets the full article text.

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 description is compact and well-structured with labeled sections (Purpose, Guidelines, Limits, Ex). Every sentence earns its place: purpose, usage routing, limits, and an example. It is front-loaded with the core purpose and scoping, and the example clarifies parameter usage without bloat.

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?

Given the tool's simplicity (read-only single-record fetch), the annotations cover safety, the schema covers parameters, and the description covers usage routing, limits, and examples. The output schema exists, so return values need not be described. Nothing an agent needs to call this tool 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 schema already documents all four parameters. The description adds value by explaining the relationship between id and name (either/or, id from query_articles, name is a title keyword) and by giving concrete examples (get_article(id='rcb-art-001'), get_article(name='曼谷大会')). This goes beyond the schema's per-parameter descriptions.

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 ('fetch') and resource ('one article record in full') and enumerates the exact fields returned (title, publish date, author, account, topic category, source URL, confidence, AI-readable summary). It also distinguishes itself from siblings by naming query_articles and get_announcements_timeline, so an agent can tell it apart without opening 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?

The description explicitly says when to use it: accepts the id from query_articles or a title keyword; run query_articles first when the id is unknown; pair with get_announcements_timeline for a chronological view. It also states limits (metadata and summary only, one record per call), which helps an agent decide whether this tool fits the task.

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 readOnly, idempotent, non-destructive, closed-world. The description adds genuinely new behavioral context: modelled figures are labelled as such in record names, the scope is China-only, and modelled values are not official statistics. That provenance caveat is the most valuable disclosure here and is not derivable from the structured fields.

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?

Labelled Purpose/Guidelines/Limits/Ex sections make it skimmable and front-loaded. Slightly over-tight repetition of the 'modelled' caveat across Guidelines and Limits costs a little, but every line still carries content.

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?

Output schema exists, so return-value explanation is correctly omitted, and annotations cover the safety profile. Scope, provenance, and usage trigger are all supplied; only the absence of any parameter-level note for the three optional inputs keeps it from being fully 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?

Schema description coverage is 100% and the description makes no mention of keyword, language, or response_format, so it adds nothing beyond the schema. Baseline 3 applies since the schema carries the full parameter burden and only the zero-required-parameter shape is implied.

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 ('China battery-recycling market statistics') and enumerates the concrete payload (collected volumes, processor counts, NEV output, modelled future volumes). This distinguishes it from nearby siblings such as query_battery_recycling_targets, get_battery_regulation_timeline, and get_elt_recycling 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?

'Use when a question needs scale rather than rules' gives an explicit selection heuristic that routes the agent away from rule/regulation tools. It stops short of naming a specific sibling alternative, so it is clear context without full when/when-not 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuine domain context: dates are applicability dates, and conditional items only apply after the delegated act enters into force (later of the two triggers). That is useful behavioral nuance 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?

The Purpose/Guidelines/Limits/Ex structure is well organized and front-loaded, with every section earning its place. It is slightly dense, but there is no filler sentence.

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 an output schema present, rich annotations, and full parameter documentation, the description need not cover return values. Combined with the usage routing and the conditional-item nuance, an agent has everything needed to call it correctly.

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 keyword, language, and response_format, and enum/defaults are declared there. The description only adds a Chinese keyword example ('护照'), which is marginal 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?

The description states a specific resource (EU and China battery regulation timeline) with concrete content (applicability dates, legal bases, amendments, conditional items) in an ordered view. This clearly differentiates it from sibling timelines like get_cbam_timeline, get_telecom_policy_timeline, and get_announcements_timeline.

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 explicit routing advice ('call first for any battery-regulation date question') and enumerates triggering domains (passport, recycled content, due diligence, carbon footprint). It lacks a when-not statement or a named alternative sibling, which keeps it short of a 5.

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, openWorld=false), yet the description adds non-obvious behavioral limits: prices are dated snapshots from cited sources and NOT live quotes, and currencies are not converted so cross-currency comparison requires an FX rate. It also states the one-market-at-a-time scope, which constrains how results should be interpreted.

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 Purpose line and organized into Purpose/Guidelines/Limits/Examples/Scope, so an agent can stop reading at any block. Every sentence carries load: the examples demonstrate valid calls and the Scope line resolves the sibling ambiguity.

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?

Output schema exists, so return-format explanation is unnecessary; the description closes the remaining gaps an agent needs before calling - staleness of data, currency non-conversion, market filtering, and the sibling routing rule. Complete for a zero-required-param read tool of this complexity.

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% with all three parameters documented, so the baseline is 3; the description goes further by framing market as an EU/China narrowing filter and supplying concrete invocation examples (market='cn', market='eu', language='en') that show valid combinations. It adds value beyond the enum labels, though not deep semantic detail on each parameter.

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+scope: 'one-call overview of the carbon market layer' covering price snapshots, market size statistics, and allowance allocation rules with named issuers/sources. It clearly distinguishes itself from compare_carbon_prices, so an agent can route 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 explicit use cases ('what is the carbon price / how big is the market / how are allowances allocated'), the narrowing action (filter by market), and an explicit exclusion routing cross-market comparison to compare_carbon_prices. Nothing 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 declare read-only, idempotent, non-destructive, closed-world behavior. The description adds meaningful context beyond them: the entries include status, as-of date, issuer and confidence grade, and it explicitly caps the tool's scope at the catalogue with no interpretive output. It does not discuss pagination, but for a read-only lookup that is minor.

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 labeled sections (Purpose, Guidelines, Limits, Ex) so an agent can scan purpose first and constraints last. It is somewhat long, but every block contributes routing, boundary, or example value 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 an output schema present, return-value explanation is unnecessary. Purpose, when-to-use, explicit scope limit, entry fields, and example calls together give an agent everything needed to call this 4-parameter optional tool correctly.

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 baseline is 3. The description goes further by giving concrete invocations that illustrate how status and keyword are actually used (status='withdrawn', keyword='14067'), clarifying intent beyond the schema's field-level text.

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 (the carbon accounting standards library) and enumerates its contents (ISO 14064 series, ISO 14067, ISO 14068-1, GHG Protocol, withdrawn standards like PAS 2050) with the fields each entry carries. This clearly separates it from sibling catalogue tools such as get_standards_roadmap or get_policy.

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 when to use it (questions about which standard governs an organisation-level inventory, a product carbon footprint, or a verification statement), an operational filter tactic (status='withdrawn' to check whether a standard still applies), and an explicit boundary (catalogue only, no interpretation for a specific company).

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/openWorld=false, so the safety profile is covered. The description adds real behavioral context: it is timeline-only, dates are sourced from cited documents and 'not forecasts', and the phase grouping is the tool's own rather than the EU's official staging. These caveats are exactly the kind of disclosure 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?

Front-loaded and labelled (Purpose / Guidelines / Limits / Ex), so an agent can skim to the relevant section. It is somewhat dense, with the Limits block slightly overlapping the grouping explanation already implied in Purpose, but every sentence carries 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?

With an output schema present, return-value explanation is unnecessary, and the description still covers purpose, trigger conditions, phase grouping logic, sourcing caveats and a companion tool. Nothing an agent needs to call 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% and both enum params (language, response_format) are documented in-schema, so the baseline is 3. The description only adds invocation examples (get_cbam_timeline(language='en')) and does not explain defaults or format tradeoffs beyond what the schema states.

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 and scope: 'the CBAM timeline as a single ordered view' spanning the founding regulation, transitional period, definitive regime and surrender phase. The CBAM specificity clearly separates it from other timeline siblings such as get_battery_regulation_timeline or get_telecom_policy_timeline without needing to name them.

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 says 'call this first whenever a question involves CBAM dates, obligations or scope' and supplies trigger phrases ('when does CBAM start', 'when must certificates be surrendered'). It also names a downstream pairing, get_domain_benchmark(id=...), for source URLs, which is genuine when-to-use 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 readOnly/idempotent/non-destructive, so the safety profile is free; the description instead spends its budget on provenance and epistemic limits — factual statements grade A (official documents), the crosswalk itself grade B (Lab judgment, not an official mapping), and no mutual-recognition document as of 2026-10-26. That is exactly the caveat an agent needs before quoting output, though it does not describe result size 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?

Front-loaded with a labeled Purpose/Guidelines/Modes/Limits/Ex structure so an agent can scan to the needed section, and every labeled block carries decision-relevant content. It is on the long side and the trailing examples partially restate the mode descriptions, which keeps it from a 5.

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-param lookup tool with an output schema and full annotation coverage, the description supplies everything an agent lacks structurally: mode semantics, provenance grading, the explicit date-stamped absence of an official mutual-recognition document, and companion tools. Return-value details are correctly left to the output schema.

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 baseline is 3; the description earns more by adding a constraint the schema does not enforce — 'mode=lookup (default, needs product=)' despite an empty required array — plus worked examples showing a Chinese product term and response_format='json'. The keyword alias and language parameter are left to the schema, which is acceptable.

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 ('China-EU carbon footprint crosswalk', per-product comparison of CN certification vs EU CBAM/CSRD/ESPR requirements) and enumerates the exact outputs (overlap, shareable data, open gaps). It also names the adjacent tools (get_carbon_standards, query_cbam_emission_factors) and clarifies it is the crosswalk layer, not the underlying standards, so it is distinguishable from 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?

Gives explicit trigger conditions: 'call this whenever a question involves exporting to the EU, dual compliance, does China's certification get recognized by the EU, or comparing Chinese vs EU carbon requirements.' It also routes to alternatives for underlying data and says which mode to pick for which question, which is genuine when-to-use guidance.

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/openWorld=false, and the description adds real behavioral context beyond them: one record per call with no batch mode, low-confidence records returned with a C label rather than withheld, and name lookup returning only the first match (not a disambiguation service). These are operational traits an agent cannot infer from structured fields.

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 Purpose/Guidelines/Limits/Ex structure with worked examples that earn their place. It loses a point for the garbled clause 'sourced fields (capacity, investment, contacts) may all fields are public', which breaks the sentence mid-thought and slightly muddies the Limits section.

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 an output schema present, return-value detail is unnecessary, and the description covers everything else an agent needs: lookup modes, parameter toggles, scope limits, confidence handling, and examples. Nothing needed to call 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 coverage is 100%, so baseline is 3; the description adds value by giving id format examples (rcb-cn-xxx / rcb-gl-xxx / rcb-eq-xxx), clarifying name is a fuzzy Chinese-or-English keyword lookup, and explaining language='en' and response_format='json' intent. It stops short of documenting the anyOf id-or-name requirement explicitly, but the examples and guidelines effectively convey it.

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 (fetch) and resource (one company/project record), enumerates the entity types covered (rCB producer / international player / equipment vendor), and specifies what is returned (capacity, process, certification, investment, developments, source). An agent can tell it apart from query_companies, the search sibling, 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 routes the agent: ids come from query_companies, use name for fuzzy lookup when the id is unknown, and it notes language/response_format toggles with concrete examples. The alternatives and the condition selecting each lookup mode are spelled out, not 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 declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds substantive scope context by disclosing that data is aggregated to hub/cluster/city granularity only and that no precise coordinates exist, which meaningfully shapes what an agent can expect.

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?

Labeled sections (Purpose/Guidelines/Limits/Ex) front-load the key information efficiently with no wasted prose. The trailing 'Ex: get_compute_infrastructure().' example adds little beyond signaling that no arguments are required, a minor redundancy.

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-format explanation is unnecessary, and annotations carry the safety profile. The description adequately covers scope and granularity limits; only the absence of any alternate-tool routing keeps it from being fully 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?

Schema description coverage is 100% and all three parameters (keyword, language, response_format) are self-documented in the schema. The description adds nothing about parameter usage, so the baseline 3 is appropriate.

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 clear verb (get) and resource (compute infrastructure) and enumerates the specific contents held: rack counts, intelligent-computing capacity, hub/cluster aggregates, and the national scheduling platform. The scope is unambiguous, though it doesn't explicitly contrast itself against any neighboring 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?

'Guidelines: use for scale questions' gives a clear triggering context, and the Limits clause establishes what it will NOT return (precise facility coordinates). No sibling alternative is named, so it falls short of a full when/when-not/alternatives disclosure.

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, idempotentHint, destructiveHint=false), so the bar is lower. The description adds genuinely useful disclosure beyond annotations: counts are static public catalogue snapshots rather than live tracking, and the UCS database stopped updating in 2023-05, so source vintage must be checked.

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?

Explicitly labeled Purpose/Guidelines/Limits/Ex sections keep it front-loaded and scannable, with no wasted sentences. The template phrasing is slightly mechanical but every line 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 an output schema present, return format need not be explained. The description covers scope, usage, and the important data-vintage caveat, leaving only alternative-tool routing unspecified.

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% and the description adds no parameter-level detail (keyword semantics, language behavior, format tradeoffs) beyond what the schema already documents. Baseline 3 applies when the schema carries the full burden.

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 (constellation status) and enumerates exactly what is returned: in-orbit counts for Starlink, Qianfan, Guowang, OneWeb and Amazon Leo, annual launch totals, and planned sizes. This distinguishes it clearly from sibling telecom/carbon/standards tools.

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?

"use for constellation scale questions" gives clear context for when to reach for it. However, it names no alternative tool and gives no exclusion condition, which is what would be needed for a 5.

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 the safety profile is covered. The description adds real behavioral context beyond that: 'metadata only - no record content' and 'counts refresh with each data release' tell the agent what it will and won't get and that counts are release-dependent.

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?

Organized with Purpose/Guidelines/Limits/Ex labels so the key routing instruction is front-loaded and scannable. Every clause adds information (payload contents, routing, limits, examples) with 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?

An output schema exists, so return-value detail is unnecessary, and the description still states its metadata-only scope and refresh behavior. For a read-only overview tool with two optional, well-documented enum params, nothing an agent needs to call 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 coverage is 100% with enums and defaults already documented, so the schema carries the parameter burden. The description echoes the intended usage ('language=en', 'response_format=json for Agent processing'), which is a light reinforcement but largely restates what the schema description already says, landing at the 3 baseline.

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 (dataset overview) and enumerates the payload: version, per-table record counts, entity-ID rules, confidence grading, supplier counts, tool index, module map. It clearly distinguishes itself from the query_* siblings by framing itself as the discovery entry point rather than a data query.

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 says to call this FIRST when discovering the server, then route to specific query_* tools, which tells the agent both when to use it and which alternatives to use afterward. It also gives example phrasings ('what data does this server have', 'list available tools') that clarify the trigger conditions.

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, closed-world behavior, so the description only needs to add domain context. It does: it warns that the three bodies' scopes differ and that their numbers must not be merged, and it flags the output as reference rather than personal advice — a genuinely useful caveat absent from the structured fields.

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?

Labeled fragments (Purpose/Guidelines/Limits/Ex) front-load the scope and constraints with no filler. The inline example earns its place by demonstrating invocation, though it repeats information the schema already implies.

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 formatting need not be explained, and all three optional parameters are documented in the schema. The description supplies the domain caveats an agent needs (source scope, no cross-body merging, non-personal advice) but omits any note about result volume or whether coverage is exhaustive across the three bodies.

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% with enums and defaults documented, so the baseline is 3. The description adds a worked example showing a Chinese-language keyword, which confirms bilingual keyword input in practice and slightly exceeds the schema's terse '中英均可'.

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 (dietary guideline entries) and confines scope to three named bodies (WHO, China, US), which is enough to separate it from query_dietary_limits and the broader query_* tools. It stops short of naming that sibling explicitly, so the differentiation is inferential 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?

'use when a question asks what a guideline body recommends' gives a clear triggering condition, and the Limits line adds an exclusion (reference only, not individual advice). It never names the nearest alternative (query_dietary_limits) or says when that one is preferred, so routing still requires 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 (readOnly, idempotent, non-destructive), but the description adds real behavioral context beyond them: one record per call, carbon prices are dated snapshots rather than live quotes, and the health domain offers no diagnosis, treatment or dosing guidance. It does not say what happens if both id and keyword are omitted or both supplied (schema lists zero required params), which is the one unanswered behavioral question.

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 purpose, then Guidelines, Limits and an example, so an agent can stop reading early. Slightly padded by enumerating return fields that the output schema already documents, but no sentence is irrelevant.

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 need not be explained, and the description still covers what to pass, why to call it, and domain-specific caveats. The remaining gap is the unspecified resolution behavior when neither or both of id/keyword are supplied, given that the schema marks no parameters as required.

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, and the description earns an increment by restating the id/keyword mutual exclusivity in operational terms and showing example values including language. It adds modest semantic value (e.g. 'distinctive keyword') rather than new parameter detail.

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 ('fetch one cross-domain benchmark record by ID or keyword') and enumerates the returned fields, so an agent immediately knows this is a single-record lookup rather than a search. It is clearly distinguished from the sibling query_domain_benchmarks, which is the tool that produces the IDs consumed here.

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 the workflow: take the ID returned by query_domain_benchmarks or supply a distinctive keyword, and invoke this 'whenever a cross-domain fact is going to be quoted' so the citation carries a source link. Concrete example calls are provided for both the id and keyword paths.

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 the description layers on substantive behavioral context beyond them: values are index-only and unit-less, cannot be reverse-engineered into absolute prices, absolute prices and source platforms are never disclosed, the series is monthly with base month = 1000, and regions are deliberately excluded from a category when caliber is not comparable (China bead wire vs EU/US mixed wire). No contradiction with 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?

Front-loaded with labeled 'Purpose'/'Guidelines'/'Limits' sections and closing examples, which is good structure, but the prose is very long and partly redundant ('This series is index-only and unit-less' is restated as 'index values, region spreads and ratios only - absolute prices ... never disclosed'). Several sentences could be merged without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return values, and it instead covers the residual gaps an agent would care about: index-only semantics, unit-lessness, base month, the region-comparability exclusion rule, and cross-tool pairing. Nothing required to select or invoke the tool 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 coverage is 100% and the schema already documents tier/region/category, so the baseline is 3; the description goes further by explaining the semantics of each mode (tier 1 vs tier 2, region codes EU/US/CN/CA/IN, category codes and their expansions) and how the parameters compose. It does not, however, state behavior for invalid or conflicting combinations.

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 resource (rCB feedstock / end-of-life tyre price index) and precisely scopes it: Tier 1 global categories (G-TPO/G-CRB/G-WIRE/G-RCB), Tier 2 region-specific categories, and an index-only public-source series with base month 1000. It explicitly distinguishes itself from get_feedstock_overview (arisings/processing paths) and get_rcb_index (layered rCB product prices), so an agent can route between them 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?

The 'Guidelines' block gives an explicit condition-to-result mapping: no arguments = global cross-section with region spreads, pass region = that region's index across categories, pass category = one category's region comparison. It also names two complementary siblings to pair with. It stops short of stating when NOT to use this tool or which sibling supersedes it in ambiguous cases.

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, and non-destructive behavior. The description adds meaningful behavioral context: official sources are labelled per record, market-size figures are public-information compilations and labelled as such, and the tool deliberately excludes prices. This goes beyond the annotation safety profile and helps the agent set expectations about data provenance and coverage.

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 description is well-structured with labelled sections (Purpose, Guidelines, Limits, Ex). Each sentence contributes either scope, usage direction, limitations, or examples. Despite being longer than average, there is no redundancy, and the most important purpose and usage information is front-loaded.

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 tool with 2 optional parameters, an output schema, and clear annotations, the description fully covers what the tool returns, how to filter it, what it excludes, and how it relates to sibling tools. The examples illustrate realistic queries. Nothing an agent needs to select and invoke the tool 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 coverage is 100%, so the schema already documents both parameters. The description adds value by explaining that no arguments returns the full topic, that topic narrows to one section, and by giving concrete query examples for topic values. This clarifies parameter usage beyond the schema's terse value list.

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 precise statement of the resource: the end-of-life tyre (ELT) collection topic for the rCB supply chain, enumerating specific content areas (policy targets, 2026 standard system, collection network, value ladder, market sizes). It also names the sibling tools it should be paired with and clarifies it does not return prices, effectively distinguishing it from get_elt_price_index and get_feedstock_overview.

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 Guidelines section is explicit: call with no arguments for the full topic, or pass a topic value to focus one section. It also names alternatives and complements: pair with get_elt_price_index for collection prices and get_feedstock_overview for arisings. Limits explicitly state what this tool does not do (returns prices), so an agent knows when not to use it.

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 the tool read-only, idempotent, and non-destructive, so the bar is lower. The description still adds valuable behavioral context: figures come from official and industry-association sources, each record is labelled with its statistical body, and data from different bodies must not be merged due to scope differences. It also clarifies that the tool does not return prices. This goes well 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?

The description is well-structured with labeled sections: Purpose, Guidelines, Limits, and Ex. It front-loads the scope and the price-tool alternative, then packs source caveats and examples into a compact format. Every sentence earns its place, and there is 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 read-only overview tool with an output schema, no required parameters, and strong annotations, the description is complete. It covers what the module includes, the source caveats, when to use it, what it does not return, and example queries. Nothing an agent needs to invoke and interpret 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 coverage is 100% for both parameters, so the baseline is 3. The description adds meaning to the region parameter by explaining it focuses the arisings table. However, it lists region values as CN/EU/US without mentioning GLOBAL, despite GLOBAL being valid in the schema enum; this is a minor gap. Language is optional and self-explanatory, so no additional description is needed.

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 precise purpose: an overview of the rCB feedstock module covering waste tyre arisings, recovery volumes, the processing-path value ladder, and module categories. It explicitly separates itself from pricing tools by stating it does not return prices and naming get_elt_price_index as the price tool. The title 'Feedstock Price Overview' is slightly misleading, but the description resolves this 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?

The description gives explicit when-to-use guidance: use this tool before quoting feedstock availability or recovery-rate figures, then use get_elt_price_index for prices. It also explains the effect of the region parameter on focusing the arisings table. This is strong, actionable guidance with an explicit alternative 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, but the description goes well beyond them: it discloses what each record carries (verbatim citation quotes, section locator, retrieval timestamp, source and record content hashes), the assertion_kind semantics, and hard limits (no individualised advice/diagnosis, copyrighted material metadata-only). That is exactly the extra behavioral context a caller needs.

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?

Long, but explicitly labeled (Purpose / Guidelines / Limits / Ex) and front-loaded so the agent gets the core action first. Density is justified by the domain-contract and assertion_kind detail, though a few clauses could be trimmed.

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, yet the description still outlines the richness of the returned record and the domain contract, covers id/name acquisition, language and format options, and states the domain's hard boundaries. Nothing needed to call 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 coverage is 100%, so the schema already documents all six parameters (baseline 3), but the description adds real meaning: name acts as a keyword that returns a candidate id list on multiple hits, kind narrows the match, and include_domain_contract is tied to the specific contract contents returned.

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 precise verb and resource ('fetch one full record from the fitness safety-boundary domain') and enumerates the three record types (exercise, condition, exercise x condition boundary). It also clarifies the relationship to the sibling query_safety_boundaries, so an agent can distinguish it 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?

Explicitly tells the agent where to get the id ('from query_safety_boundaries first') and when the name-keyword fallback applies ('when the match is unambiguous'), plus when to set include_domain_contract=true. It even gives concrete invocation examples.

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), and the description adds real value beyond them: the data is compiled from public specifications and is not a supplier's guaranteed certificate of analysis, the gap analysis is anchored to N550 only, and only one grade is returned per call. It stops short of describing failure behavior when an id or name matches nothing.

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 / Guidelines / Scope / Limits / Ex structure is front-loaded and skimmable, with an explicit example block that removes ambiguity. It is on the verbose side for a single-lookup tool, but nearly every clause carries distinct information (record contents, lookup keys, sibling routing, data provenance).

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 detail is not needed, and the description covers the remaining agent-critical questions: what fields the full record holds, which keys to use, which sibling to pick instead, and what the data's limits are. Nothing needed to call 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 coverage is 100%, so the baseline is 3, but the description goes further by clarifying that id and name are alternatives (schema does not state '二选一' semantics as prominently), giving example values for each, and showing an actual call shape combining name with response_format. Marginals add meaning beyond the schema text.

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 ('fetch one carbon black grade in full') with an explicit inventory of what the record contains (ASTM parameters, application list, process route, brand owner, rCB gap analysis). It directly distinguishes itself from the closest sibling by stating that get_grade_spec returns only the bare ASTM parameter table.

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?

Names both lookup keys (semantic id or grade name) with concrete examples, routes the agent to query_grades for discovery and get_grade_spec for spec-only needs, and states the explicit exclusion: 'For a bare ASTM parameter table only, use get_grade_spec instead.' A Limits block adds scope caveats, so there is essentially no inference left.

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, so safety is covered. The description adds real behavioral context beyond annotations: it explicitly limits output to spec ranges and excludes lot-specific CoA data, which sets expectations about result scope. Output format is deferred to the output schema, which is appropriate.

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, then Guidelines, Limits, Examples, and Scope, so key routing info comes first. It is dense but each labeled section earns its place; the ⭐ marker is minor decoration that borders on unnecessary but doesn't harm retrieval.

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 detail needn't be in the description, and the description supplies purpose, filtering, limits, examples, and sibling differentiation. Nothing needed to call 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 coverage is 100%, so the baseline is 3, but the description adds value by giving concrete grade examples (n330, n550), explaining the type filter (native/conductive/rcb), and enumerating which spec fields are judged (iodine_absorption, dbp_absorption, etc.). This meaningfully augments the terse schema descriptions.

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 (get) and resource (ASTM spec parameter ranges for carbon black grades) with explicit scope (N110-N990, conductive, rCB). It distinguishes itself from the sibling get_grade by labeling itself the SPEC-ONLY quick lookup, so an agent can route correctly 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 explicit when-to-use guidance (judge whether an rCB sample falls in spec by listing the relevant properties), concrete example queries, and a clear exclusion routing to get_grade for application/process/gap analysis. Nothing 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?

The annotations already establish read-only, idempotent, and non-destructive behavior. The description adds valuable non-obvious context: the index is dimensionless, non-tradable, must never be converted to an absolute price, and early periods may carry forward an anchor with output flags.

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 description is organized into Purpose, Guidelines, Limits, and Ex sections. It is compact, front-loaded with the core purpose, and every sentence carries actionable information without redundancy.

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 tool with an output schema, rich annotations, and only four parameters, the description is fully complete. It covers what the tool returns, how to call it, how it relates to siblings, and important interpretive caveats.

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 baseline is 3. The description adds meaningful value beyond the schema by explaining defaults (P2, CN), the YYYY-MM date format, and providing usage examples for valid parameter combinations.

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: 'return the historical series of the layered rCB index for one grade tier.' It names the exact fields returned and clearly distinguishes this tool from siblings like get_rcb_index and get_price_trend.

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?

Provides explicit guidance: grade defaults to P2 in CN, date format must be YYYY-MM, and pairing with get_rcb_index or get_price_trend is recommended for different analytical needs. It also includes concrete examples showing valid calls.

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 and non-destructive, so the safety profile is covered. The description adds material context beyond that: it is reference-only and explicitly not diagnostic, and it warns that BMI/waist cut-offs diverge between WHO and China standards. This is meaningful behavioral disclosure not captured by 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?

Labeled sections (Purpose/Guidelines/Limits) front-load the key information and every clause contributes. The trailing "Ex: get_health_indicators()" is slightly redundant for a zero-required-parameter call, but overall it is tight.

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 need no explanation. Combined with the stated purpose, usage rules, and standards warning, the description gives the agent enough to invoke and interpret the tool correctly; only explicit sibling routing is absent.

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% with enums documented for language and response_format, so the schema carries the parameter burden. The description adds no parameter-level detail (e.g., what keyword matches), leaving this at the baseline.

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 ("health indicator reference values") and enumerates the exact content: BMI classes, waist thresholds, body-fat reference points. This clearly separates it from siblings like get_dietary_guidelines and query_health_myths, though it never names an alternative 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?

Provides invocation rules ("ALWAYS state which standard is being used", "never mix them") that govern correct usage, which is genuinely useful. However, it never says when to prefer this tool over alternatives like query_health_myths or get_dietary_guidelines, so selection remains inferred.

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, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond them: single-record scope, the absence of legal opinion/applicability output, and the JSON-for-pipelines option. It does not mention auth or rate-limit behavior, so not a full 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?

Front-loaded with a labeled Purpose/Guidelines/Limits/Ex structure that is easy to scan and contains no filler prose. The three closing examples are slightly redundant (name='CBAM' and name='2023/956' illustrate the same idea), keeping it short of a 5.

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 documentation is not required, yet the description still names the fields returned. Combined with the id/name alternative explanation, the query_policies dependency, and the exclusions, an agent has everything needed to call this correctly.

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 schema already documents id, name, language, and response_format. The description reinforces with concrete value formats (rcb-pol-001, 'CBAM', '2023/956') and ties id to its source query_policies, but adds little syntax the schema lacks. 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+resource ('fetch one regulation record in full') and enumerates the returned fields (issuing body, policy type, scope, impact, deadline, source link, AI summary). It clearly distinguishes itself from the list-oriented sibling query_policies by emphasizing 'one record per call'.

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 routes the agent: use the id from query_policies (rcb-pol-xxx) or a name keyword, and 'run query_policies first when the id is unknown.' It also states the exclusions (no legal opinion, no applicability assessment) and the response_format='json' path for agent pipelines, so when-to-use and when-not are both covered.

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 the safety profile (readOnly, idempotent, non-destructive). The description adds genuinely non-obvious behavioral context: the two calibers differ ~15% and MUST NOT be mixed. That is a real domain constraint an agent could not infer. Minor gaps: no note on freshness/coverage of the data.

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/Guidelines/Limits labels and an example, so an agent can scan it quickly. Slightly padded by the explicit section headers for such a short body, but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and annotations cover mutability. The description supplies the essential domain caveat (don't mix calibers). Missing only cross-references to the cost/energy siblings that a fully complete definition would provide.

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% and two parameters have enums, so the schema already documents keyword, language and response_format. The description adds nothing about parameter behavior (e.g. what keyword matches, when to choose json). Baseline 3 is appropriate.

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 (compute) and resource (power consumption statistics) and adds unusual scope detail: two official calibers plus data-centre cost structure. This distinguishes it from vague siblings, though it doesn't name a specific sibling it might be confused with (e.g. get_compute_infrastructure, get_pue_benchmarks).

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 guideline: 'quote the issuing body with the figure' and 'always name the source.' A worked example call is given. However, it does not say when to reach for this tool over the related siblings (get_pue_benchmarks, get_compute_infrastructure, calculate_compute_energy_cost), so routing guidance is incomplete.

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, and destructiveHint. The description goes further, stating no exchange quotes, no trading recommendations, ELT feedstock prices deliberately unpublished, and every figure is a range. These are critical behavioral constraints that annotations cannot convey. No contradiction with 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?

Well-structured with Purpose, Guidelines, Limits, and Ex sections. Information is front-loaded, each sentence carries distinct value, and no filler exists. Length is justified by the complexity of the tool.

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?

Despite having an output schema (which covers return values), the description covers usage patterns, limitations, and examples. For a tool with optional parameters and multiple sections, this is complete and anticipates agent needs.

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%, but the description adds significant usage context: how to combine section and product, examples for each parameter, and clarifies that response_format='json' yields structured data for parsing. It enriches the schema without redundancy.

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 tool returns the rCB and virgin carbon black price benchmark structure, enumerating its components (anchor, band, feedstock, international, regional, grade, cost). It distinguishes itself from siblings by naming get_elt_price_index and get_rcb_index as complementary tools, so an agent can tell it apart.

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 states when to leave parameters empty for full set, how to narrow via section, and explicitly pairs with two sibling tools. Includes concrete usage examples. This is exemplary routing guidance.

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, and non-destructive behavior, so the description adds context beyond those: it discloses return constraints such as 'official anchors only', 'no raw quote tables', and 'trend direction and anchors only'. This clarifies what the agent will receive and what it will not, which is valuable for setting expectations.

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 description is well-organized with Purpose, Guidelines, Limits, and Ex labels, making it easy to scan. Every sentence contributes meaningful information without redundancy, and the most important purpose constraint is front-loaded. It is dense yet efficient.

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 simple two-optional-parameter read-only tool with an output schema and strong annotations, the description covers purpose, parameters, usage context, limitations, and a sibling alternative. No critical information appears missing for an agent to correctly select and invoke the 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?

The schema already covers both parameters at 100%, but the description adds practical value by enumerating segment values in English (domestic/export/import/feedstock/rCB), giving a concrete period example (2026), and emphasizing both are optional. The example 'rCB price trend 2026 CN' makes parameter usage more concrete than the schema alone.

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 tool's function: returning native carbon black / rCB price trend direction with official anchors, not raw quote tables. It also distinguishes itself from get_rcb_index by noting that tool provides numbers while this one provides direction. This gives an agent a precise picture of what the tool does and what it does not do.

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 explicitly guided: pass optional segment and period, use for directional questions like 'is rCB price rising', and pair with get_rcb_index for numeric values. It also states limits ('no absolute quotes'), making it clear when not to rely on this tool. The example query further anchors correct invocation.

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 the safety profile is covered. The description still adds meaningful non-obvious context: the values are published statistics or single-site cases and must not be averaged across differing scopes, which directly affects how an agent may legitimately interpret results.

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 labeled micro-sections (Purpose/Guidelines/Limits/Ex) make it scannable and front-loaded with the resource definition. Slightly formulaic labeling costs a little efficiency, but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description covers purpose, usage, and a key interpretation constraint. It is essentially complete for a read-only lookup tool, with only the absence of an explicit negative case keeping it from a 5.

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% with three documented parameters (keyword, language, response_format), so the schema already carries the semantics. The description adds only an example of a zero-argument call and no extra meaning about filtering, language selection, or output format, so the baseline 3 is appropriate.

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 Purpose line names a specific resource and scope: PUE benchmarks and green-rating figures for compute facilities. That is far more precise than the tool name alone, though the sibling differentiation is only implicit (the closest relative, calculate_compute_energy_cost, appears under Guidelines rather than being contrasted in the Purpose statement).

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 states when to use it ('efficiency questions'), names a companion tool to pair with and the condition for pairing ('when a load figure is available'), and adds a scope caveat ('do not average across differing scopes'). Missing an explicit statement of when this tool is the wrong choice, so it falls short of a full 5.

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 known. The description adds valuable behavioral context beyond this: it states the reference range is computed via the anchor method and is not a transaction price, and that the VF factor is forward-only (no backfill before 2026-Q3). This gives the agent important caveats about the data's nature and temporal limitations, which is beyond what annotations provide.

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 description is well-structured with clear sections (Purpose, Guidelines, Limits, Example). It is front-loaded with the core purpose, then provides actionable guidance, limitations, and a concrete example. Every sentence earns its place—there is no fluff or repetition. The example usage ('rCB index P2 CN 2026-09', 'current rCB reference price EU') is practical and demonstrates natural language invocation.

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?

The description is highly complete given the tool's complexity. It covers the anchor method, parameter semantics, defaults, limitations, and even provides examples. Since an output schema exists, the description does not need to detail return values. It explains key caveats (non-transaction price, forward-only VF) that affect interpretation. The only minor gap is lack of explicit handling for invalid inputs or edge cases, but this is acceptable given the output schema and the thorough parameter guidance.

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 each parameter has a description in the schema. However, the tool description adds meaning beyond the schema: it explains the grade levels (P1 refined / P2 standard / P3 industrial) which are not defined in the enum descriptions, and clarifies the date format and default behavior (blank = latest) and region defaults. This enriches the agent's understanding of parameter choices.

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 tool's purpose: a query that returns the rCB price index (ABP), absolute reference price (ARP), and AF/VF decomposition for a given grade, period, and region. It specifies the anchor method (N550) and distinguishes itself from other price tools by naming exactly what it returns. The verb 'query' and resource 'rCB price index' are precise, and the mention of the anchor method helps differentiate it from other index tools like get_elt_price_index.

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 provides explicit guidelines: how to pass each parameter (grade with defaults, date format and blank behavior, region with defaults), and it explicitly recommends pairing with get_rcb_vcb_spread for discount and get_grade_trend for history. It also discloses limitations (reference range is not a transaction price; VF is forward-only). This is comprehensive, telling the agent exactly when and how to use this tool and when to use alternatives.

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 covered. The description adds valuable behavioral context beyond that: the N550-anchored reference range, the single-period snapshot behavior (no forecast), and the caveat that output is not a transaction price. These interpretive constraints help the agent use the result correctly.

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 labeled sections (Purpose, Guidelines, Limits, Ex) make the description highly scannable. Purpose is front-loaded, each sentence earns its place, and the example is the minimal illustration needed. No filler or redundancy with the schema's structured fields.

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 an output schema present, annotations covering the safety profile, and full parameter documentation, the description covers the remaining essential context: anchoring basis, temporal scope, exclusion limits, and a usage example. The only gap is that it doesn't explicitly differentiate from semantically-similar siblings (get_rcb_index, compare_rcb, get_substitution_boundary), leaving that to inference.

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. The description's parameter list ('date (YYYY-MM), region (CN/EU/NA/SEA), grade (P1/P2/P3)') largely restates the schema, but the concrete example 'rCB vs N550 discount CN 2026-09' adds value by demonstrating how a natural-language request maps to the actual parameters, which nudges this to a 4.

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-resource pair ('anchored spread between rCB and native carbon black') and defines the deliverable precisely: anchoring ratio rho, discount rate, and price gap per grade/region/period. It positions itself as the quantitative 'how much cheaper is rCB' indicator, which clearly distinguishes it from sibling tools like get_grade_trend (direction) and calculate_saving (custom quotes).

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 Guidelines section explicitly names complementary tools and their conditions: 'pair with get_grade_trend for direction and calculate_saving for custom quotes.' The Limits section adds exclusion guidance ('not transaction price', 'no forecast'), telling the agent when this tool is inappropriate. It stops short of 5 because it doesn't explicitly route the agent away from closely-related siblings like get_rcb_index or compare_rcb.

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 openWorldHint=false, so the safety profile is covered. The description adds genuine scope context beyond that: the data is split by material and statutory stage and contains thresholds only, with no applicability interpretation — a real boundary on what the caller receives.

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 labeled Purpose/Guidelines/Limits/Ex sections and no filler, so the routing information lands first. Slightly formulaic and the 'Ex:' call with no arguments adds little, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and annotations covering safety, the description only needs to establish scope and routing — which it does fully. Material coverage, stage split, and limits on interpretation are all stated, leaving no gap an agent would need to guess at.

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% and all three parameters (keyword, language, response_format) are documented in the schema, including enums and defaults. The description adds no parameter-level detail (e.g. which material strings are valid), so the 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 resource (recycled-content minimums) with enumerated materials (cobalt, lead, lithium, nickel) and the scope split (two statutory stages). An agent can distinguish this domain-result tool from sibling calculators like calculate_recycled_content_gap without opening the 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 when to use it ('threshold questions'), names the alternative and pairing pattern ('pair with calculate_recycled_content_gap to compare against an actual figure'), and states an exclusion ('no interpretation of how they apply to a specific battery'). When, when-not, and the sibling relationship are all covered.

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 the safety profile is fully covered by structured data. The description's contribution is the scope limit (status/dates only, no performance figures), which is real added value but fairly thin; nothing about coverage breadth, freshness, or which releases are included.

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 labeled segments (Purpose / Guidelines / Limits / Ex.) cover everything in roughly forty words with zero filler, and the purpose is front-loaded ahead of usage and limits.

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 an output schema present, return values need not be described, and all three optional parameters are covered by the schema. Purpose, usage trigger and scope limit are all stated, leaving only sibling-level disambiguation unaddressed for a zero-required-parameter read 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 100%, so keyword, language and response_format are already documented in the schema, including the enum semantics. The description adds nothing parameter-specific and its example call ('get_standards_roadmap()') shows only the no-argument form, which is the correct baseline 3.

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 resource (the 3GPP / ITU-R standards roadmap) and enumerates its contents: 3GPP releases, IMT-2030 framework milestones, and the 6G timetable. It is clearly distinguishable by content, though it never names an alternative sibling such as get_telecom_policy_timeline or get_announcements_timeline, which are the plausible confusions.

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?

'use for standard-version and timeline questions' gives a clear triggering condition, and 'Limits: status and dates only - performance figures live in the standards themselves' defines when the tool will not satisfy a need. It stops short of naming which sibling to use for the out-of-scope performance data, so the routing guidance is incomplete.

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, and no destructive behavior, so the description does not need to restate those. It adds behavioral scope beyond annotations: the tool covers technical/regulatory possibility only, not commercial viability, and omitting dimension returns all four dimensions. This provides meaningful context without contradicting 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?

The description is compact and front-loaded with labeled sections: Purpose, Guidelines, Limits, and Examples. Every sentence earns its place, with no filler or repetition of schema content. The structure makes it easy to scan and act on quickly.

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 single optional parameter with strong annotations and an output schema, the description is complete. It covers what the tool does, how to invoke it, what scenarios it applies to, what it excludes, and where to route non-matching needs like pricing.

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 schema only marks dimension as optional and gives high-level Chinese labels. The description adds exact accepted values in English, the default behavior when omitted, and natural-language query examples like 'rCB application limit in seals'. This materially enriches the bare schema for an AI agent.

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 explicitly states the tool returns the four-dimension substitution boundary of rCB vs native carbon black and enumerates the dimensions: application limits, regulatory access, certification requirements, material spec constraints. It is specific about the resource and scope, and the Limits section differentiates it from calculate_saving on commercial viability, so it is clearly not a tautology.

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 usage condition: 'call before any substitution feasibility claim' with a concrete example question. It also states an exclusion — not commercial viability — and routes pricing to calculate_saving, giving an agent clear guidance on when not to use 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 cover readOnly/idempotent/non-destructive/closed-world, so the safety profile is known. The description adds genuinely new behavioral context beyond that: output is metadata + source link only (not full copyright text) and currency must be verified on the official platform before compliance use. This is useful scope/limitation disclosure.

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?

Dense but labeled with Purpose/Guidelines/Limits/Ex so it is front-loaded and scannable. The acronym list and examples slightly pad length, but essentially every clause carries information; minor trimming only.

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 an output schema present, return-value explanation is not required, and the description appropriately focuses on scope, lookup keys, and limitations. Combined with annotations and full schema coverage, an agent has what it needs to call this correctly; only explicit sibling routing is absent.

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% with enum defaults documented, so the baseline is 3. The description adds practical value by giving concrete ID format ('rcb-tech-001') and keyword examples ('D8178', 'GB/T 40009') that illustrate the id/name trade-off the anyOf expresses only structurally.

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 ('fetch one ... technical standard or process'), the resource domain (ASTM D36 series, GB/T, HG/T, pyrolysis, sCB), and the two lookup keys (entity ID or keyword). The word 'one' implicitly contrasts with the sibling query_techs list tool, but no sibling is named explicitly, 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?

Gives a concrete trigger: 'use when an Agent needs the governing standard behind a parameter or certification claim', plus worked examples ('ASTM D8178 scope'). It does not explicitly name alternative tools (get_carbon_standards, query_techs, get_grade_spec) or when-not-to-use, so it stops short of a 5.

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 behavior, so the safety profile is covered. The description earns credit for adding substantive caveats not in the annotations: the dataset is China-scoped, roadmap dates are aspirational rather than achieved, and the tool is keyed to 'policy-sequence' content.

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/Guidelines/Limits/Ex template is front-loaded, terse, and scannable, with no wasted prose. The trailing 'Ex: get_telecom_policy_timeline()' is a no-argument call that conveys almost nothing and is the only dead weight.

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 an output schema present and annotations covering the safety profile, the description only needs to cover scope and usage, which it does. The remaining gap is sibling differentiation among the numerous other timeline and policy tools, which a one-line routing note would 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 description coverage is 100% with all three parameters (keyword, language, response_format) documented and two enums constrained, so the schema carries the parameter burden. The description adds nothing about keyword matching semantics (e.g., Chinese vs English matching, filtering scope) or output-format tradeoffs, so the 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 names a specific verb+resource ('telecom and satellite-internet policy timeline') and enriches it beyond the tool name by calling out China's 6G roadmap milestones and satellite-internet policy documents. This distinguishes it from the battery/CBAM/announcement timeline siblings, though it never names those alternatives 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?

'use for policy-sequence questions' gives clear situational context, and the Limits line ('China focus; roadmap dates are planned, not achieved') sets a real boundary condition. It stops short of routing the agent between this tool and the many other timeline/policy siblings (get_battery_regulation_timeline, get_cbam_timeline, query_policies), so no exclusions or alternatives are stated.

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, so the safety profile is covered. The description adds context about what the tool documents (customs-reported vs derived fields) and its data boundary (no commercial quote platform data), which is useful beyond the annotations. It doesn't describe output structure, but an output schema exists.

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 description is well-structured with Purpose, Guidelines, Limits, and Ex sections. Every sentence earns its place: it explains what the tool does, when to use it, what it excludes, and gives an example. No redundancy with the schema or annotations.

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 documentation tool with one optional parameter, an output schema, and strong annotations, the description is complete. It tells the agent why to call it, what it will learn, and what the tool will not return. Nothing needed for 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 description coverage is 100%, so the schema fully documents the single response_format parameter. The description's example shows usage with response_format='json', which adds a small usage hint, but the baseline of 3 is appropriate since the schema already carries the parameter meaning.

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 purpose: describe the trade flow dataset's source, caliber, unit conversion, derived-field declarations, field table, and compliance boundaries. It clearly distinguishes this tool from siblings like get_trade_flow_summary or query_trade_flows by noting it returns no trade records 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?

Explicitly instructs to call this before running any trade query that will be quoted, and states what it documents. It also names a limit (UN Comtrade official statistics only) and clarifies it returns no trade records, which helps an agent avoid using it as a data source.

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?

The description goes well beyond annotations by specifying the weighted-unit-price formula, exclusion of World aggregate rows from partner rankings, customs-reporting limitation, and comparability caveats. These are behavioral traits the readOnly/idempotent annotations do not communicate.

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 description is organized into Purpose/Guidelines/Limits/Ex with no filler. Each sentence contributes either an aggregation behavior, usage constraint, or caveat, and the most important scoping rule appears early.

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?

Given only 2 optional parameters, an output schema, and read-only/idempotent annotations, the description supplies all essential selection and invocation context: output contents, period handling, formula, pairing guidance, and data caveats. Nothing needed to call the tool safely 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 both parameters are already documented. The description reinforces period semantics and gives an example call, but the added meaning over the schema is marginal; baseline 3 is appropriate.

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?

Purpose states a specific verb ('aggregate'), a concrete data source (UN Comtrade carbon black HS 280300 records), and exact outputs (per-reporter totals, weighted unit price, top-10 partners). It also references get_trade_partner_ranking, making its niche distinct from the sibling ranking 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?

Guidelines explicitly tell the agent how to parameterize the call (pass YYYY or leave empty) and to pair it with get_trade_partner_ranking for single-reporter drill-down. It does not explicitly enumerate when to avoid this tool or compare to query_trade_flows, but the guidance is concrete enough for correct invocation.

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, and destructiveHint, and the description adds meaningful behavioral detail: World aggregate rows are excluded, shares are computed only within the returned set, and only one reporter-period-flow combination is allowed per call. This goes well beyond the structured 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?

The description is compact and well-organized into Purpose, Guidelines, Limits, and Ex sections. Every sentence adds information, and the most important scoping details appear first.

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 an output schema present and annotations covering safety, the description is nearly complete: it gives purpose, required parameters, limitations, share semantics, and concrete examples. The only gap is the inconsistent requiredness of flow between the description and the input schema, which could mislead an agent during 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 coverage is 100%, so the baseline is 3; the description adds useful nuance for flow values, top_n default/max, and usage examples. However, it states that flow is required while the schema's required array only lists reporter and period, creating a conflicting signal that prevents a 5.

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?

Description opens with 'Purpose: rank partner countries for one reporter, period and flow direction by quantity' and lists the exact return fields ('rank, partner, quantity, value, unit price and share'). This is a specific verb+resource that clearly differentiates the tool from siblings like get_trade_flow_summary and query_trade_flows.

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 states required inputs (reporter, period, flow), when to raise top_n ('only when a longer tail is needed'), and the one-call-per-combination limit. It lacks explicit alternatives or when-not-to-use guidance, so it stops short of a 5, but the context is clear.

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, openWorldHint=false and destructiveHint=false, so safety is covered; the description still adds real behavioral context the annotations cannot carry, notably the A-grade-only scope, the caveat that absence does not imply untrustworthiness, the 100-row ceiling, and the disclaimer that no ranking or endorsement is implied. That is a meaningful addition beyond structured fields.

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/Guidelines/Limits/Examples structure is front-loaded and scannable, with the key routing instruction early. It is somewhat dense and the examples partially restate the parameter advice already given in Guidelines, but no sentence is purely 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?

An output schema exists, so return values need not be enumerated; nonetheless the description previews the record shape (who vouches, source, confidence grade, traceability), and it covers scope limits, sibling routing, and parameter presets. 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%, so the baseline is 3 and the schema already documents limit, language and response_format with enums and defaults. The description goes beyond restating them by advising 'use language={"en"} plus response_format={"json"} for downstream automation' and confirming the 100-row cap matches the schema maximum, which is practical guidance an agent can act on.

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 precise verb and resource with the defining filter baked in: 'return every company/project carrying verified=true (A-grade confidence, backed by government filings or official announcements)'. This cleanly separates it from query_companies and get_company in the sibling list, so an agent can route without inspecting 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?

It gives an explicit when-to-use ('call this first for any recommendation, shortlisting or transaction-style task') and names the follow-up alternative with its condition ('pair with get_company for full detail on the chosen entity'). It also prescribes the parameter combination for automation workflows, 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 (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuine extra context: it is reference-only material, the children's figure is a daily average, and WHO sets no quantified sedentary-behaviour threshold — data nuances the annotations cannot convey.

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?

Labelled Purpose/Guidelines/Limits structure is front-loaded and scannable, with no filler prose. The trailing 'Ex: query_activity_guidelines()' adds little since the tool takes no required arguments, but it is brief.

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 need not be described, and annotations cover the safety profile. Combined with the population-group scope and the reference-only caveat, an agent has what it needs to select and call this correctly.

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% with five self-documented parameters (limit, offset, keyword, language, response_format), so the schema carries the burden. The description adds nothing about paging, filtering, or language/format selection, 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?

States a specific resource (physical activity guidelines) and enumerates the population groups covered (adults, children, older adults, pregnancy). It is clearly distinguishable from adjacent health siblings such as get_dietary_guidelines and query_health_myths, though it never names or contrasts them 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?

The 'Guidelines: use for activity-volume questions' line gives explicit usage context, and the 'Limits' line rules out individual/personalized advice. It stops short of naming an alternative tool or when NOT to call it beyond the advice boundary.

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 this as a safe, idempotent, closed read. The description adds genuinely useful disclosure beyond them: the corpus is Chinese-language source material, coverage is only 63 articles from 2026-04 onward (not the account's full history), and 'A-grade' is clarified as first-hand rather than peer-reviewed. It does not discuss pagination mechanics directly, keeping it just below 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 Purpose/Guidelines/Limits/Ex labeling front-loads the key facts and makes scanning easy. It is somewhat long, but each section carries distinct information, so almost every 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 an output schema present and 100% schema description coverage, the description need not explain return values, yet it usefully summarizes the item payload (publish date, topic, source URL, AI summary). For a 7-parameter search tool, nothing an agent needs to call 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 coverage is 100%, so the baseline is 3. The description still adds value: it explains which fields keyword matches, clarifies that category is for a single theme, and supplies three concrete invocation examples including a category and language value that exceed 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 (search) and resource (the RCB industry WeChat account's first-hand research archive), then enumerates the content scope: conference coverage, process cases, application boundaries, market forecasts. This clearly differentiates it from the sibling get_article, which retrieves a single item.

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 actionable usage rules: keyword matches title/topic/author/scope, and category filters to a single theme. It does not explicitly route the agent away from get_article or state when-not-to-use, so it falls short of a 5, but the search/filter context is clear.

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, so the safety profile is covered. The description adds a genuine scope constraint — only published targets, no industry performance data — which helps an agent avoid misinterpreting coverage. It doesn't discuss pagination or result shape, though the schema/output schema carry that.

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?

Labeled sections (Purpose/Guidelines/Limits/Ex) make it scannable and front-loaded with the resource description. Slightly template-like and the trailing no-arg example call is low value, but nothing is padded excessively.

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 full schema coverage, an output schema, and clear purpose/limits, an agent has what it needs to invoke this correctly. The only minor gap is that return/pagination behavior is left entirely to the output schema and offset description rather than being summarized in the tool description.

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 all five parameters (limit, offset, keyword, language, response_format) are documented in the schema, including enums and defaults. The description adds no parameter-level detail beyond what structured fields already provide, so the baseline of 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 resource (battery recycling targets) and enumerates the exact contents: recycling efficiency, material recovery rates, collection rates, plus effective years. It also distinguishes itself from the timeline siblings via the 'rather than dates' clause, so an agent can route correctly without opening 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?

Explicitly says when to use it ('target/efficiency questions rather than dates') and states a boundary ('published targets only, no industry performance data'). It does not name the specific alternative tool (e.g. get_battery_regulation_timeline) by name, but the routing condition is clear.

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 fully cover the safety profile (readOnly, idempotent, destructive=false, openWorld=false), so the bar is lower; the description nonetheless adds real behavioral context the annotations do not convey: excluded cards are filtered at export and never returned, and each card is a single fact with no recommendation. It does not cover pagination/return-shape behavior, but the output schema handles that.

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/Guidelines/Limits/Ex/Scope labels and every section carries information; no filler sentences. It runs slightly long, and the starred Scope paragraph does a lot of work that could be tightened, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a full output schema and complete annotations, the description only needs to add selection and content semantics, which it does (filtering rules, card granularity, when to prefer query_domain_benchmarks). The only shortfall is the enum-inconsistent example value, which leaves a small ambiguity about accepted type inputs.

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% (including offset/next_cursor and response_format), so baseline is 3. The description adds useful matching semantics (keyword scans title and fact fields; combine type and region) and worked examples, but the example query_cards(type='标准解读') uses a value that is not in the type enum (statistic/standard/paper/announcement/industry_association), which risks misleading the agent.

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 ('search the public knowledge-card collection') and immediately qualifies what a card is (atomic sourced facts compiled from statistics, standards, papers, announcements). The Scope note explicitly differentiates it from the sibling query_domain_benchmarks, so an agent can choose between them 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 concrete when-to-use rules (keyword matches title/fact fields; combine type and region to narrow), explicit exclusions (legacy rCB-centric layer, small curated set), and names the preferred alternative for multi-domain facts with the reason (current, larger benchmark layer). Nothing 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.