EU Trade Explorer

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

No annotations provided, so description carries full burden. Details internal behavior: calls specific sub-tools, deterministic salience selection, unit consistency, exclusion of sub-contracting. Provides good insight into what the tool does beyond its return structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose and key logic. While somewhat detailed, each sentence adds value (e.g., salience explanation, unit consistency, exclusion note). Could be slightly more concise but structure is clear.

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 complexity of nested schema and internal logic, description covers behavior, return shape, and exclusions. No output schema, but states return fields. Missing explicit error conditions or prerequisites, but adequate for an internal helper 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?

Only parameter is a nested object with 100% schema description coverage. Description references the schema's own field descriptions, adding no extra parameter-level meaning. Baseline score of 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?

Describes the tool as a report-section helper for 'Autonomy & vulnerability', explicitly states it computes net import reliance, trade intensity, and export propensity, and explains the deterministic salience logic. Clearly distinguishes from sibling tools by referencing sub-tools and stating sub-contracting is excluded.

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?

Implied usage as a report-section helper, but lacks explicit guidance on when to use versus alternatives. Notes sub-contracting is not included, offering some exclusionary context, but no direct when-to-use/when-not-to-use or alternative suggestions.

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?

No annotations are provided, so the description must fend for itself. It describes the action as listing top-level chapters, which implies a read-only operation, but does not explicitly state safety, output format, or any constraints. Adequate but could be more transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main purpose, no unnecessary words. Every sentence earns its place.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the essential purpose and links to a sibling for deeper navigation. It could mention what the output looks like, but is largely complete.

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

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

The only parameter 'lang' is fully documented in the schema (100% coverage). The description adds no additional context about parameters, so 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 clearly states 'List all top-level Combined Nomenclature chapters (2-digit codes)' with a specific verb and resource. It distinguishes from the sibling tool get_subtree by noting that drill-down is done via that 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?

Explicitly says it's a bootstrap for top-down browsing and mentions get_subtree for drilling down. Provides clear use context, though it does not explicitly state 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?

With no annotations, the description carries full burden but only describes output (HHI, top-8 share). It does not disclose behavioral traits such as read-only nature, side effects, authorization needs, or rate limits, nor does it explain return format beyond the two metrics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with efficient explanation of the metric, scale, and secondary output. Front-loaded with key concept, no redundant or filler 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?

Despite a complex parameter set (nested DashboardQuery, many options) and no output schema, the description omits important context: it references 'top-8' but default n_top is 7, it doesn't mention that the tool returns time series data, nor does it explain the entity_level dimension. The description is insufficient for a comprehensive understanding.

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 input schema already documents parameters adequately. The description does not add extra meaning to any parameter (e.g., entity_level or n_top), but it explains the output (HHI scale) which is not in schema, keeping at 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?

Description clearly states the tool computes HHI with interpretation and top-8 share breakdown. It specifies the output metric and scale, but does not explicitly differentiate from sibling tools like get_concentration_compare or get_concentration_map, though the name and context imply concentration analysis.

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

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

No guidance on when to use this tool versus its many siblings (e.g., get_concentration_compare, get_concentration_map). Does not mention prerequisites or context for selection, leaving the agent without direction for appropriate 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?

No annotations are provided, so the description carries full burden. It describes the output (HHI lines per sub-product) but does not disclose behavioral traits like data source, limits, or what happens if no data. More context could be added.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences that are front-loaded and efficient. The first sentence states the purpose, the second adds context. No filler or 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?

The description adequately explains the output concept, but with 3 parameters and no output schema, an agent may need more information about the return format or edge cases. For a simple analytical tool, it is acceptable but not thorough.

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% for both top-level and nested parameters. The description adds marginal value by explaining 'HHI lines per sub-product' which relates to 'n_subcodes', but does not elaborate on other parameters 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 the tool compares HHI across sub-products, distinguishing it from the sibling tool 'get_concentration' which likely shows per flow. The verb 'compared' and resource 'sub-products' are specific.

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 implies use for comparing sub-products but does not explicitly state when to use this tool versus alternatives like 'get_concentration' or 'get_product_compare'. No exclusions or when-not-to-use guidance.

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

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

No annotations exist, so description must carry burden. Discloses cross-sectional nature and mentions the Rotterdam/Antwerp distortion, but does not cover auth, side effects, rate limits, or return format.

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?

Single paragraph that efficiently packs purpose, sibling relation, and entity_level explanation, but could be more structured with bullet points.

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 moderate complexity and no output schema, the description gives a good idea of input and concept but lacks specifics on output format (e.g., map data structure).

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. Description adds context on entity_level and partner_name requirement but does not significantly extend 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?

Description clearly states it computes cross-sectional HHI per country for one year, identifies as the choropleth counterpart of get_concentration, and explains the two entity_level modes, distinguishing it from siblings.

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

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

Provides context (choropleth counterpart) and explains entity_level options, but lacks explicit when-to-use vs. alternatives or when-not-to-use conditions.

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

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

