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

Annotations already cover read-only/idempotent/non-destructive, so the bar is lower. The description adds real behavioral context: the meaning of each status value, that 'ex' lines split codes, that short codes enumerate sub-codes capped by `limit`, and that results are informational, not legally binding.

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

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

Front-loaded and information-dense, but the middle sentence is a long run-on enumerating every return field, and the legal-source parenthetical adds bulk. Every clause carries information, yet the packed structure reduces readability.

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

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

For a single-code lookup with no output schema, the description fully enumerates the returned fields, the status semantics, the 'ex'-line edge case, the short-code sub-code listing, and the de minimis provisions. Nothing an agent needs to invoke or interpret the result 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 both parameters (cn_code format with/without separators, and limit) are fully documented in the schema. The description adds context on how `limit` interacts with short codes but doesn't extend beyond what the schema already states. Baseline 3 applies.

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

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

States a specific verb+resource: determining whether goods under a CN code fall within the EU CBAM scope, citing the exact legal source (Annex I of Reg. 2023/956 as amended). This is clearly distinct from siblings like cn_describe (code description) and compare_origins (origin emission comparisons).

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

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

The description explains what it returns and how to interpret 'partially_in_scope', but never says when to reach for this tool vs siblings like cn_describe or default_value. Usage is implied by the purpose rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior, but the description adds real context beyond them: the full shape of the response, the found=false failure mode for uncovered codes, the other-year diff field, and the non-binding legal caveat with the authoritative source cited.

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

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

Front-loads the returned payload, then coverage limits, then the legal disclaimer. Dense but each sentence carries distinct, actionable information; the disclaimer is arguably the least essential clause but is relevant for a customs 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?

With no output schema, the description fully carries the burden of describing return values and failure semantics, and it also documents the supported-code scope and authoritative-source caveat. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 100% and both parameters (year enum, cn_code format examples) are already fully documented in the schema. The description adds no syntax or semantics beyond what the structured fields provide, so the baseline 3 applies.

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

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

Names a specific resource (CN code description) and enumerates exactly what it returns: label, text, hierarchy, sub-codes, cross-year delta. This is clearly distinct from siblings like compare_origins and cbam_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?

Defines the operative scope precisely: covers chapters 25, 28, 31, 72, 73, 76 and headings 2601/2716, with other codes returning found=false. That effectively tells the agent when this tool will and won't yield data, though it doesn't route to an alternative tool for out-of-scope codes.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds meaningful context beyond annotations: the 30-country cap, inclusion of the 'Other countries and territories' row and Annex IV value, units (tCO2e per tonne), the legal caveat (Excel values not legally binding; the binding source is named), and that provenance/fallback rules are surfaced. It does not describe output format or pagination, but this is a comparison listing, so that gap is modest.

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 sentence packing the 30-cap, special rows, units, legal caveat, and provenance behavior — front-loaded with the core purpose but burdened with parenthetical legal detail that partly competes with the main action. Efficient but somewhat overloaded.

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 two-parameter read-only comparison tool with no output schema, the description supplies the essential domain context: scope (one CN code, several origins), special rows included, units, and the legal non-binding caveat with a pointer to the binding regulation. It does not specify return structure, but the comparison intent is adequately conveyed.

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

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

Schema coverage is 100%, so the schema documents cn_code formats and the countries array with max 30. The description does not restate parameter syntax, but it reinforces the max-30 constraint and clarifies that origins are shown 'side by side', which frames how the countries array is used. Given the high schema coverage, this is above the 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 states a specific verb (compare side by side) and resource (CBAM default values of a CN code across countries of origin). It is reasonably distinguishable from siblings like default_value (single value) and sources, though it does not explicitly name or contrast against those 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?

Usage is implied by the tool's purpose (comparing multiple origins at once, up to 30), but the description never explicitly states when to use this versus default_value for a single origin, nor when-not to use. No exclusions or alternatives are named.

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

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

Annotations already declare readOnly, idempotent and non-destructive, and the description adds substantial behavior beyond them: mark-up is not applied (a separate markup_rule quotes it), EU/Annex III origins return an explanation, unrecognised countries error, and Annex II/III content is deliberately excluded. That is richer disclosure than the safety hints alone.

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

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

Purpose and scope are front-loaded, but the body is a single sprawling paragraph mixing return fields, exclusions, error behavior and legal citations. Every clause is informative, yet the run-on structure makes it harder to scan than it needs to be.

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

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

There is no output schema, so the description carries the return-value burden and does so well: it enumerates direct, indirect and total embedded emissions, production-route letter, fallback values, and precursor handling. Combined with the coverage of error and exclusion cases, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning about the country parameter: it accepts table names, common names, or ISO alpha-2 codes, unrecognised names error rather than fall back, and it names the special sentinel 'Other countries and territories'. This goes beyond the schema's examples.

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

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

States a precise verb+resource pair: CBAM default values for goods under a CN code from a country of origin, and even names the authoritative source (the Commission's Excel). It implicitly separates itself from cbam_scope by noting that a code outside CBAM scope gets no value, but it never names siblings explicitly the way a 5 would.

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

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

Gives concrete routing rules: unrecognised country is an error and never a fallback, third countries not listed should be queried as 'Other countries and territories', EU Member States and Annex III origins get an explanation instead of values, and electricity (2716) is out of scope. An agent knows exactly when this tool applies and what to do in edge cases.

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

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

Annotations already declare read-only, idempotent, closed-world, non-destructive behavior, so the description does not need to restate safety. It adds valuable behavioral context by enumerating the return payload (URL, version, SHA-256, legal status, Official Journal check, CELLAR amendments) and noting the data is 'at the last refresh.'

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

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

It is a single front-loaded sentence that lists the returned provenance fields without filler. The enumeration is dense but appropriate because there is no output schema to carry that information.

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

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

With no output schema, the description must explain the return values, and it does so comprehensively for each bundled dataset. Combined with annotations that cover safety and idempotency, it gives the agent enough to call 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?

There are zero input parameters, so the baseline is 4. The description does not need to explain parameters and correctly focuses on the returned data.

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

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

The description names the resource ('Where the answers come from') and enumerates the exact provenance fields returned for each bundled dataset, so the agent knows it retrieves source/version/licence metadata. It does not explicitly contrast with sibling tools like compare_origins, so it misses the top tier.

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

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

There is no explicit statement of when to use this tool versus alternatives, nor any exclusions. The opening phrase implies provenance lookup, but an agent must infer the use case from the field list.

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