EU Trade Explorer

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

With no annotations, the description carries the transparency burden and meets it: it discloses the deterministic salience scoring, states that the caller cannot influence the lead choice, guarantees unit consistency for trade_intensity_pct, and explicitly documents why sub-contracting is omitted. It also reveals the return envelope, including the available/reason fallback signals.

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 front-loaded with the purpose, keeps the key behavioral caveats in a logical order, and ends with the return envelope. No sentence is wasted; the length is justified by the tool's algorithmic 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?

Given the rich output schema and the extensive sibling context, the description covers purpose, internal decision logic, data-consistency guarantees, exclusions, and the returned object envelope. It leaves no significant ambiguity about what the tool returns or how it arrives at the narrative.

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 already provides full descriptions of every parameter inside the query object (100% coverage), so the description need not repeat them. The only added semantic context is that the request body is identical to every other tradedashboard.eu analytical endpoint, which is useful but marginal; hence 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 opens by positioning the tool as the 'Autonomy & vulnerability' report-section helper and names the exact headline metric (net import reliance) plus the two computed metrics. It distinguishes this summary tool from the individual sibling tools (get_net_import_reliance, get_trade_intensity, get_export_propensity) by explaining that it decides which metric leads the narrative.

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

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

It clearly identifies when to use the tool (as the report-section helper) and explicitly excludes sub-contracting as an unrelated topic. It names the underlying metric tools, but it does not explicitly formulate alternative conditions such as 'use get_trade_intensity when you only need that series,' so guidance is strong but not fully exhaustive.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It clearly implies a read-only list operation and clarifies that only top-level entries (2-digit codes) are returned, which is a key boundary. However, it does not explicitly address potential missing behavior like pagination or language-specific variations, though the lang parameter is fully documented in the schema.

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

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

The description is two concise sentences. The first states the core purpose, and the second gives navigation context. There is no wasted wording, and the information is front-loaded.

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

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

The tool is simple with one parameter and an output schema. The description provides enough context for an agent to select and invoke the tool correctly, including its role in the browsing flow and the pointer to get_subtree for deeper exploration. The output schema handles return-value details, so no additional description is needed.

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 covers the only parameter 'lang' with a complete list of supported values, achieving 100% schema description coverage. The description itself does not add parameter-specific detail, which is acceptable given the schema already provides full semantics, but it also does not enhance the 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 uses the specific verb 'List' with the resource 'top-level Combined Nomenclature chapters' and specifies '2-digit codes', making the tool's function clear. It also distinguishes itself from the sibling get_subtree by positioning itself as the top-down bootstrap and referencing the drill-down 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?

The description explicitly states when to use this tool ('Bootstraps browsing the nomenclature top-down') and provides a clear alternative for the next step ('drill into a chapter with get_subtree'). This gives the agent direct guidance on how this tool fits into the workflow.

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 does disclose behavioral context: the HHI range (0-10000), the top-8 breakdown with rest bundled as 'Others', and the interpretation of higher HHI. However, it does not mention any caveats around data sources, completeness, or the shape of the response (e.g., per-period time series), so it is adequate but not rich.

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 metric and quickly adds the key interpretation detail. Every part adds value: the HHI range, the top-8 breakdown, and the practical implication. There is no fluff 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?

An output schema exists, so return values are covered elsewhere. The description provides a useful high-level understanding but does not position the tool among its many siblings or explain how the compact/entity_level/query parameters alter the output. It is complete enough for basic understanding but lacks contextual depth for an agent to fully plan a call.

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

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

Schema description coverage is 100%, so the baseline is 3. The description itself does not reference any parameters, but the schema already provides detailed descriptions for every field (e.g., entity_level, compact, query sub-fields). No additional value is needed, and no gaps are present.

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 what the tool returns: the Herfindahl-Hirschman Index (HHI) of trade concentration across partners or member states, plus a top-8 breakdown. The verb is implicit but unambiguous. However, it does not explicitly differentiate from sibling tools like get_concentration_compare or get_concentration_map, so it does not reach a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives. It explains what HHI means ('Higher HHI = more dependent on a handful of counterparties') but never mentions when to choose this over get_concentration_compare, get_concentration_map, or other concentration-related tools. There are no alternatives noted and no exclusions.

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 the key behavioral trait of producing one HHI line per sub-product, but does not mention other behavioral aspects such as data source, response structure, or any side effects. The output schema helps fill gaps, but the description alone is limited.

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, focused sentence that front-loads the core concept (HHI comparison across sub-products) and the key differentiator (line per sub-product). It is concise and every phrase contributes meaning, with no redundant 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?

While the output schema provides rich descriptions for all parameters, the description itself is minimal. It lacks guidance on when to use this tool versus siblings like get_concentration or get_concentration_map, and does not mention that the query body is shared with other endpoints (though the schema does). Given the tool's moderate complexity, the description is adequate but not 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 baseline is 3. The description's phrase 'one HHI line per sub-product' adds little beyond what the n_subcodes parameter description already states ('Max number of sub-products to plot as separate HHI lines'). No additional parameter semantics are provided in the description.

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

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

The description states the specific verb 'compared' and resource 'Partner-concentration (HHI) across sub-products', clearly distinguishing it from per-flow tools. It explicitly says 'one HHI line per sub-product rather than per flow' and the intended purpose 'to see which sub-products drive a parent code's overall concentration', which differentiates it from siblings 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 provides clear usage context by contrasting with per-flow analysis ('rather than per flow') and stating the goal of identifying which sub-products drive concentration. However, it does not explicitly name alternative tools or state when not to use this tool, so it does not fully meet the 'explicit alternatives' bar.

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 discloses the cross-sectional year-specific behavior and the Rotterdam/Antwerp entry-point distortion, which is a useful caveat. It does not detail return behavior, but the output schema fills that gap.

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

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

Two sentences, front-loaded with the main purpose, and no unnecessary detail. Highly concise while conveying 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?

The description captures the core concept, the two modes, and a caveat. While it does not mention the 'query' or 'compact' parameters, the schema fully describes them. For an agent, it provides enough context to select the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds the conceptual explanation of entity_level and the distortion, but the schema already documents entity_level and other parameters thoroughly, so minimal added value.

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

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