No annotations provided, so the description bears full burden. It describes the tool as returning reference data, implying a read-only, non-destructive operation. It could mention that there are no side effects, but the description is sufficient for understanding behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, well-structured, and front-loaded with the purpose. Every sentence adds 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 no parameters, no output schema, and a simple purpose, the description is complete. It explains what data is returned and how to use the results in other tools.

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?

There are no parameters (0 params, 100% schema coverage). The description adds meaning by explaining what the tool returns, which goes beyond the empty 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 that the tool provides reference data for reporters/partners, including country lists, groups, and translations. It distinguishes itself from sibling tools (which are about trade data) by being a lookup tool for valid field values.

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 tells when to use the tool: 'Use this to find valid values for the fields...'. It does not mention when not to use it, but the context is clear given the sibling tools are for different purposes.

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?

No annotations provided, so description carries full burden. It discloses return format (YYYY-MM) and that it checks cached data, implying a safe read operation. No side effects or permissions mentioned, but for a simple query tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, no wasted words. Front-loaded with the action and output. Perfectly concise.

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 a single optional parameter and no output schema, the description fully explains what the tool returns and how to use it. It is complete for its complexity.

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

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

Schema description coverage is 100%, already describing the parameter. The description adds value by linking the parameter to the usage context and output, going 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 uses a specific verb 'Return' and resource 'period coverage' for product codes, clearly stating what the tool does. The format and usage context distinguish it from sibling tools like get_market_summary.

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

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

Explicitly says 'use before picking period_start/period_end so you don't request an empty window', providing clear when-to-use guidance. Does not explicitly mention alternatives or when-not-to-use, but the directive is strong.

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?

No annotations are provided, so the description bears full responsibility. It discloses that values are not clamped (above 100% possible) due to re-exports, stock drawdown, and scope differences. It also describes the output components. However, it does not mention idempotency, error conditions, or rate limits, which are less critical for a read-only query.

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 a single, concise paragraph that front-loads the definition. It is clear and to the point, though could be structured slightly more (e.g., separate lines for output components).

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 no output schema, the description mentions the return includes a matrix, comparison, codes, and notes, but lacks precise structure or format. For a tool with a complex input schema and no output schema, this is adequate but incomplete for an AI to fully anticipate the response shape.

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 detailed field descriptions. The tool description adds minimal parameter-specific information (only the not-clamped note on the output). Baseline 3 is appropriate as the schema does the heavy lifting.

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 defines the metric (Export Propensity = Exports / Production, annual) and states what the tool returns: the export-propensity matrix, sibling/per-code comparison, resolved codes, and notes. This is specific and distinct from sibling 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?

The description does not provide when to use this tool versus alternatives (e.g., other analytical endpoints). No exclusions or context about when not to use it, leaving the agent to infer usage from the name alone.

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

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

With no annotations, the description carries the full burden. It discloses that the tool guarantees the same product/reporter/partner/period slice across all sections, warns that separate calls have no such guarantee, and describes the return structure. It is clear about the read-only nature and the benefit, but does not mention auth requirements or rate limits.

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 concise yet comprehensive, structured in three paragraphs: purpose and alternatives, defaults and overrides, return format. Every sentence adds value, and the most important information (purpose and alternative tools) 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 combines five sections and no output schema is provided, the description fully explains the return format (query plus sections with narrative_facts, chart_data, links, etc.) and mentions the links field. It covers all necessary context for an agent to use 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% for both parameters, but the description adds significant value beyond the schema. It explains the defaults for query fields (e.g., reporter='European Union', period_start='2015-01') and how to override them for different slices, providing concrete examples like a specific member state or custom partner group.

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 fetches all five report sections in one call for a shared query, and explicitly names the alternative individual calls (e.g., get_product_profile, get_market_summary), distinguishing it from siblings.

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

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

The description advises using this tool instead of making five separate calls for consistency and completeness. It explains the guarantee of a consistent slice and mentions that individual calls risk mismatch. However, it does not explicitly state when not to use (e.g., if only one section is needed) or provide explicit alternatives beyond listing the individual tools.

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?

No annotations are provided, so the description must disclose behavioral traits. It mentions the output structure (per-period totals, keyed by GISCO code) but does not mention safety, side effects, permissions, or edge cases. Adequate but not thorough.

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 a single, front-loaded sentence without any waste. It efficiently communicates the tool's purpose.

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

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

Given the complexity of the input schema (nested query object with many sub-parameters) and no output schema, the description is insufficient. It lacks details on response format, use cases, and relationship to sibling tools.

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 no additional semantic information about the parameters (query and compact) beyond what the schema already provides.

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 'Choropleth-ready aggregates' with specific metrics (quantity, value, price) for imports and exports, keyed by GISCO country code. This gives a clear verb and resource, but does not differentiate from sibling tools like get_concentration_map.

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

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

No guidance is provided on when to use this tool versus alternatives such as get_concentration_map or other analytical tools. The description lacks context for selection.

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?

