Trustbase Lab · Trusted Data Infrastructure for the AI Era

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?

The description discloses behavioral details beyond the annotations, including the classification into pass / light deviation / significant deviation and the dependency on measured values. It also clarifies that thresholds follow the site's own anchored-benchmark methodology, not customer specifications, which is important for correct interpretation of 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 description is well-structured with labeled Purpose, Guidelines, Limits, and Example segments, making it highly scannable and front-loaded. Each sentence contributes meaningful operational guidance, and the example clarifies usage without unnecessary verbosity.

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 fully covers the tool's purpose, input requirements, methodology, limitations, and a usage example. Combined with complete schema descriptions and an output schema, there is sufficient information for an agent to select and correctly 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds semantic value by giving concrete examples for rcb_params such as iodine_absorption, OAN, and ash. It also grounds target_grade with the N550 example, providing context beyond the schema's short 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 explicitly states the tool's purpose: compare measured rCB sample parameters against a target native carbon black grade spec range and classify each parameter as pass, light deviation, or significant deviation. It is clearly differentiated from sibling get_* tools that only retrieve grade or spec data without performing a benchmark comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: ideal for grading incoming rCB lots against a native anchor before substitution decisions, and it specifies required inputs including target_grade and rcb_params. It also gives limits such as needing measured values and following the site's anchored-benchmark methodology rather than customer specs, but it does not explicitly name alternative sibling tools for cases where different input or methodology is needed.

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 declare readOnly, idempotent, non-destructive, and the description adds non-obvious behaviors: one record per call, gated field withholding, and first-match-only name lookup. No contradiction with annotations; it could have added auth requirements, but the safety profile is already carried.

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 uses labeled sections (Purpose, Guidelines, Limits, Ex) and front-loads the core function before constraints. Every sentence is actionable; examples at the end reinforce the parameter combinations.

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-record read tool, the description covers purpose, id source, lookup behavior, output options, limits, and examples. Annotations and output schema cover safety and return structure, leaving no important gap for correct 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 baseline is 3; the description adds id formats, the id/name either-or relationship, fuzzy lookup semantics, and when to use language and response_format. It adds value beyond the schema without needing to restate 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 opens with a specific verb and resource: 'fetch one company or project record ... by entity id or name', listing the detail fields that will be returned. This clearly distinguishes get_company from sibling query tools by emphasizing single-record retrieval by id/name.

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 concrete guidance: ids come from query_companies, use name for fuzzy lookup when id is unknown, and set language and response_format for specific needs. It also states exclusions: no batch mode, gated fields may be withheld, and name lookup returns only the first match.

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 real context beyond that: 'metadata only - no record content' and 'counts refresh with each data release (schema 1.9),' which tells the agent the data is non-content and time-versioned.

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 the agent can scan to what it needs. It is dense and listy, but nearly every clause earns its place; the only mild redundancy is restating parameter behavior already in the schema.

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

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

An output schema exists, so return-value detail is unnecessary and correctly omitted. Purpose, discovery guidance, and limits are all present; the definition is complete for a zero-required-parameter discovery tool, with only the sibling-overview distinction left implicit.

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 two enum parameters already fully documented, so the baseline is 3. The description reframes them as usage advice ('pass language=en for English output, response_format=json for Agent processing') but adds no syntax or default information the schema does not already contain.

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?

Gives a specific verb+resource ('dataset overview') and enumerates exactly what it returns: version, record counts per table, entity-ID rules, confidence grading, verified-supplier counts, tool index, module map. It is clearly the server-wide entry point rather than a domain tool, though it never explicitly distinguishes itself from sibling overview tools like get_feedstock_overview or get_trade_dataset_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?