The description clearly states the tool computes cross-sectional HHI per country for one year and identifies itself as the choropleth counterpart of get_concentration, distinguishing it from sibling tools. It also explains both entity_level modes in concrete terms.

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 this tool (when a choropleth/map view is needed) by referencing get_concentration, and explains the two entity_level options. However, it does not explicitly exclude alternatives or 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 the transparency burden. It identifies the tool as 'reference data', implying a read-only lookup operation. It also describes the scope of data it returns, which is useful behavioral context. It does not explicitly state that it has no side effects or require authentication, but for a zero-parameter reference 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?

Two sentences, front-loaded with the tool's purpose, and every phrase adds concrete information. No filler or repetition of the title or schema.

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

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

Given that the tool has zero parameters and an output schema exists, the description completely covers purpose, content, and usage. No additional details about return structure or edge cases are necessary for this simple lookup tool.

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

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

The tool has no parameters, so the baseline is 4. The description adds value by explaining what the returned reference data is used for, which is the relevant semantic context in place of 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 clearly states that this tool provides reference data for reporters/partners and enumerates the contents (EU/Euro-area/member states, presets, groups, translations). It also names the specific query fields it supports, distinguishing it from the many analytics-focused 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 gives explicit usage guidance: 'Use this to find valid values for the reporter, partner_set, partners and reporter_members fields used throughout the other tools' query argument.' This clearly indicates when to use the tool, though it does not mention when not to use it or name direct 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?

With no annotations, the description must carry the burden of behavioral disclosure. It adds valuable context by stating the coverage is 'actually cached,' implying the tool reads cache state rather than computing theoretical ranges. It also discloses the specific field names and format. However, it doesn't address error handling or edge cases (e.g., invalid product codes), but for a simple read operation 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 one sentence, front-loaded with the core action. It packs purpose, return format, and a usage hint into a single, well-structured line without any unnecessary words. The dash nicely separates the main behavior from the practical recommendation.

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

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

Given the tool's simplicity (one optional parameter, no nested objects, output schema present), the description fully covers the necessary context. It explains the tool's purpose, return values, and when to use it, including the consequence of not using it (empty window). There are no significant gaps for an agent to invoke it correctly.

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

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

The input schema already provides 100% coverage of the single 'products' parameter with a clear description ('CN code(s) to check coverage for. Omit for the overall store range.'). The tool description adds no parameter-specific semantics beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states a specific action: returning the period coverage (data_min/data_max) actually cached for given product codes. It includes the return format ('YYYY-MM') and explicitly distinguishes this as a data availability check, differentiating it from the many data-retrieval 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 gives explicit when-to-use guidance: 'use before picking period_start/period_end so you don't request an empty window.' This tells the agent exactly when to invoke this tool and provides a rationale. It effectively communicates the prerequisite context without needing to mention 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It does disclose a key non-obvious behavior: values above 100% are legitimate and not clamped, with reasons. However, it omits other behavioral aspects such as error handling, data availability caveats, or any required authentication, leaving some uncertainty about the tool's full 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 compact and well-structured: a definition, a critical nuance, and a list of return contents. Each of the three sentences earns its place without redundancy or fluff. It is front-loaded with the core concept.

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 rich input schema and presence of an output schema cover most technical details, and the description adds valuable context (non-clamping, return contents). The only minor gap is the statement 'annual' which could mislead agents about the configurable frequency parameter, but the schema clarifies this. Overall, it is sufficiently complete for a well-specified tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond what the schema already provides; it only indirectly hints at product code resolution. Since the schema fully documents every parameter, the description's lack of parameter detail is acceptable.

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

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

The description precisely defines the metric ('Export Propensity = Exports / Production, annual') and explicitly states the deliverable ('Returns the export-propensity matrix') with a clear verb and resource. It also highlights the non-clamping behavior, which distinguishes it from simpler ratio tools. This makes the tool's purpose 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 gives no guidance on when to choose this tool over siblings like get_net_import_reliance or get_trade_intensity. There is no mention of suitable scenarios, exclusions, or alternatives. The only implied usage is 'use it when you need export propensity,' which is not sufficient 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 the full burden. It discloses the composite nature, the guarantee about identical `query` across sections, and warns users never to construct `https://tradedashboard.eu/...` URLs but to use the provided `links`. It also states the response shape. It does not discuss auth, rate limits, or error conditions, but for a read-only aggregation tool with this level of detail, it is quite 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?

The description is longer than a one-liner but every sentence carries meaningful information: the composite purpose, the consistency guarantee, the defaults rationale, override guidance, and return format. It is well-structured with a clear flow from purpose to usage to output. Although it could be tightened slightly, it remains efficient for the complexity it covers.

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, 2 top-level params, many subfields) and the presence of an output schema, the description is complete. It tells the agent when to invoke this composite tool, what the response structure looks like, and critical caveats (link construction, shared query). The output schema presumably details individual section contents, so the description doesn't need to repeat that. It fully supports correct selection and invocation.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that `query` is the same request body used across all endpoints, that its defaults are sensible for a first-cut report, and that only `product` is required. It also clarifies that all five sections share the identical `query` slice, which is not obvious from the schema alone. This exceeds baseline without duplicating field-level details already in the schema.

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

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

The description opens with a specific verb+resource: "Fetch every report section ... for one shared `query` in a single call" and immediately distinguishes itself from sibling tools by naming them (`get_product_profile` / `get_market_summary` / ...) and explaining the alternative. This clearly tells an agent what the tool does and how it differs from closely related endpoints.

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

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

It explicitly states when to use this tool: "instead of calling ... separately yourself" and provides a strong reason (guarantee of consistent slice, avoiding re-typing differences or forgetting a section). It also explains when to override default query parameters (for a different slice) and notes that defaults are sensible for a first-cut report. This is excellent guidance with explicit 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It honestly states the output shape (aggregates keyed by GISCO code) but does not disclose other behavioral traits such as whether the operation is read-only, pagination, error handling, or any rate limits. Since it is a data retrieval tool, the lack of safety warnings is not a major issue, but the description provides limited transparency beyond the output 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?

The description is a single, tightly-worded sentence that front-loads the core purpose ('Choropleth-ready aggregates') and adds the key qualifiers (per-period totals, import/export, GISCO codes, reporter/partner sides). No filler or redundant information. It earns its place by being direct and 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?