No annotations are provided, so the description carries full burden. It discloses that the three sources are independent and that most_specialised reporters are pre-sorted. It describes the return value structure. While it omits authentication needs or error conditions, for a read-only data retrieval tool this is sufficient.

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 detailed but front-loaded with the main purpose. It could be more concise by using bullet points, but the information is well-organized and each sentence adds value given the tool's complexity.

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 explains the return value shape, the independence of data sources, and how to use pre-sorted fields. With no output schema, it provides good context for interpreting results. The only minor gap is lack of error handling or edge case details.

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% (all parameters documented). The description adds context about the query parameter being shared among endpoints and mentions prodcom_code behavior, but does not significantly enhance parameter understanding 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 it is a 'Market structure report-section helper' that combines three specific data sources (get_specialisation, get_concentration, get_production_series). It explains what returns (narrative_facts, chart_data, available, reason) and distinguishes the tool from siblings by detailing the independent nature of the sources.

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 explains when to use this tool (to get a combined market structure view) and provides guidance on treating the sources as separate findings. It also notes that prodcom_code is passed through without guessing, leaving ambiguity to the caller. However, it does not explicitly state when not to use it or suggest alternative tools.

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?

No annotations provided, so description carries full burden. It details the return structure (narrative_facts, chart_data, available, reason) and explains key behaviors: NIR is always annual, PRODCOM mapping may be omitted, query is exactly as given. While it does not cover auth or rate limits, it sufficiently discloses the tool's behavior and edge cases.

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: first paragraph states purpose and key recommendation, second clarifies constraints, third details return fields. While not extremely concise, it front-loads important information and each sentence serves a purpose. Minor redundancy could be trimmed.

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

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

Given the tool's complexity (multiple return components) and rich schema coverage (100%), the description is complete enough. It explains the return structure, provides a concrete example of usage, and covers the main behavioral aspects. However, it lacks discussion of error handling or performance considerations.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by recommending 'frequency': 'year' for multi-year summary, and clarifying that the query is applied exactly as given. It also implicitly links parameters to the return values, enhancing understanding 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 it's a 'Report-section helper' that provides a 'condensed, report-ready digest of how a market has evolved', and explicitly contrasts it with separate tools (get_overview, get_reporter_detail, etc.). This distinguishes it from siblings and gives a clear, specific verb and resource.

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 when-to-use ('one call instead of separately fetching...') and when-not-to-use guidance ('Nothing here substitutes a different reporter or partner_set'), with a concrete frequency recommendation ('Set query.frequency = "year"'). It also tells the user how to achieve alternative results (call again with different partner_set).

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?

No annotations are provided, so the description carries full burden. It discloses the return structure, the non-1:1 CN-to-PRODCOM mapping, and the availability notes field, providing comprehensive behavioral context.

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 formula, example, return contents, and usage tip. It is informative but slightly lengthy; could be trimmed for conciseness.

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 complexity of the nested query object and no output schema, the description adequately explains the purpose, calculation, return components, and special notes about mapping, making it complete for agent usage.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context about the `compact` parameter and the role of `prodcom_code`, but does not elaborate on other parameters since the schema already fully explains them.

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 defines Net Import Reliance with its formula, explains what the tool returns (NIR %, components, comparisons), and distinguishes it from other analytical tools by specifying the joining of PRODCOM and Comext data.

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 the purpose and includes a usage tip about pinning a specific PRODCOM code. However, it does not explicitly state when not to use this tool or mention alternative tools.

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?

No annotations are provided, so the description bears the full burden of behavioral disclosure. It correctly implies a read-only operation (presenting headline figures) but does not explicitly state safety, idempotency, or potential side effects. The description is adequate but could be more transparent about the nature of the tool.

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 extremely concise: two sentences that immediately convey the tool's purpose and its recommended usage as the first call. Every sentence adds value, with no wasted words. This is an exemplary model of brevity and clarity.

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 low complexity (two parameters, no output schema) and the high-quality schema descriptions, the description is fairly complete. It covers purpose and usage. However, a brief note on the return format (e.g., 'returns a JSON with headline series and top partners') would slightly improve completeness, but it's not critical.

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% coverage, with detailed descriptions for all sub-parameters in the DashboardQuery object and the compact parameter. The description of get_overview adds no new parameter-level information beyond what the schema already provides. Per the rubric, baseline 3 is appropriate when schema coverage is high.

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 provides 'headline figures' including import/export quantities, values, prices, trade balance, and top-partner breakdown. It also specifies it's 'the best first call for any new product/reporter slice,' which distinguishes it from more detailed sibling tools like get_partner_detail or get_volatility.

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 advises using this tool as the first call when exploring a new product/reporter slice, giving clear context for its primary use case. However, it does not explicitly mention when not to use it or name alternative tools for follow-up analysis, though the implication is strong given the sibling list.

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 no annotations, the description reasonably discloses the output structure (rankings, series, 'Other' bucket). However, it does not mention input requirements (e.g., required 'product' field in query), side effects, or limitations, leaving some behavioral aspects opaque.

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 two sentences, efficiently front-loading the purpose and adding detail. Every word earns its place with no wasted or redundant text.

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

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

Given the tool's complexity (nested query object) and lack of output schema, the description is incomplete. It omits the return structure details, does not differentiate from many siblings, and fails to mention the required query parameter.

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

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