States a clear directive: 'call this FIRST when discovering the server, then route to specific query_* tools,' which tells the agent both when to use it and what to do next. It stops short of naming the other *_overview siblings as alternatives, so the routing guidance covers only the query_* family.

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=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: ranges are compiled from public specifications and not a guaranteed certificate of analysis, and the gap analysis is relative to N550 only. These are non-obvious limits that prevent misinterpretation of 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 description is well-organized with clear labels (Purpose, Guidelines, Limits, Ex) and immediately front-loads the purpose. Every sentence earns its place—no filler—and the examples are concise and instructive.

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 moderate complexity (multiple return fields, gap analysis), the description covers what is fetched, how to identify the grade, edge cases (N550-only comparison), and usage limits. An output schema exists, so return-value details need not be repeated. The definition is complete enough for correct 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 meaning by showing concrete example values for id and name ('rcb-grade-n550', 'Super P') and clarifying the mutual-exclusivity via usage examples. However, it doesn't substantially expand beyond what the schema already documents for language or response_format.

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 ('fetch one carbon black grade in full') and enumerates exactly what is returned: six ASTM parameters as min/max ranges, test-method standards, application list, process route, brand owner, and gap analysis for rCB types. This level of detail clearly distinguishes it from siblings like get_grade_spec and query_grades.

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 pairs this tool with query_grades to discover ids and with get_grade_spec for specification detail, signaling when to use each alternative. It also provides a Limits section clarifying one grade per call and the data provenance caveat, so an agent can decide confidently.

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. The description adds valuable behavioral context beyond that: it specifies that output is limited to spec ranges, not lot-specific data, and provides example queries. This enriches the agent's understanding of the tool's behavior without contradicting 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 structured with Purpose, Guidelines, Limits, and Examples, making it easy to parse. It is slightly verbose but every section adds value; the front-loaded purpose is strong. Could be tightened, but it's well-organized.

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 that an output schema exists, the description does not need to explain return format. It covers what the tool does, when to use it, what it does not cover, and provides examples. Nothing essential is missing for an agent to select and 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 baseline is 3. The description adds meaning by explaining that 'grade' is the primary input (with examples like n330, n550) and 'type' is optional, and provides query examples that demonstrate parameter combinations. This goes beyond the schema's simple descriptions, warranting 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 clearly states the tool's purpose: retrieving ASTM spec parameter ranges (min/max/unit/test method) for carbon black grades. It distinguishes itself from siblings by positioning as the 'standard-parameters reference' and explicitly contrasts with 'lot-specific CoA data', making its scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage instructions: 'pass grade (e.g. n330, n550) plus optional type' and states when to use ('use to judge whether an rCB sample falls in spec'). It also defines limits ('spec ranges only - not lot-specific CoA data'), effectively telling the agent when NOT to use it, which is exactly what this dimension asks for.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it returns exactly one record, accepts either id or name keyword, and explicitly disclaims legal opinion and applicability assessment. It doesn't describe pagination or error behavior, but for a single-record read tool with strong annotations, this is solid.

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, Ex) and every sentence earns its place. It front-loads the purpose, then gives actionable usage guidance, then limits, then examples. No fluff or repetition of schema 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?

For a single-record read tool with an output schema present, the description covers everything an agent needs: what the tool returns, how to identify the record, when to use the sibling search tool, and what the tool does not do. The output schema handles return-value details, and annotations handle safety. No critical gaps.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds value by explaining the id/name mutual exclusivity ('与 id 二选一' is in schema, but description reinforces it), giving concrete example values (rcb-pol-001, CBAM, 2023/956), and clarifying that response_format='json' is for agent pipelines. This goes beyond the schema's terse 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 regulation record in full') and enumerates the exact fields returned (issuing body, policy type, scope, impact, compliance deadline, source link, AI-readable summary). It clearly distinguishes from siblings like query_policies (search) and get_announcements_timeline (timeline) by focusing on a single regulation record.

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 to run query_policies first when the id is unknown, and provides concrete examples for both id and name/identifier keyword usage. It also states limits (one record per call, no legal opinion, no applicability assessment), which helps the agent decide 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 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 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, 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 mark the tool as read-only and idempotent, and the description adds meaningful behavioral limits: it returns metadata and source link only, not full standard text due to copyright, and warns to verify currency before compliance use. This contextualizes expectations beyond the structured annotation 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 description uses labeled sections (Purpose, Guidelines, Limits, Ex) with the core purpose front-loaded. Every sentence carries practical information, and the examples are compact yet illustrative.

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 lookup tool with a rich input schema, existing output schema, and strong annotations, the description fully covers purpose, parameter selection, limitations, and usage context. An agent has everything needed to decide whether to call it and how to 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?