Given the tool's complexity (a nested query object with many parameters) and the existence of an output schema, the description provides the essential 'what' but not the 'when' or 'why' for using this tool. It does not explain the typical use case (e.g., generating a choropleth map) beyond the label 'Choropleth-ready', and it lacks information on how this differs from other map-related tools. The output schema likely covers return values, but the description could be more complete in guiding an agent on when to select this 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%, as every parameter (including nested ones) has a detailed description inside the input schema. The description does not add extra parameter-level meaning, but it does provide high-level context by noting the tool returns aggregates keyed by GISCO country code. Per the rubric, a baseline of 3 is appropriate when schema covers all 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 the tool's function: 'Choropleth-ready aggregates: per-period totals (quantity, value, price) for imports and exports, keyed by GISCO country code on both the reporter and partner sides.' This is a specific verb+resource (provides choropleth-ready aggregates) and names the key output dimensions (per-period totals, GISCO codes, reporter/partner sides), distinguishing it from sibling tools like get_concentration_map which likely serve different map-related 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 is provided on when to use this tool versus alternatives. It does not mention any context for use, exclusions, or compare with nearby sibling tools. The only implicit signal is the name 'get_map_data', which suggests map-related use, but the description lacks explicit when-to-use or when-not-to-use direction.

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 of behavioral disclosure. It openly states that the three sources are independent, that specialisation RSCA is trade-based and unrelated to PRODCOM production figures, that lists are pre-sorted and should be used as-is, and that prodcom_code is passed through untouched with ambiguity left to the caller. It does not mention authorization, rate limits, or failure modes, but for a combinational read helper, the behavioral caveats and composition logic are well disclosed.

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?

Though the description is long, it is densely packed with essential information: purpose, alternatives, independence warning, data handling quirks, and return shape. Every sentence contributes new value, and the structure is logical (what it combines, how to interpret, what to do with ambiguous mappings, what it returns). The length is justified by the complexity of the behavior.

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 is complex (combines three independent sources with caveats), but the description covers the composition, the key behavioral warnings, the prodcom pass-through policy, and the return envelope. An output schema is present, so the description does not need to detail every return field, yet it still mentions the main parts (narrative_facts, chart_data, available, reason). For a contextual aggregation helper, this is 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%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining that prodcom_code is passed through untouched and that ambiguous mappings are never guessed here, and by specifying how the query object is shared across endpoints. It also clarifies that the top-8-by-value breakdown appears as chart_data, which gives extra context to the n_top and output structure. This exceeds 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 identifies the tool as a report-section helper that combines three named data sources (get_specialisation, get_concentration, get_production_series) into a unified 'Market structure' output. It distinguishes itself from siblings by explicitly naming the underlying tools and explaining how they are bundled, making the purpose unambiguous and differentiating it from alternatives like get_market_summary or get_overview.

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

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

The description explicitly states when to use this tool (as a 'Report-section helper' for the 'Market structure' section) and names the alternative tools it aggregates, even noting they are independent and should be treated as separate findings. It also gives specific guidance on prodcom_code handling, telling the caller to resolve ambiguities rather than having the tool guess. This is strong 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?

With no annotations, the description carries the full burden of behavioral disclosure. It explains that every figure reflects the query exactly as given, that NIR is normalized to 'year' regardless of the requested frequency, and that NIR is omitted if the product lacks a PRODCOM mapping. It also fully describes the return structure, which is comprehensive 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 longer than average but well-structured: it opens with the core purpose, then gives usage guidance, and finishes with a detailed return-structure breakdown. Each section adds value, and the bullet-style list under narrative_facts is readable. It could be slightly trimmed without losing information, but it is far from bloated.

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 the tool's complexity (nested query, multiple output components), the description is complete: it covers purpose, usage, behavioral nuances (NIR normalization/omission), return fields, and how to adjust parameters. It even explains the tool's relationship to sibling tools. An agent has everything needed to select and invoke it correctly.

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

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

The schema already documents all parameters at 100% coverage, so the baseline is 3. However, the description adds practical, tool-specific semantics: it recommends setting query.frequency to 'year' for multi-year summaries and explains that changing query.partner_set is the way to contrast different partner groups. These are meaningful usage insights beyond the schema's generic field 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's function as a 'Report-section helper' that produces a 'condensed, report-ready digest of how a market has evolved', and it explicitly differentiates itself from the siblings get_overview, get_reporter_detail, get_concentration, and get_net_import_reliance by saying it replaces the need to call them separately. It is a 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 gives clear when-to-use guidance: for the 'General overview' report section, and recommends setting query.frequency to 'year' for multi-year evolution. It also provides an alternative usage path by telling the agent to call again with a different query.partner_set for different slices, explicitly stating it does not substitute a different reporter/partner_set. This is more than a generic usage context.

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 transparency burden and does well: it discloses the formula, the meaning of negative values, the data sources (PRODCOM and Comext), the non-1:1 CN-to-PRODCOM mapping caveat, and where to find availability notes. It does not mention rate limits or pagination, but for a data-returning tool this is a solid level of behavioral disclosure.

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

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

The description is front-loaded with the formula and interpretation, then lists outputs and the key mapping caveat. It is somewhat dense and long, but every clause adds value and no words are wasted, making it appropriately concise for the complexity of the tool.

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

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

Given the complexity of the nested query object and the presence of an output schema, the description effectively covers the core purpose, the metric's interpretation, key caveats, and the parameter that resolves mapping ambiguity. It leaves out no critical information needed for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds useful guidance about the role of query.prodcom_code in pinning mappings, but it does not substantially expand on parameter semantics beyond what the schema provides, keeping this at the baseline.

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

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

The description clearly states the tool calculates and returns Net Import Reliance with the explicit formula and a concrete interpretation example, making it distinct from sibling analytics tools. It also enumerates the specific outputs: NIR % series, supply/disposition components, comparisons, resolved PRODCOM codes, and availability notes.

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 implied context for when to use this tool by explaining the NIR metric and its interpretation, and it gives a concrete instruction to use query.prodcom_code for ambiguous mappings. However, it does not explicitly contrast with alternatives or state when not to use it, leaving some usage ambiguity among the many sibling 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 carries the full transparency burden. It discloses that the tool returns aggregate headline figures and a top-partner breakdown, but does not mention the multi-tab structure (e.g., Pattern Shifts, Cross-section views) hinted at in the parameter descriptions, nor any data-volume or performance characteristics. It is not misleading, but lacks depth.

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 consists of two concise, front-loaded sentences. The first states what the tool does, and the second gives a clear usage recommendation. No unnecessary words or repetition.

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

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