Schema description coverage is 100% with detailed parameter descriptions, so baseline is 3. However, the tool description adds no value by explaining parameters or their semantics beyond the schema, effectively remaining silent on how to use the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides a per-partner breakdown with rankings by quantity and value, plus time series and an optional 'Other' bucket. However, it does not differentiate this tool from similar sibling tools like get_market_structure_summary or get_reporter_detail, lacking explicit distinction.

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 no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or conditions under which it is appropriate, leaving the agent without decision support.

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 no annotations, the description carries the full burden. It explains the analysis: compares average quantity and price before vs. after, returns change percentages with quadrant interpretations. It doesn't explicitly state read-only behavior but the description implies no side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences that are front-loaded with core functionality and a suggested workflow. No fluff, every sentence adds 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 complexity of the nested schema, the description adequately focuses on the key parameter and output semantics. Lacks output schema details but provides quadrant interpretations. Relates to sibling tools, providing workflow context.

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% due to detailed DashboardQuery schema descriptions. The tool description adds value by explaining the midpoint parameter's role and default behavior, and relates it to the workflow. The compact parameter description in schema is also clear.

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 clearly states it performs a before/after trade-pattern shift analysis around a split point, returns scatter points with quadrant labels, and distinguishes itself by referencing sibling tools get_supply_shocks and get_price_shocks in the suggested workflow.

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 suggested workflow: first use get_supply_shocks or get_price_shocks to identify a shock date, then set it as midpoint here. This gives clear context for when to use this tool, though it doesn't explicitly state 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?

With no annotations provided, the description carries the full burden. It explains the algorithm's core behavior: it accounts for each flow's usual volatility to avoid over-flagging, and describes the output structure (ranked events, phases, magnitude). This is fairly transparent for a read-only analytical tool.

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 two sentences, front-loaded with the core purpose, and contains no wasted words. It efficiently conveys the essential 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?

Given the complexity of the tool (shock detection), the description provides a good high-level overview but lacks specifics about the exact return format (e.g., list of shocks, nested structure). Without an output schema, more detail would be beneficial for complete understanding.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context about the output (phases, magnitude, series) but does not add meaning to the input parameters beyond what the schema already provides. It remains at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool detects sudden price regime shifts, accounting for volatility, and specifies it returns ranked shock events with timeline phases, magnitude, and series. It distinguishes itself from sibling tools by focusing on price shocks with volatility normalization.

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 explains what the tool does but provides no explicit guidance on when to use it over alternatives or when not to use it. The context of use is implied but not stated, lacking differentiation from similar tools like get_supply_shocks.

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 no annotations provided, the description carries full burden. It discloses key behaviors: for a single parent CN it expands into children, for multi-code it compares directly, leaf codes return 'leaf: true', and it returns per-subcode quantity/value/price series for both flows. It does not contradict any annotations (none exist), and provides sufficient transparency for safe invocation.

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 a single paragraph but is well-structured and front-loaded with the core purpose. It could be slightly more concise by splitting into two sentences, but every sentence adds necessary context without extraneous detail.

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 large set of sibling tools, the description adequately explains its unique role (sub-product comparison) and key behaviors. It mentions leaf handling and output type, but does not explicitly define 'both flows' (import/export), which might be assumed. No output schema exists, but the description covers return format sufficiently.

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 the two parameters, but description adds value beyond schema. For 'product', it explains the expansion vs direct compare behavior, and for 'compact', it gives practical advice on when to set true or false. The schema already describes defaults and types, so the description enhances understanding 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's function: 'Sub-product comparison' which expands a parent CN code into its children or compares multiple codes directly, returning per-subcode series. It distinguishes itself from siblings by noting that sub-products plot as individual lines rather than being aggregated, making it unique among many analytical 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?

The description implies when to use the tool (when sub-product breakdown is needed) but does not explicitly state when not to use it or mention alternatives among the many sibling tools like get_autonomy_summary or get_overview. It briefly mentions leaf code behavior, which gives some context, but lacks explicit usage 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?

No annotations are provided, so the description carries full burden. It discloses that suppressed/absent country figures return as null (not zero) and mentions the data source (PRODCOM, EU member states plus others). It does not contradict any annotations. However, it does not explicitly state the operation type (read-only) or potential side effects.

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 moderately concise, conveying key points (purpose, scope, null behavior, usage hint) in a few sentences. However, it includes a specific code reference ('DS-059358') that may clutter the main message and could be shortened. Front-loaded with purpose.

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

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