The schema already covers all four parameters in detail, establishing a baseline of 3. The description adds value by giving concrete id format ('rcb-tech-001'), keyword examples ('D8178', 'pyrolysis', 'GB/T 40009'), and clarifying the id-or-name relationship, which helps agents pick the right 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?

Description opens with a specific verb and resource: 'fetch one rCB technical standard or process by entity ID or keyword'. It enumerates the covered standard families and the returned content (scope, core indicators, status, source link), making the tool's job unmistakable and distinct from sibling getters.

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 use the tool: 'when an Agent needs the governing standard behind a parameter or certification claim' and gives concrete parameter guidance with examples. It does not mention when not to use it or name query_techs as an alternative, so it falls just short of full 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 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=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds critical domain context: absence from the list does not imply untrustworthiness, and the data includes a confidence rating (A-grade) backed by specific sources. It also explicitly disclaims any commercial rating or endorsement, which prevents misinterpretation. It does not detail return format beyond the schema, but with an output schema present, that is not required. This goes beyond annotations to add meaningful nuance.

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 structured into labeled sections (Purpose, Guidelines, Limits, Ex), which aids scanning. It is dense but every sentence serves a purpose: defining the scope, providing usage direction, clarifying limitations, and showing examples. It is longer than typical but justified by the complexity of the trust concept. Minor deduction for length; it could be trimmed slightly without losing value.

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 simplicity of the parameters (all optional, well-documented in schema) and the presence of an output schema (not shown but implied), the description fully covers what an agent needs to know: what the tool returns, how to filter, how to interpret results (trust layer), and how to integrate with get_company. No critical information is missing; the limitations are clearly stated (max 100 rows, no endorsement). The tool is complete for its purpose.

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 input schema has 100% description coverage, so the baseline is 3. The description adds value by recommending language='en' and response_format='json' for downstream automation, and by mentioning the limit parameter in the example. This exceeds the schema by providing usage context for parameters, hence 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 ('return'), a specific resource ('every company/project carrying verified=true'), and the precise filtering criterion (A-grade confidence backed by government filings or official announcements). It is distinct from sibling tools like get_company (which retrieves full detail) and query_companies (which likely performs general search), and it explicitly positions itself as the 'trust layer' for shortlisting. The purpose is unambiguous and well differentiated.

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 guidance: 'call this first for any recommendation, shortlisting or transaction-style task.' It also names the alternative (get_company) and explains when to use it ('for full detail on the chosen entity'). It even gives parameter recommendations (language='en', response_format='json' for automation). This is textbook-level usage guidance, covering when and when-not, which is rare and highly valuable.

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?

With annotations already declaring readOnly, idempotent, and non-destructive behavior, the description adds valuable context: the archive is first-hand only, carries publish date/topic/source URL/summary, is Chinese-language, and is not the account's full history. The clarification of 'A-grade' and the coverage window give an agent accurate expectations not inferable from annotations alone.

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 no redundant filler. It front-loads the core purpose, keeps each section to one or two sentences, and the examples are compact and directly actionable.

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 6-parameter tool with an output schema present, the description is complete: it covers the resource, the matching semantics, category filtering, language, data coverage limits, and gives runnable examples. The output schema handles return values, so nothing essential is missing for an agent to invoke the 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 coverage is 100%, so baseline is 3. The description adds meaning by explaining that keyword matches title/topic/author/scope and category filters to a single theme, and it provides three concrete example calls that clarify how keyword, category, and language parameters combine. This lifts it above 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?

The description clearly states a specific verb ('search') and a specific resource ('first-hand research archive of the RCB industry WeChat official account'), with content detail (conference coverage, process cases, application boundaries, market forecasts). However, it does not explicitly distinguish itself from sibling tools like get_article or other query_* tools, so it stops short of full sibling differentiation.

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 explains how keyword and category filtering work, and the Limits section clearly gives exclusions: Chinese-only source material, limited coverage of 63 articles from 2026-04 onward, and A-grade not meaning peer-reviewed. It does not name alternative tools or exactly when to prefer them, though the limits implicitly say when this tool is not suitable.

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

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