Given that an output schema exists, the description need not explain return values. It adequately explains the tool's role as an entry-point overview for a product/reporter slice. The multi-tab complexity is covered by the parameter descriptions, so the description is complete enough for its purpose.

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

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

Schema description coverage is 100%, with all parameters thoroughly documented in the input schema. The description does not add new parameter semantics but reinforces the tool's focus on headline figures and top-partner breakdown, which aligns with period and n_top. Per rubric, 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 identifies the tool as returning headline trade figures (import/export quantities, values, weighted-average prices, trade balance, top-partner breakdown). It explicitly distinguishes itself as 'the best first call for any new product/reporter slice,' setting it apart from more specialized 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 best first call for any new product/reporter slice' is an explicit usage recommendation, indicating when to use this tool before diving into more detailed analyses. However, it does not name specific alternative tools or provide explicit when-not-to-use guidance, so it's slightly below perfect.

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 transparency burden. It does disclose that rankings are provided by both quantity and value, and that an optional 'Other' bucket exists. However, it does not mention any limitations, data handling specifics, or what happens with missing data or how the top-N is determined (though n_top parameter is in the schema). It is adequate but not rich.

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 sentence that is information-dense and well-organized, starting with the core purpose and then elaborating on specifics. It avoids fluff but could benefit from a more structured breakdown of key behaviors. Still, it is appropriately sized.

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

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

The tool is complex with many parameters and an output schema, but the description only provides a high-level overview. It does not mention the various tabs or cross-section views, which are likely important for distinguishing results. The input schema carries much of the detail, but the description alone leaves gaps 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?

Input schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The tool description adds minimal extra semantic value by mentioning 'top-N' and 'Other' bucket, which map to 'n_top' and 'include_other' parameters, but it does not explain any parameter behavior beyond what the schema already states.

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

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

The description clearly states it provides a per-partner import/export breakdown with top-N rankings and time series, which distinguishes it from sibling tools dealing with aggregates or other breakdowns. It uses a specific verb-like noun phrase and lists concrete output elements. However, it does not explicitly differentiate itself from similar tools like get_top_entities or get_reporter_detail.

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 any exclusions, prerequisites, or comparisons with sibling tools. The only implicit clue is 'Per-partner' which hints at its specific focus, but this is not 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?

With no annotations, the description carries the full burden. It discloses the before/after comparison logic and the meaning of each quadrant, which is essential behavioral detail. It does not mention limitations or data requirements, but the output schema and full parameter descriptions mitigate this.

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 dense sentences with no redundancy. It front-loads the core purpose and follows up with a practical workflow, making every part earn 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?

Given the tool's complexity, the output schema, and full parameter descriptions, the description covers the essential gaps: what the tool does, how to interpret results, and how it relates to sibling tools. It is complete enough for an agent to select and invoke 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 top-level parameters, and query subfields all have descriptions, so the baseline is 3. The description adds value by explicitly explaining that query.midpoint is the split point and how it fits into the workflow, which goes beyond the schema's field description.

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

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

The description clearly states a specific verb ('compares') and resource ('average quantity and price before vs. after') and defines the output (scatter points with quadrant labels). It distinguishes itself from siblings by framing it as a post-shock analysis step, not a shock detector.

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 'Suggested workflow' explicitly tells the agent to use get_supply_shocks/get_price_shocks first and then set the shock date as query.midpoint. This gives clear when-to-use context, though it does not explicitly list alternative tools to avoid.

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 burden. It discloses the output structure (timeline phases, magnitude, series) and the methodology (volatility adjustment), which adds transparency. However, it does not mention any prerequisites, limitations, or edge cases, leaving some behavioral aspects unspecified. No contradiction with annotations since none 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-loaded with the primary action ('Detect sudden price regime shifts') and every clause adds value. It explains the algorithm's intent and the return format without 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 tool with 8 top-level parameters, nested query objects, and an output schema, the description provides sufficient context about the tool's core function and typical outputs. It clearly states what shocks are detected and the output components. It lacks explicit differentiation from similar tools, but the purpose is clear enough given the high schema coverage.

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

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

Schema description coverage is 100%, so the baseline is 3. The description itself does not add parameter-level semantics beyond what the schema already provides. It mentions flow volatility and shock detection in general terms, but does not elaborate on specific parameters like lookback_years or min_abnormality.

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' and names the resource 'sudden price regime shifts', clearly distinguishing this from sibling tools like get_supply_shocks (supply shocks) and get_volatility (general volatility). It also explains the methodology and expected output, making the purpose 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 abnormal price movements by mentioning volatility adjustment, but it does not explicitly state when to use this tool over alternatives or provide exclusions/alternatives. No comparison to get_supply_shocks or get_volatility is given, so guidance is only implicit.

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 of disclosing behavior. It explains expansion into children, direct comparison for multi-code requests, per-subcode series for both flows, and the leaf flag. While it does not mention potential response size limits or error conditions, the key behavioral aspects are clearly disclosed.

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 compact two-sentence text with no filler. It front-loads the core concept and uses every clause to convey meaningful information. The structure makes it easy for an agent to quickly grasp the tool's unique functionality.

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 query object and the presence of an output schema, the description covers the essential distinguishing behavior (sub-product expansion, multi-code handling, leaf response). It does not need to explain return values because an output schema exists. The description sufficiently equips an agent to select and invoke the tool correctly.

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

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

The schema provides 100% parameter coverage with rich descriptions, so the baseline is 3. The description adds value by clarifying how the 'product' parameter is interpreted—single parent codes expand into children, while multi-code lists are compared directly—which is not explicit in the schema. This enhances the semantic understanding beyond the schema alone.

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

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

The description opens with 'Sub-product comparison', which precisely names the tool's purpose. It clearly states that it expands a parent CN code into children and returns per-subcode quantity/value/price series for both flows, distinguishing it from aggregated views. The leaf-case behavior is also specified, leaving no ambiguity about the tool's function.

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 a breakdown by sub-product is desired rather than aggregation, as indicated by 'instead of being aggregated away'. It also clarifies the handling of multi-code requests. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, which would make it even stronger.

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 burden of disclosing behavior. It notes that suppressed/absent country figures return as null rather than zero, which is important for interpretation. It also clarifies the country scope, but does not mention return structures or error cases; the output schema likely covers the former.

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 tool's core purpose, followed by useful specifics (null handling and parameter hint). 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 rich schema and output schema, the description provides sufficient context for an agent to select and invoke the tool: it states the purpose, scope, a key data behavior, and a param-specific hint. It does not explicitly contrast with sibling concentration tools, but the production focus is clear.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds targeted guidance for `query.prodcom_code` (pinning a specific PRODCOM mapping) but does not elaborate on other parameters, which are already well described in the schema.

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

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