The description covers the tool's scope and output metrics (HHI, shares) but lacks details on output format or how to interpret results. No output schema exists, so more context would be beneficial. Given the complexity and many sibling tools, additional guidance (e.g., difference from get_concentration) would improve completeness.

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 parameters in detail. The description adds minimal value for parameters; it only mentions 'prodcom_code' in a usage hint. The behavioral note about nulls is useful but not parameter-specific. 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 clearly states the tool calculates HHI of PRODVAL across countries and production shares for a given product, distinguishing it as production concentration (PRODCOM data) versus trade concentration. It specifies the scope (DS-059358 reporting countries). However, it does not explicitly contrast with sibling tools like 'get_concentration'.

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 includes one usage hint ('Use query.prodcom_code to pin a specific PRODCOM mapping') but provides no guidance on when to use this tool versus alternatives, such as get_concentration or get_production_series. No when-not-to-use or exclusions are mentioned.

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 no annotations, the description fully discloses behavior: it states that suppressed/absent values return as null (not zero), highlights heavy confidentiality suppression, and clarifies reporter coverage. This level of detail is excellent for a read-only data retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with dense, front-loaded information. Every sentence adds value: first states purpose and scope, second explains data quality and a usage tip. No wasted words.

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 no output schema, the description provides enough context: it names the returned metrics, explains null behavior, and covers reporter scope. It could briefly mention that time series frequency is configurable via schema, but overall it is adequate for a production data endpoint.

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 parameters are well-documented. The description adds specific value by explaining the prodcom_code parameter's role in pinning a PRODCOM mapping when CN codes map to several. This goes beyond schema. However, it does not add context for other parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides EU27 and per-country PRODCOM production series with specific metrics (quantity, production unit value). It distinguishes from trade tools by noting 'no trade columns' and clarifies the reporter scope beyond EU27. This is specific verb+resource with clear scope.

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 lacks explicit guidance on when to use this tool versus alternatives like get_production_concentration. It does provide a usage tip for prodcom_code disambiguation, but no when-not-to or alternative references. Usage is implied but not explicitly outlined.

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 no annotations, the description carries the full burden. It discloses the return fields (narrative_facts, chart_data, available, reason) and explains what each covers. However, it does not mention side effects, permissions, or limitations beyond being 'thin', leaving some gaps.

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 concise with two paragraphs, front-loading the purpose and listing return aspects. However, reliance on an external tool reference (get_market_summary) for output shape slightly reduces self-containment.

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 no output schema, the description adequately explains the return shape and key aspects. It covers the essential information but could be more explicit about the output structure without referencing another 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% (both parameters have descriptions). The tool description adds no additional parameter information beyond what the schema provides, so the baseline score of 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 clearly states it is a 'Report-section helper' that returns the resolved product code/label, subcode caveat, data-coverage window, and PRODCOM mapping status. It distinguishes itself from siblings by noting it is 'deliberately thin' and lacks full hierarchy, making its purpose specific and unique.

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 implies usage as a 'Report-section helper' for the 'Scope & definitions' section, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or when-not-to-use scenarios. Referencing get_market_summary for output shape gives some context but not clear guidelines.

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 no annotations provided, the description carries the full burden and discloses key behavioral traits: returns a single-year snapshot, conditional inclusion of the selected reporter's own price line when 'query.reporter' is a single real member state, and the benchmark series (EU average, min/max). This is comprehensive for a read-only tool.

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 two sentences, starting with the primary purpose. The first sentence is long but packs necessary detail. It is concise without being terse, though it could be more 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?

Despite lacking an output schema, the description provides a complete picture of what the tool returns: quantity, value, price per flow, ranked, plus benchmark time series with conditional elements. This is sufficient for an agent to understand the output.

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 parameters well. The description adds value by clarifying the behavior conditional on the reporter parameter (single real member state triggers own line). This additional context justifies a score above baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool ranks every EU reporter by value for one year and is the 'country-view counterpart of `get_reporter_detail`'. It specifies the output includes quantity, value, price per flow, and a benchmark price time series. This distinguishes it from siblings effectively.

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 'Use it to answer "how does this country compare to every other EU reporter?"' and mentions the counterpart sibling. It does not provide explicit when-not-to-use scenarios, but the context is clear enough for an AI agent to decide.

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?

No annotations are provided, so the description carries the full burden. It discloses that aggregate reporters are excluded and that it shows top-N rankings, which is adequate for a read-only data retrieval tool. No mention of error handling or edge cases, but the core behavior is clear.

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 extremely concise at two sentences, front-loaded with the key action ('Per-EU-member-state import/export breakdown'), and uses bolding for emphasis. Every word serves a purpose with no 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?

Given the complexity of the tool (nested query object, numerous parameters) and no output schema, the description covers the main behavioral aspects: the type of breakdown, top-N ranking, exclusion of aggregates, and relationship to sibling. It does not detail the exact response structure, but the mention of quantity, value, and price series provides sufficient expectation.

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

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