Beyond the read-only/idempotent annotations, the description discloses useful behavior: only publicly releasable cards are ever returned, each result includes a fact summary with its source, and cards contain a single fact rather than analysis or recommendations. No statement contradicts 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 well-structured with labeled sections: Purpose, Guidelines, Limits, and Ex. It front-loads the core purpose, and every sentence carries useful information without padding.

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 fully covers scope, matching behavior, result contents, exclusions, and usage examples. An output schema exists, so detailed return-value documentation isn't required here; nothing essential is missing for an agent to invoke query_cards 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 all four parameters are already documented. The description adds usage nuance (combine type and region to narrow, keyword matches title and fact fields) and examples, but those largely restate schema meaning rather than adding new parameter semantics.

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 clear verb ('search') and resource ('public knowledge-card collection'), then defines the collection as atomic sourced facts compiled from statistics, standards, papers, and official announcements. This makes the tool's scope immediately distinguishable from sibling query tools for articles, companies, policies, and 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?

A dedicated 'Guidelines' section explains how keyword matching works and advises combining type and region to narrow results, followed by concrete examples. It doesn't explicitly state when to prefer this over siblings, but the context is clear enough that an agent can apply it correctly.

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/idempotent/non-destructive, so the safety profile is covered. The description adds real context beyond that: the 130-record scope, the A/B/C confidence caveat, and the important limitation that capacity is a record attribute rather than a separate projects table.

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. labels and no filler, though it is dense enough to require careful reading. Each section contributes, but the examples and limit note add length beyond what a minimal call needs.

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

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

An output schema exists, so return-value explanation is unnecessary. For an 11-param, zero-required discovery tool the description covers intent, filtering strategy, delegation target, and data caveats; only minor gaps (e.g. pagination/limit interaction) remain.

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 11 parameters with enum labels and defaults. The description reinforces segment/status/location filtering but adds little syntax or semantic detail the schema does not already contain, 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 verb and resource ('query the global rCB company and project database'), gives scope (130 records, three segments) and filter dimensions, and positions itself as 'the discovery tool' versus get_company for entity detail. An agent can distinguish it from siblings like get_company or get_verified_suppliers 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?

Gives explicit combination guidance ('combine segment + status + location'), a workflow for capacity-project lists, and names the follow-up tool (get_company). It also names a concrete alternative for full entity detail, so the when-to-use and when-to-delegate boundaries are 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, and non-destructive behavior. The description adds useful behavioral boundaries: exactly 37 records, spec ranges rather than lot CoA, rCB vs-N550 gap analysis, and the ash-gap limitation on rCB reinforcement. This materially prevents agents from misinterpreting the data as lot-specific or broader than it is.

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 dense but organized into Purpose/Guidelines/Limits/Ex segments and front-loads the resource. A few semicolon-packed clauses reduce readability, but every sentence contributes domain-relevant constraints or usage guidance.

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

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

For a 7-parameter, all-optional search tool with a complete schema, annotations, and an output schema, the description covers library composition, dataset limits, filter-combination guidance, and example queries. Nothing essential for selecting or invoking the tool appears to be 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%, with each parameter already explained. The description adds value by showing how to combine type, category, and keyword, and by giving example query intents. It doesn't deeply explain parameter formats, but that's unnecessary given the schema's completeness.

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: 'search the carbon black grade benchmark library' with explicit scopes (ASTM D1765 native grades, conductive benchmarks, rCB types). The word 'search' plus the enumerated contents distinguishes it clearly from sibling tools like get_grade or get_grade_spec.

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 an explicit Guidelines section telling agents to combine type/category/keyword and to use this tool 'as the anchoring benchmark layer before any rCB vs native comparison'. It also gives concrete example queries, but it does not name sibling tools to use instead under specific circumstances, so it lacks explicit when-not/alternative 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?