The description clearly states the tool measures production concentration (HHI of PRODVAL) across countries over time, plus country production shares. It explicitly mentions the specific dataset (DS-059358), distinguishes it from trade concentration tools by focusing on production, and clarifies the geographic 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 provides clear context on what the tool covers (production across all reporting countries) and offers a specific usage hint for `query.prodcom_code`. However, it does not explicitly name sibling tools or state when not to use it, which would make the guidance stronger.

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 transparency burden and does valuable work: it discloses that country-level figures are 'heavily confidentiality-suppressed' and that suppressed/absent values return as null, not zero. It also clarifies the reporter scope (all DS-059358 reporters, not just EU-27). This goes beyond the schema, though it doesn't cover all possible edge cases like aggregation defaults or response 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?

The description is three sentences, each earning its place: scope definition, data-quality caveat, and a parameter hint. It is well-front-loaded and avoids fluff or restating the tool name.

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

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

Given the tool's complexity and the presence of an output schema, the description covers the key contextual elements: the exact series returned, the reporting-country scope, null-handling behavior, and a conditional parameter usage tip. It is sufficient for an agent to understand what this tool produces and how to invoke it correctly without consulting additional sources.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter meaning: it reiterates the `prodcom_code` use case ('pin a specific PRODCOM mapping') which is already in the schema, and mentions the query object is shared across endpoints, but provides no new syntax or value constraints 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 opens with a specific verb+resource+scope: 'EU27 and per-country PRODCOM production series' and enumerates the exact series returned (EU quantity, EU production unit value, and per-country equivalents). It distinguishes itself from sibling tools like get_production_concentration by focusing on time series rather than concentration metrics.

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

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

Usage context is clear: production data is described as carrying no trade columns, implying this tool is for production-only queries. It also gives a parameter-specific when-to-use hint for `prodcom_code`. However, it does not explicitly contrast with sibling tools or state when NOT to use it, so it stops short of full usage-exclusion 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 provided, the description carries the burden and does well: it discloses the specific output fields (narrative_facts, chart_data, available, reason), the conditional has_subcodes caveat, the cached data window, and the PRODCOM gating behavior. It also sets expectations by stating the tool is deliberately thin. It doesn't address error cases or performance, but for a read-only report helper this is solid.

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

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

The description is extremely compact—two sentences—yet packs in the tool's purpose, scope, exclusions, return shape, and a cross-reference to a sibling convention. No wasted words, and the most important information (what it does) 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 existence of an output schema, the description doesn't need to detail return fields, and it wisely points to get_market_summary for the shape convention. It covers the essential context: what data it provides, what it omits, and how it fits into the report-section helper family. It could have added a brief note on failure scenarios, but available/reason are mentioned, making it reasonably 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% for both parameters (lang and query), with rich field-level details inside the query object. The description adds no additional parameter-specific meaning beyond pointing out that the query is the same request body all endpoint endpoints take, which is useful context but not a semantic enhancement. Baseline 3 is appropriate when 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 states this is a report-section helper for 'Scope & definitions' and enumerates precisely what it returns: resolved product code/label, sub-code bundling caveat, cached data-coverage window, and PRODCOM mapping availability. It also distinguishes itself by explicitly noting what it deliberately omits (no full CN hierarchy or sibling enumeration), setting it apart from sibling tools like get_subtree and get_chapters.

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

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