With 100% schema description coverage, the baseline is 3. The description adds contextual meaning beyond the schema by specifying that it's the reporter-side counterpart, excludes aggregate reporters, and focuses on top-N breakdown. This extra context justifies a score of 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 provides a per-EU-member-state import/export breakdown of top-N member states by quantity and value with price series. It explicitly distinguishes itself from the sibling tool 'get_partner_detail' by being the reporter-side counterpart.

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 indicates this tool is for reporter-side analysis and is the counterpart of get_partner_detail, providing implicit guidance on when to use it. However, it lacks explicit when-not usage or alternative tools beyond this counterpart.

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 no annotations, the description carries full burden. It discloses the metric range, intra-EU scope, and a key caveat (distortion from transit). However, it lacks details on authentication, rate limits, error conditions, or performance implications. The caveat adds notable transparency but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact paragraph of three sentences. It front-loads the key metric, explains the range, and adds a crucial caveat. No wasted words.

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 explains the metric well but does not describe the output structure or how the 'year' parameter affects results. Given no output schema, more detail on return format (e.g., per member state, time series) would improve completeness. Adequate for an experienced user but not fully informative.

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% (every parameter described in schema). The tool description does not add new parameter-level meaning beyond 'intra-EU only' context, which is already implied by the metric. 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 clearly states it computes Intra-EU revealed symmetric comparative advantage (RSCA) per member state, explaining the metric (Balassa index), range (-1 to +1), and scope (value-based, intra-EU only). It also gives a caveat about the Rotterdam/Antwerp effect, distinguishing it from other analytics 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?

No explicit guidance on when to use this tool over alternatives like get_concentration or get_export_propensity. The description implies use for specialisation analysis but does not provide context or comparisons.

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 no annotations, the description carries the full burden. It discloses what the tool returns (intensity, series, quality, codes, notes) and a key behavior (data only from 2021). It does not mention safety traits (e.g., read-only) but the read-like nature is clear from the context.

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 a single, dense paragraph that front-loads the key purpose and then efficiently lists return components. Every sentence adds value; no fluff.

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 has a complex nested parameter (query) but no output schema, the description competently outlines the return data (intensity, series, quality, codes, notes). It could be more explicit about the output structure, but the provided list is adequate for an agent to understand the result.

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

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

Schema description coverage is 100%, so baseline is 3. The tool description adds no new parameter details beyond the schema, though it does direct users to the schema's field descriptions for the 'query' parameter. The description of 'compact' in the schema is already clear.

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 verb 'returns' and the specific resource 'EU27 sub-contracting intensity', defines what it measures (share of toll vs own-account production), and lists the return components (intensity, series, data quality, codes, notes). It also notes the temporal constraint (split only from 2021). This distinguishes it from sibling tools like 'get_subcontracting_members'.

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 implies usage for subcontracting intensity queries but does not explicitly state when to use this tool versus alternatives (e.g., 'get_subcontracting_members' for member breakdowns). No when-not-to-use guidance or exclusion criteria are provided.

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?

No annotations are provided, so the description must cover behavioral traits. It does disclose that null values indicate confidentiality suppression (not zero) and that only reporters providing the split are included. However, it lacks details on read-only nature, permissions, rate limits, or data freshness. The description provides some transparency but is not comprehensive.

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 a single paragraph that efficiently conveys the tool's purpose, data source, and key behavioral notes without superfluous content. It is front-loaded with the core concept, though could be slightly more structured (e.g., separating purpose from data notes). Overall, it is concise and earns its sentences.

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 explains the data source and null handling but does not describe the return structure or response fields (since no output schema exists). It gives enough context for a basic understanding but lacks completeness regarding what the response looks like and how it fits with sibling tools beyond a single mention of reporters. Moderate completeness given the tool's complexity.

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

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