Beyond the readOnlyHint/idempotentHint annotations, the description discloses important behaviors: each hit carries 'issuing body, policy type, scope, rCB impact, compliance deadline and source link,' and B/C-grade entries are 'excluded only when verified=true is set.' It also states output language and response format options, adding value 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 well-structured with Purpose/Guidelines/Limits/Ex sections and front-loads the primary purpose. Each section adds relevant information, though the three example calls in the Ex section are somewhat redundant with the Guidelines and could be trimmed slightly.

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 8 parameters, no required fields, an output schema, and the complexity of a multi-jurisdiction policy search, the description is remarkably complete. It covers what results contain, the verified filtering behavior, language and format choices, permissible use cases, and concrete invocation examples, leaving no major gap for an agent to 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%, so the schema already documents each parameter. The description adds meaningful usage semantics by advising to combine keyword with region and category, explaining the verified flag's effect on B/C-grade entries, and providing concrete examples like query_policies(keyword='CBAM') that clarify 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 clearly states a specific verb and resource: 'search the global rCB regulation library' and enumerates the covered frameworks (EU CBAM/EUDR/ESPR, China MIIT, India/Korea EPR, etc.). This distinguishes it from sibling tools like get_policy or get_article by emphasizing a library-wide search over specific documents.

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 guidance: 'combine keyword with region and category' and 'set verified=true when the answer must rest on government documents.' It also provides usage limits, such as 'policy documents only - no legal advice and no ruling on how a rule applies to a specific company or shipment,' though it does not explicitly contrast with sibling tools like get_policy.

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 meaningful behavioral context beyond annotations: it discloses that full standard text is never reproduced, that C-grade entries are unverified leads, and that the category taxonomy is the tool's own rather than the issuing body's. These are important caveats an agent needs to interpret results 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 description is organized into labeled sections (Purpose, Guidelines, Limits, Ex) and front-loads the core purpose before details. It is somewhat long but every section earns its place: the standard list is specific, the limits are critical caveats, and the examples are actionable. Slight redundancy exists between 'verified=true' in Guidelines and the confidence parameter description in the schema, but overall it is well-structured.

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 search tool with 8 optional parameters, an output schema, and full schema coverage, the description covers the key decision points: what to search, how to filter, what to expect in results, and what limitations apply. It doesn't describe pagination or result ordering, but the limit parameter and output schema cover the return contract. The caveats about C-grade entries and taxonomy ownership are exactly the kind of context that prevents misuse.

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 8 parameters with examples and defaults. The description adds a bit of extra semantic guidance (e.g., combining keyword with category and region, verified=true meaning A-grade only), but it doesn't substantially extend the parameter meaning beyond what the schema provides. 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 description opens with a clear verb and resource: 'search the rCB technology and standards library', then enumerates the specific standard series and topics covered. It distinguishes itself from sibling tools like get_tech (which likely retrieves a single tech record) by framing this as a search across a library with filters.

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 provides usage guidance: combine keyword with category and region, use verified=true for standard-backed entries, and gives three concrete example calls. It also states what the tool is not for (full standard text is never reproduced) and flags C-grade entries as unverified leads, which helps an agent decide when to use this tool versus 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?

Beyond the read-only/idempotent annotations, the description discloses important behavioral and data-quality traits: customs-reported data only, derived fields, missing quantity handling ('missing_qty'), and a USD/t guardrail band. This gives agents substantial context for interpreting results and avoiding misuse.

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 with clear labeled sections (Purpose, Guidelines, Limits, Ex) and every sentence carries useful information. It is dense but not bloated, and the purpose 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?

Given the tool's complexity and the presence of a full input schema and output schema, the description is complete: it covers dataset scope, supported values, derived fields, limitations, guardrails, and example queries. Nothing critical is missing for selecting and invoking the 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 coverage is 100% and the schema already describes each parameter, including flow enums and partner formats. The description adds some useful context like derived-field definitions and natural-language examples, but largely restates parameter guidance already present in 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 states a specific verb ('query'), a precise resource (global carbon black HS 280300 bilateral trade flows), and the data source (UN Comtrade official customs statistics). It also gives concrete scope details (1751 records, reporters, years) and examples, making it easy to distinguish from sibling trade 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?

It clearly describes when to use the tool: for capacity shift, trade-partner concentration, and price-gap analysis, and explicitly excludes commercial quote platforms. It does not name sibling tools as alternatives or state when not to use them, so it falls just short of a perfect score.

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