The description provides clear context: it's a report-section helper meant for the 'Scope & definitions' section, and says it is 'deliberately thin' and excludes full CN hierarchy/sibling enumeration, implying when not to use it. However, it doesn't explicitly name alternative tools for those excluded capabilities, so it falls short of full when-not/alternative 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 the full burden. It discloses the output structure (single-year snapshot, benchmark price time series, weighted average, min/max envelope, selected reporter's own line) and the reporter resolution logic (whole EU by default, narrower when `query.reporter` is an aggregate). It doesn't mention side effects or safety guarantees, but for a read-only query tool this level of detail is strong.

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 but front-loaded with the core purpose and the sibling differentiation. Every sentence adds information about output structure or reporter behavior. It's slightly long, but the complexity of the tool justifies it; no waste or repetition.

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 purpose, what it returns, reporter resolution nuances, and its relationship to a sibling tool. An output schema exists, so the description doesn't need to enumerate return values. It omits details like pagination or limits, but given the rich schema and output schema, this is adequate and well-rounded.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how the `reporter` parameter affects the benchmark computation (resolves to whole EU, aggregate, or single member state), which is not obvious from the schema alone. This enriches the semantics of a key parameter beyond its formal definition.

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

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

The description opens with a specific verb+resource+scope: "Every EU reporter ranked by value for one year," clearly stating the tool's function. It also differentiates from the sibling `get_reporter_detail` by calling itself "the country-view counterpart," which frames its distinct role in the tool family.

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 states when to use it: "Use it to answer 'how does this country -- or reporter group -- compare to every other reporter?'" It also names the alternative `get_reporter_detail` as a counterpart, giving clear contextual guidance. However, it does not explicitly state when NOT to use it (e.g., if you need the same reporter across time), so a missed exclusion prevents 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 provided, the description carries the full burden of behavioral disclosure. It discloses that aggregate reporters (EU, Euro area, groups) are excluded from the ranking, which is a non-obvious behavior. However, it does not explicitly state any safety characteristics (e.g., read-only) or mention rate limits, pagination, or side effects. The disclosure is partial, adding some value but leaving 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 two sentences, front-loaded with the core purpose and the counterpart relationship. Every phrase carries meaning: the breakdown scope, the counterpart, the ranking criteria, and the exclusion of aggregates. There is no redundancy or fluff, making it highly concise and well-structured.

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

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

The tool has a complex nested query object and a rich output schema, so the description does not need to explain return values. It provides a high-level overview, the key distinction from a sibling tool, and a behavioral exclusion, which is sufficient for an agent to select and invoke it. It could mention the various tabs (Pattern Shifts, Cross-section, etc.) or the `compact` parameter, but the schema already covers those details. Overall, it is complete enough given the surrounding 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 description coverage is 100%, and the parameter descriptions in the schema are extremely detailed (e.g., product accepts CN codes or TOTAL, n_top controls top entities, compact condenses series). The tool description itself references 'Top-N member states' which aligns with the `n_top` parameter, adding a slight linkage. However, the description does not need to repeat parameter details; it provides minimal additional value beyond the schema, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'import/export breakdown' per EU member state, with top-N member states ranked by quantity and value. It explicitly names the sibling tool `get_partner_detail` as the counterpart, which distinguishes it from other siblings. The scope (reporter-side vs partner-side) is clear, and the exclusion of aggregate reporters is an additional clarifying detail.

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

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

The description provides clear context by naming `get_partner_detail` as the counterpart, implying usage when a reporter-side breakdown is needed versus a partner-side one. It does not explicitly state when not to use it, but the exclusion of aggregate reporters hints at a limitation. It lacks exhaustive alternatives or exclusion criteria, but the core usage context is present.

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 output range (-1 to +1), the intra-EU-only limitation, the value-based methodology, and a specific data-quality caveat (Rotterdam/Antwerp effect). This is substantial behavioral transparency for a data-query tool, though it does not cover edge cases like empty results or handling of missing data.

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

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

The description is three sentences: first states the core purpose, then the scale and scope, then a caution. Every sentence contributes unique information without redundancy, making it concise and well-structured.

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

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

Given the complexity of the nested query object and the presence of an output schema, the description provides sufficient conceptual context (RSCA, intra-EU, caution) without needing to restate parameter details. It could mention the relationship to sibling endpoints or emphasize that 'product' is required, but the schema already covers that. Overall, it is complete for the tool's purpose.

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

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

The input schema provides 100% coverage of all parameters, including the nested query object with detailed field descriptions. The tool description adds no parameter-specific insight, relying entirely on the schema. Since the schema is exhaustive, a 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 states a specific verb+resource: it computes intra-EU revealed symmetric comparative advantage (RSCA) per member state, explicitly distinguishing itself from world-benchmarked indices and other sibling tools. The scope (intra-EU, value-based) and the -1 to +1 scale make the purpose unmistakable.

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 clear context for when to use this tool: to measure comparative advantage within the EU, with a note about intra-EU distortion. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of the most explicit 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 the full burden. It discloses the return components (intensity, component series, quality status, PRODCOM codes, notes) and the key data limitation that the own/sub split only exists from 2021 onward. This is meaningful behavioral context, though it does not cover auth, rate limits, or side effects (which are likely minimal).

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 concise sentences, front-loaded with the metric definition and followed by return components and a caveat. Every sentence adds value with no redundant filler.

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

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

The description effectively explains what the tool measures, what it returns, and an important temporal constraint (2021 onward). Given that an output schema exists, it does not need to detail return structures. This is complete for a specialized data-query tool, though it could briefly mention how to invoke it (e.g., that it uses the standard query object).

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

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

Schema description coverage is 100%, so the baseline is 3. The tool description does not add parameter-specific meaning; it only mentions PRODCOM codes as an output, not as an input. The schema itself thoroughly documents the query object and compact parameter, so the description does not need to compensate.

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 EU27 sub-contracting intensity, its components (value/quantity, quality status, PRODCOM codes, availability notes), and distinguishes it from siblings by its unique metric. The verb 'returns' and the specific resource make the purpose unambiguous.

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

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

Usage is implied: use this tool when you need sub-contracting intensity data. However, there is no explicit mention of when to use it over alternatives like get_subcontracting_members, nor any exclusions. The description offers no direct guidance on choosing between similar 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?

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that country cells are heavily confidentiality-suppressed and that missing values are null, not zero, and that reporters not reporting the split simply do not appear. This adds meaningful behavioral context beyond the basic 'get' semantics.

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 compact sentences with no wasted words. The first sentence states the core metric, the second clarifies the scope, and the third covers a key data quality behavior. 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?

The description covers the essential context: the metric itself, the universe of reporters, and the confidentiality suppression behavior. Since an output schema exists and the description is concise, it is complete enough for an agent to invoke appropriately. A minor enhancement could be more explicit linkage to the PRODCOM dataset, but it is already mentioned.

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 input schema already documents all parameters thoroughly. The tool description does not duplicate or enhance parameter explanations, but given the rich schema, the baseline of 3 is appropriate. No parameter semantics are lost.

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 tool's output: per-country sub-contracting intensity, measured as the share of sold production that is toll manufacturing. It also differentiates from sibling tools by emphasizing the per-country, per-reporter perspective and the specific PRODCOM dataset, making it unmistakable what this tool does.

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 you need per-country sub-contracting intensity) and clarifies coverage (only reporters reporting the own/sub split appear). However, it does not explicitly mention alternative tools or provide concrete 'when not to use' guidance, so the usage direction is present but somewhat implicit.

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 burden of disclosing behavior. It does reveal the recursive nature of the response ('its children, and their children, ...') and the content structure ('each with a `code` and a `text` description'). It also adds practical context about verifying the suitability of a heading. It does not mention error handling, depth limits, or rate limits, but for a read-only tree query, the key behavior is well conveyed.

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 long, front-loaded with the primary action, and every clause serves a purpose. There is no fluff or repetition of schema 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 presence of an output schema and 100% schema description coverage, the description need not explain return values or parameter syntax. It provides the essential tree semantics and a practical use case, which is sufficient for an agent to select and invoke the tool appropriately. It could mention potential edge cases, but the overall context is well covered.

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 fully documents both parameters (`code` and `lang`). The description adds some context for `code` by linking it to the use case (checking a heading as `query.product`), but it does not add any meaning for `lang`. Per the rubric, the baseline for high schema coverage is 3, and the marginal addition does not elevate it beyond that.

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 with a specific verb ('Return') and resource ('Combined Nomenclature sub-tree rooted at `code`'), and explicitly describes the recursive structure (children and their children). It also distinguishes itself from siblings by explaining its use case: checking if a heading is a clean match or bundles sub-products.

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 guidance: 'Use this to see whether a heading you're about to use... is actually a clean match...' This gives clear context for invoking the tool. However, it does not explicitly name alternatives or state when not to use it, which keeps it from a perfect 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 provided, the description carries the full burden of disclosing behavior. It details the statistical threshold (>2 sigma by default), the output structure (ranked shock events with timeline phases, magnitude, abnormality score, and underlying series). This goes beyond a simple statement of purpose, though it does not cover limitations or 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 three sentences long, front-loaded with the primary action and resource, followed by key behavioral and output details. Every sentence provides meaningful information with no redundancy or filler, making it appropriately concise and well-structured.

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

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