Schema description coverage is 100% (both `query` and `compact` are documented in the input schema). The description does not add meaningful parameter-level semantics beyond what the schema already provides; it focuses on the tool's purpose. Baseline 3 is appropriate as the schema handles parameter documentation.

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 that the tool returns per-country sub-contracting intensity (share of toll manufacturing) from PRODCOM data, distinguishing it from likely siblings like `get_subcontracting`. It explains what the data represents and how missing values are handled (null for confidentiality), making the purpose very specific and clear.

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 implies that the tool is for countries that report the own/sub split ('others simply don't appear'), but does not explicitly state when to use this tool versus alternatives like `get_subcontracting`. No exclusions or alternative tool names are provided, so guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the burden. It describes the return structure (code and text) and that it returns the full sub-tree. However, it does not mention authentication requirements, error handling, or any side effects.

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 three sentences, each serving a purpose: action, output, and usage. It is front-loaded and contains no unnecessary words.

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 query tool with no output schema, the description adequately explains purpose, parameters, and return format. It could mention error handling or limitations (e.g., large subtrees), but is otherwise complete.

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

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

Schema description coverage is 100%, so the schema already explains both parameters. The description adds a usage example ('e.g. '7010') and contextual guidance, but does not provide significant additional meaning 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 the tool returns the Combined Nomenclature sub-tree rooted at a code, including children and their children. It also provides a concrete use case, distinguishing it from sibling tools like search_codes or validate_code.

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 this tool: to check if a heading is a clean match or bundles sub-products. It does not explicitly state when not to use it or mention alternatives, 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?

No annotations exist, so the description carries the full burden. It discloses the detection method (>2 sigma default), output structure (phases, magnitude, score), and defaults, which is rich. However, it omits potential side effects (e.g., data fetching latency, precision limits) that a fully transparent description might include.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: first states purpose, second adds detection criteria, third lists outputs. Every sentence earns its place; no fluff. Front-loaded with the primary action.

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 (9 parameters, no output schema), the description provides a solid overview of inputs and outputs. However, it does not explain the return format in full detail (e.g., structure of a shock event), which could hinder precise use. Still, it covers the essentials.

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

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

Schema coverage is 100%, with detailed descriptions per parameter. The tool description adds some overarching context (e.g., the >2 sigma threshold) but does not significantly augment individual parameter semantics beyond what the schema already 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 uses a specific verb ('Detect abnormal collapses') and resource ('trade volumes'), clearly distinguishing from siblings like 'get_price_shocks' or 'get_volatility'. It details outputs (phases, magnitude, score), making the tool's purpose highly specific and 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?

The description implies usage for detecting volume collapses but does not explicitly state when to use over alternatives (e.g., 'get_price_shocks'), nor provides when-not or exclusion criteria. The context is clear but lacks comparative 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?

No annotations are provided, so the description must convey behavioral traits. It states the tool returns an 'ordered list' and is 'lightweight', implying a read-only, fast operation. However, it does not explicitly mention idempotency, auth requirements, or rate limits. The name 'get' suggests read-only, but the description could be more transparent about side effects (likely none) and data freshness.

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 two short sentences with no unnecessary words. It front-loads the core function ('ordered list') and adds context in the second sentence. Every part is informative and to the point.

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 explains the tool's purpose and usage context effectively, given its simplicity and the lack of an output schema. It tells the agent what to expect (a list) and when to use it. However, it does not describe the output structure (e.g., fields returned) or any limits/pagination, which would be helpful for a complete understanding.

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

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

Schema coverage is 100% with detailed descriptions for all parameters, so the baseline is 3. The description does not add any parameter-specific information beyond what the schema already provides. It is adequate but does not enhance understanding of parameters like 'n', 'flow', or 'entity_level'.

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 it returns 'the ordered list of top entities for a slice' and distinguishes from 'no time series'. It also provides use cases: 'populating entity pickers' and 'quickly checking who the top partners/reporters are without pulling full series'. This explicitly communicates the tool's purpose and scope, differentiating it from sibling tools that return time series or full details.

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 advises when to use this tool: 'a lightweight helper for populating entity pickers or quickly checking who the top partners/reporters are without pulling full series'. It implies it is for quick, simple retrieval of a ranked list, contrasting with tools that return full time series. However, it does not explicitly name alternative tools or specify when not to use it, so it falls short of a 5.

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

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

With no annotations, the description must disclose all behavioral traits. It explains what is returned (TI series, components, comparisons, codes, notes) and the meaning of values, but lacks details on pagination, error handling, or performance. Adequate but not comprehensive.

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 concise at ~60 words, conveying the formula, interpretation, use case, and return contents in one efficient paragraph. Every sentence adds value with no 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?

Given the tool's specificity (a single metric) and detailed schema, the description provides sufficient context: what TI is, its range, its significance, and what is returned. It lacks comparison to siblings and details on data structure, but for its purpose it is fairly complete.

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

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

Schema coverage is 100% with detailed field descriptions. The description adds context by explaining the TI formula and purpose, which indirectly aids parameter understanding, but does not directly elaborate on specific parameters 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 defines Trade Intensity with its formula and range, states its use in CEEAG methodology, and lists the returned components (TI series, comparisons, resolved codes, availability notes). It provides a specific verb-resource pair and distinguishes itself from siblings by detailing the unique metric.

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

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

No explicit guidance on when to use this tool versus alternatives like get_net_import_reliance. The description implies usage for carbon-leakage assessment but does not state when not to use it or suggest 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?

No annotations are provided, so the description carries the burden. It mentions data exclusion ('inactive-period-excluded history') and output type (bars and heatmap). However, it doesn't disclose whether the tool is read-only, any authentication needs, or limitations. No contradictions since no annotations exist.

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 two sentences, front-loads the key definition (CV), and includes optional behavior (include_heatmap). Every sentence adds value without redundancy. Highly 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?

The tool has 10 parameters and no output schema. The description mentions returning 'per-entity CV bars (with drill-down series)' and a heatmap, but does not describe the response structure in detail. For an agent to use it correctly, more detail about the output format would be beneficial. Additionally, no annotations are provided for behavioral context.

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% coverage with detailed descriptions for all parameters. The description adds context about output (drill-down series, heatmap) but does not enhance understanding of individual parameters beyond the schema descriptions. 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 clearly states it calculates coefficient-of-variation (CV) volatility per partner/reporter x product pair. It specifies the output: per-entity CV bars and optionally a heatmap. This clearly distinguishes from sibling tools like get_concentration or get_pattern_shift.

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 explains what the tool computes and that a heatmap is optional, but does not explicitly state when to use this tool versus alternatives (e.g., get_volatility_summary). The guidance is implicit: use it for volatility analysis. No exclusions or when-not-to-use are mentioned.

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?

Given no annotations, the description entirely carries the burden. It discloses entity selection logic, retry once with loosened thresholds, fallback strategy when shocks are absent, and the return structure. This is thorough and leaves little ambiguity.

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 moderately long but well-structured, starting with purpose then moving to selection, retry, fallback, and return format. Every sentence adds value given the complexity of the orchestration.

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 covers orchestration, retry logic, fallback, and return format. The return format is briefly described but lacks detailed field types; however, given no output schema, this is acceptable. Overall complete for a summary helper.

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 single parameter 'query' has 100% schema coverage via DashboardQuery, so the baseline is 3. The description does not add any extra parameter-specific information beyond what the schema already provides.

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 is a 'Report-section helper' for 'Volatility & shocks' and explains how it composites data from get_volatility, get_price_shocks, and get_supply_shocks. It distinguishes itself from these siblings by describing its orchestration and fallback behavior.

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 implies usage context: it is a helper for generating the volatility & shocks section of a report. It does not explicitly state when not to use it or provide alternative tools, but the context is clear enough for an AI agent.

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 indicates the tool returns guidelines, implying it is a read-only informational tool. While annotations are absent, the description does not explicitly state that it has no side effects, but the context strongly suggests safe behavior. A minor improvement would be explicit mention of read-only nature.

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 extremely concise at four sentences, front-loaded with the critical 'Read this first' directive. Every sentence provides necessary context without redundancy. Excellent structure.

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 has no parameters and an output schema exists, the description is complete. It clearly defines the tool's purpose, usage, and return value (guidelines). No gaps are present.

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

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

There are zero parameters, and schema coverage is 100% (vacuous). The description adds no parameter information, which is appropriate. Baseline score of 4 is justified as no parameter elaboration 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 clearly states that this tool returns guidelines for using the bridge's tools to research and write trade reports. It specifies the workflow, shared query object, and compact option, distinguishing it from sibling tools that perform specific data retrieval.

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 read this first and call before guessing at tool use. Provides clear context for when to use this tool (initial orientation) and mentions alternatives (individual tools for deeper dives), offering excellent usage 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?

Without annotations, the description discloses key behaviors: bare keyword triggers a search, single code or comma-separated list is validated directly, and include_children fetches subcodes. It mentions has_subcodes check. No destructive or auth-related details needed for a read-only resolver.

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 concise and well-structured: a single paragraph that states purpose, then adds a practical tip. Every sentence contributes value 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?

Given no output schema, the description mentions the response includes validated product codes with descriptions and has_subcodes flag. It covers the main return elements. For a resolver tool, this is sufficient, though a full output structure outline would be helpful.

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 meaningful context: explains query can be free-text or codes, lang is for labels, limit applies only to keyword searches, and include_children allows exploring subcodes. This adds value 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 the tool resolves free-text queries or CN codes into validated product codes. It highlights it as the recommended first step before using a code as product in other tools, and distinguishes from siblings like search_codes and validate_code by combining search and validation in one call.

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

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

The description positions the tool as the recommended first step and explains usage scenarios (keyword search vs code validation). It also provides a practical tip about CN nomenclature granularity and the include_children parameter. However, it does not explicitly specify when to avoid using this tool in favor of specific siblings.

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

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

With no annotations, the description discloses the output format (ranked {code, label, path} candidates) and notes auto-detection behavior for dotted PRODCOM codes. It lacks an explicit statement of read-only nature, but the search context implies it. Overall, it provides good behavioral context.

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 extremely concise, consisting of three sentences with no extraneous information. It front-loads the purpose and efficiently provides 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 search tool with no output schema, the description adequately covers the data sources, output format, and relevant behavioral traits (auto-detection), making it complete for an agent to 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the return structure and auto-detection behavior for the source parameter, enhancing understanding beyond 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 clearly states the tool performs a keyword/code search over Combined Nomenclature or PRODCOM, and explicitly distinguishes it from the sibling tool 'resolve_product_code' by mentioning the latter as a one-call helper while this tool returns a raw ranked candidate list.

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 directs the agent to prefer 'resolve_product_code' for a one-call helper and to use this tool when the raw ranked candidate list is desired, providing clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries full burden. It discloses return structures for single and list inputs, including details on hierarchy levels, product_name, has_subcodes, and error pairs. However, it does not mention authentication, rate limits, idempotency, or side effects beyond output. The description adds some behavioral context over the schema but is not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core purpose. It efficiently covers both single and list behavior without redundant phrasing. Every sentence adds distinct value, and the structure makes the tool's behavior immediately understandable.

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 low complexity (2 parameters, no nested objects, no output schema), the description is largely complete. It explains what the tool returns for both cases and hints at error handling. However, it could be more complete by explaining the format of the hierarchy or the possible values of 'has_subcodes', but these gaps are minor.

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 echoes schema information (comma-separated list, TOTAL literal, language parameter) but does not add new semantic meaning beyond what the schema already provides. It does not explain default behavior for 'lang' or the exact format of response fields.

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 it validates and describes Combined Nomenclature codes, with specific verb 'validate and describe' and resource 'CN codes'. It distinguishes between single code and list inputs. However, it does not explicitly differentiate from sibling tools like 'resolve_product_code' or 'search_codes', which may have overlapping purposes.

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

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

No guidance on when to use this tool versus alternatives. The description explains what the tool does but does not address scenarios where other tools (e.g., 'resolve_product_code') would be more appropriate. No when-not-to-use or prerequisite information is provided.

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