The tool has a complex input schema (9 parameters, nested objects) and an output schema, both of which carry significant detail. The description provides a clear high-level summary—what it detects, how it measures shocks, and what the response contains, including the notable timeline phases. This is adequate given the richness of the structured metadata.

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 description does not need to explain parameters. The description does not add parameter-specific context beyond what the schema already provides, except for referencing the default sigma threshold which is also captured in the schema. Baseline 3 applies.

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

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

The description clearly states the tool's function with a specific verb ('Detect') and resource ('abnormal collapses in trade volumes'). It further clarifies the exact nature of the collapse (volume drops well below historical average) and distinguishes itself from sibling tools like get_price_shocks by focusing on volume rather than price.

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 the tool is used for detecting supply shocks but does not explicitly state when it should be used over alternatives, nor does it mention any exclusions. While the purpose is clear, the lack of explicit guidance on alternative tools or contexts leaves the usage dimension at a baseline implied level.

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 does disclose key behavioral traits: the response is an 'ordered list' and is not a time series, and the tool is 'lightweight.' Yet it does not explicitly state that the operation is read-only, nor does it mention authorization needs or rate limits. For a no-annotation tool, this is a moderate level of transparency.

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 exactly two sentences, with the primary purpose and key differentiator front-loaded ('ordered list of top entities for a slice -- no time series') and a secondary use case following. Every word earns its place, and it avoids restating schema information.

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

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

For a simple list-fetch tool, the description adequately captures what is returned (ordered list, no time series) and when to use it. The rich input schema and the presence of an output schema cover parameter and return details. It could mention that it uses the same query object as other analytical endpoints, but that is already documented in the schema and not essential for selection.

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

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

The input schema has 100% description coverage, with detailed explanations for all parameters including the nested query object. The description itself adds no parameter-specific meaning beyond referring to 'a slice' and 'top entities,' so it stays at the baseline of relying on the schema for parameter semantics.

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

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

The description clearly states that the tool returns an ordered list of top entities for a given slice, and explicitly notes it does not include a time series. It distinguishes itself by framing the use case as 'populating entity pickers' or 'quickly checking who the top partners/reporters are', which differentiates it from sibling tools that provide full series or detailed reports.

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 clear context for when to use it: 'for populating entity pickers or quickly checking who the top partners/reporters are without pulling full series.' This implies a lightweight alternative to full-series tools. However, it does not explicitly name sibling alternatives or state when not to use it, so it falls just short of full exclusion 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 provided, the description carries the full burden of behavioral disclosure. It explains what the tool computes, how to interpret the metric, and what data it returns (series, components, comparisons, resolved codes, availability notes). This goes well beyond a simple 'get data' statement, though it does not address potential caveats like data availability limitations or request constraints.

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. It opens with the formula and interpretation, then gives the purpose context, and closes with the return contents. Every sentence contributes useful information with no redundancy or 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 rich input schema and the presence of an output schema, the description is complete enough. It explains not only what the tool does but also why it matters (CEEAG methodology) and what components to expect in the result, enabling an agent to select and invoke it appropriately among many 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?

The input schema provides 100% coverage with detailed descriptions for every parameter. The description adds context about the metric's components (imports, exports, production) but does not add specific parameter-level semantics beyond what the schema already documents. Therefore, the baseline of 3 applies.

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

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

The description clearly states the tool's function: it returns Trade Intensity, defined by an explicit formula. It also explains the interpretation (near 1 vs near 0) and the return contents (TI series, components, comparisons, PRODCOM codes, availability notes). This distinguishes it from sibling analytical tools like get_net_import_reliance.

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 context for when the tool is relevant: it is used in the Commission's CEEAG methodology for carbon-leakage/State-aid eligibility. However, it does not explicitly mention alternatives or when not to use this tool, 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 carries the transparency burden and does well: it discloses the exact metric, the data scope ('inactive-period-excluded history'), interpretation, and conditional output based on include_heatmap. It could add more about data source or limitations, but for a read-only analytical tool this is solid.

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

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

The description is three concise sentences, front-loaded with the metric definition and formula, and gives the key output structure without unnecessary padding.

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

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

Given the very rich input and output schemas, the description is sufficient for an agent to understand the core behavior and outputs. It does not need to restate parameter details, and the output schema covers return values.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context for include_heatmap (bar-only vs. heatmap) and entity level, but it does not explain other parameters 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 defines the tool as computing coefficient-of-variation volatility per partner/reporter x product pair, with a specific formula (CV = stdev / mean). This distinguishes it from sibling tools like get_volatility_summary, which presumably provides a more aggregated view.

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 you need CV volatility breakdowns across entities and sub-products. However, it does not explicitly state alternatives or exclusions, such as when to prefer get_volatility_summary or get_concentration instead.

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

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

With no annotations provided, the description fully carries the behavioral burden. It discloses the retry mechanism for shock detection, explains that an empty result is a reportable finding rather than a gap, describes how findings are prioritized, and mentions the intentional exclusion of `get_pattern_shift`. This is rich, honest behavioral disclosure.

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

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

Although the description is relatively long, every sentence earns its place by conveying critical behavioral and relational context that is not available from annotations or the schema. It is front-loaded with the tool's role and well-organized into logical clauses.

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 absence of annotations and the presence of an output schema, the description thoroughly covers the tool's dependencies, retry behavior, reporting semantics, and return shape. It is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

The single `query` parameter is fully documented by the input schema (100% coverage), including defaults and semantics for each nested field. The description adds no parameter-specific detail beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description clearly identifies the tool as a report-section helper for "Volatility & shocks" and explains that it aggregates findings from `get_volatility`, `get_price_shocks`, and `get_supply_shocks`. It also differentiates itself from `get_pattern_shift`, making its purpose and scope unambiguous.

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

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

Explicit guidance is provided: the tool is a helper used at default parameters, entities are never re-picked from shock results, and `get_pattern_shift` is intentionally excluded from the bundle with a note to call it directly if needed. This clarifies when to use this tool versus 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 provided, the description carries the full burden. It discloses what the tool returns (workflow, dashboard menu, methodology notes) and its role as an entry point ('Read this first'). It does not mention side effects (none expected) or exhaustive edge cases, but for a read-only guidance tool, it provides sufficient 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 two sentences, front-loaded with 'Read this first.' It packs substantial detail into the second sentence without redundancy. Every phrase earns its place by listing specific content areas and the intended usage timing.

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

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

The description fully covers what an agent needs to know: when to call it, what it returns (workflow per angle, dashboard structure, methodology), and that it should precede tool selection. It complements the output schema without repeating schema details. For a zero-parameter tool, this is 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 tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter details, but none are needed since the schema is empty and 100% covered.

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

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

The description clearly states the tool's purpose: 'Returns the long-report workflow' with specific details about what it contains (tool combinations, dashboard structure, methodology). It identifies the resource as 'long-report' which distinguishes it from the sibling tool 'guidelines_for_a_short_report' and other report 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 gives clear usage guidance: 'Read this first for an in-depth report' and 'Call this before guessing at tool use.' This explicitly tells the agent when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, though the sibling name implies the short-report 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 the full burden. It discloses what the tool returns (the workflow), what it covers (access/quota, shared query object, compact option), and gives a concrete step-by-step ('resolve a product code, then call get_full_report'). This is transparent about its informational nature, though it doesn't explicitly state read-only semantics.

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 just two sentences, front-loaded with the most actionable 'Read this first for a quick report', followed by a compact summary of contents. 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?

For a guidelines tool with no parameters and an output schema, the description covers the essential workflow, the key sub-step (calling get_full_report), and the additional topics (access/quota, query object, compact option). It is sufficient for an agent to understand when and why to invoke it.

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

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

The tool has zero parameters, so the baseline is 4. The schema is empty, and the description adds no conflict or extra parameter info; the baseline applies.

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

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

The description clearly states the tool's purpose: 'Read this first for a quick report' and 'Returns the short-report workflow'. It specifies the resource (short-report workflow) and distinguishes itself from the sibling 'guidelines_for_a_long_report' by the 'short-report' qualifier.

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 opening line 'Read this first for a quick report' provides a clear when-to-use instruction. It implies this is for quick reports rather than long ones, though it does not explicitly mention the alternative 'guidelines_for_a_long_report'.

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 of behavioral disclosure, and it excels: it explains the tool's dual behavior (bare keyword triggers a search; a single code or comma-separated list is validated and described directly), the coarseness of CN nomenclature, and the effect of `include_children`. It also flags the importance of inspecting `has_subcodes` before committing to a code, all without needing annotations.

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

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

The description is concise yet complete: the purpose appears in the first sentence, followed by a short explanation of the combined workflow and a focused tip with a practical example. No filler or redundancy; every sentence contributes to either usage or behavioral transparency.

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 (4 parameters, dual input modes) and the presence of an output schema, the description covers all essential aspects: input handling, behavior for different query types, and guidance on subtree exploration. It is fully adequate for an AI agent to select and invoke the tool correctly, and the output schema handles return-value 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?

The input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds value by clarifying the `query` parameter's dual nature (free-text vs. CN codes) and by giving a concrete example of the coarseness problem for choosing `include_children`. It reinforces the schema's meaning rather than merely repeating it.

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

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

The description opens with a clear, specific action: 'Resolve a free-text query or CN code(s) into validated product code(s) with descriptions.' It also distinguishes this tool from siblings by positioning it as 'the recommended first step before using a code as `product` in any other tool's `query`' and explicitly notes it saves the search → validate → subtree round-trip, differentiating it from search_codes and 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 provides explicit when-to-use guidance: it is the recommended first step for resolving product codes before use in other tools. It also advises checking `has_subcodes` and setting `include_children=true` when a coarser code may not be the best match, giving concrete decision criteria. This goes beyond generic context to actionable 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 discloses the ranked result shape and that results are raw candidates, but does not explicitly state that it is read-only, lacks side effects, or describe error/timeout behavior. It adds some useful context but not deep behavioral disclosure.

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

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

The description is two short paragraphs: first the core purpose, then the return shape and usage guidance. Every sentence earns its place, with no redundant restatement of the tool name or schema.

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

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

Given the rich schema (100% parameter coverage) and the presence of an output schema, the description is complete enough for tool selection and invocation. It also addresses the key ambiguity among siblings by directing the agent to resolve_product_code for a helper path. No important usage aspect is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level detail beyond the schema, but it does reinforce the notion of searching by keyword/code and returning ranked candidates. Since the schema already documents every parameter thoroughly, this is sufficient.

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 ('search') and names the exact resources (Combined Nomenclature, PRODCOM) plus the result shape. It also distinguishes the tool from the sibling resolve_product_code by clarifying which is for a one-call helper vs. this raw 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?

Explicitly tells the agent when to prefer resolve_product_code and when to use this tool directly ('if you specifically want the raw ranked candidate list'). This is clear when/when-not guidance with a named alternative.

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 of behavior disclosure. It clearly explains the dual behavior (single vs. list) and the success/error response structure. It does not mention permissions or rate limits, but for a read-only validation tool, the disclosed behavior 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?

The description is extremely concise, front-loading the purpose in the first sentence and using clear backticked formatting for technical terms. Every sentence contributes necessary information about behavior, making it highly efficient with zero 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 the moderate complexity of handling single vs. list inputs and the presence of an output schema, the description covers the essential behaviors thoroughly. It explains the two return modes and the error pairing. The special 'TOTAL' code is mentioned only in the schema, but that is part of parameter documentation rather than the tool description. Overall, it is complete enough 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?

The schema provides 100% coverage for both parameters, including the comma-separated list and accepted languages. The tool description adds context about how the cardinality of 'code' affects the response format, but this is behavioral rather than parameter-specific. No additional parameter semantics are necessary.

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 with a specific verb ('Validate and describe') and resource ('Combined Nomenclature codes'). It indicates the return of hierarchy levels, product name, and subcode status, which distinguishes it from generic code tools. However, it does not explicitly contrast with sibling tools like resolve_product_code or search_codes.

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 input format guidance (single code vs. comma-separated list) and explains the two response modes, but it does not explicitly state when to use this tool over alternatives. The usage context is implied rather than explicitly contrasted with sibling tools.

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