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

No annotations are provided, so the description carries the full burden, and it does well: it discloses that values are derived, that the LEI field is withheld where the holder may be a natural person, that the registry does not validate LEIs, and that historical years may reflect a prior operator. It omits any note on auth or result size limits, but for a read-only lookup 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?

A single dense paragraph that is front-loaded with the core purpose before the caveats and parameter behavior. Every sentence carries information, though it is packed tightly and could be broken up for scannability.

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 describe returns, and it does: latest verified emissions plus yearly totals for verified emissions, free allocation and surrendered units, with the derived nature flagged. Combined with the data-quality caveats, an agent has what it needs to call and interpret 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 coverage is already 100%, but the description still adds meaning: LEI must be 20 characters with dashes/spaces ignored, detail=true adds each installation's years, and from_year/to_year bound the year range. This goes beyond the schema's terse 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?

States a specific verb+resource: returning all installations whose current Union Registry account holder registered a given LEI, along with their emissions data. The scope is precise and unambiguous. It does not explicitly contrast itself with the sibling search_installations, so it lands at 4 rather than 5.

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

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

Gives genuine usage context: 'no match does not prove the company holds no installation' because only ~a fifth of installations carry an LEI, and earlier years may belong to a previous operator. This tells the agent how to interpret results, though it never names alternative tools (e.g. search_installations) for the case where an LEI lookup fails.

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 full behavioral burden. It thoroughly discloses the returned fields, which is valuable, but omits explicit statements about read-only safety, authentication needs, or side effects. The content itself implies a safe read, but this is not stated.

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 long run-on sentence with many clauses, making it dense and harder to parse. All content is relevant, but a bulleted structure would improve scannability and front-loading.

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

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

Given no output schema, the description comprehensively lists what is returned, covering licence, attribution, withholding rules, and source details. It is nearly complete for a no-parameter info tool, though it could explicitly state that it is a read-only metadata operation.

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 description appropriately does not need to explain any parameter semantics, and the empty schema fully covers the absence of inputs.

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 enumerates the dataset metadata returned (snapshot date, source files, codes, years, units, etc.), which distinguishes it from siblings that query installations or emitters. However, it does not explicitly state 'returns' or 'provides', relying on the 'What the data is:' framing to imply purpose.

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 when-to-use or when-not-to-use guidance is given. The instruction 'Cite the source line of every answer' is a post-processing rule, not a usage condition or alternative-selection cue.

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 load and does so well: it discloses that years without values are omitted and listed in years_without_values, that 0 is ambiguous between zero and nothing entered, that post-coverage emissions are null, that sparse recent years are flagged incomplete, and that compliance codes exist only for registry-offered years (2021-2024 in a stated snapshot). That is unusually rich 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?

A single dense paragraph that is front-loaded with the resource definition before edge-case semantics. Nearly every clause earns its place, though the run-on structure and parenthetical stacking make it heavier 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?

No output schema exists, so the description must describe return values and does: field meanings, the years_without_values companion list, null semantics, the incomplete flag, and compliance-code coverage windows. For a 4-parameter read tool this is complete enough to call 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 already 100%, so baseline is 3, but the description adds real meaning: it explains why country matters (the same id exists in several registries), the DE-69 id format, and the ambiguous-id behavior. from_year/to_year are not elaborated beyond the schema, keeping it from a 5.

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

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

States a specific resource and scope: a year-by-year per-installation record with named fields (verified emissions, free allocation, surrendered units, excluded flag, compliance code). It is clearly distinct from search_installations by being singular and historical, but it never names or contrasts with that sibling, so it stops short of a 5.

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

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

Usage is implied rather than stated: it explains how to disambiguate (pass country or write the id as DE-69) and what happens on ambiguity (returns candidates), but gives no explicit when-to-use-this-vs-search_installations guidance. An agent can infer the intended invocation but must reason about the alternative itself.

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 behavioral burden and does so richly: it discloses the return shape and ordering (largest first), the total-count field, privacy redactions ('[name withheld: possible natural person]', suppressed city/LEI, lei_withheld), the fact that no account-holder names are stored, and that registry text is wrapped as untrusted remote text to defend against prompt injection.

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

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

Front-loaded with the core purpose, and every clause carries information (filters, result fields, ordering, count, privacy, injection wrapping). It is dense and the second half is one very long sentence, which slightly hurts scannability, but little of it is filler.

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

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

For a search tool with no output schema and no annotations, the description is complete: it lists the returned fields, ordering, count semantics, filtering behavior, and privacy handling. An agent has everything needed to call it and interpret results 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 75% and the schema already documents country and activity codes in detail, but the description adds beyond it: query requires all words to match with accents/case ignored, limit defaults to 20 (schema only has min/max), and it restates the activity/country filter semantics. This is more than the schema alone conveys, though it does not fully document every edge case.

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 (Find) and precise resource set (EU ETS installations, aircraft operators, shipping companies in the Union Registry snapshot) plus the search fields. This immediately distinguishes it from siblings like dataset_info, installation_history, company_by_lei and top_emitters, which are lookup/history/ranking tools rather than text search.

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 the search conditions (all words must match, optional country/activity filters) and the schema notes query may be empty when a filter is supplied, which implies usage. However, it never names an alternative sibling or states when NOT to use this tool (e.g. for a single known installation_id or LEI, where company_by_lei or installation_history would be better).

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 and does well: it discloses the default year ('latest year with verified emissions, 2025 in the 2026-09-24 snapshot'), the 1-100 limit with default 10, the fact that derived totals are computed, and that compliance code only exists for 2021-2024. It does not discuss data source freshness limits or permissions, keeping it short of a 5.

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

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

Front-loaded with the core purpose and the default year, then the return fields. The return-field enumeration is long but justified because no output schema exists. Slightly dense but no filler sentences.

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

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

For a filtered ranking tool with no output schema and no annotations, the description covers purpose, defaults, filters, return fields, derived values, and the compliance-code year 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 50% (country and activity documented in schema, year and limit not), so the description must compensate for the gaps – and it does, explaining the year default behavior and the limit range/default. The activity-code hint about passing codes explicitly also adds meaning beyond the schema, though country filtering semantics are left entirely to the schema.

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

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

States a specific verb and resource: installations ranked by verified emissions over a chosen year, with optional country/activity filters. It is clear and distinctive (a ranking, not a general search), but it never names or contrasts with the sibling search_installations, leaving sibling differentiation to inference.

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?

Offers some implied usage context – filters are optional, and 'pass codes explicitly for a wider sector' hints at how to broaden results. However it never states when to prefer this ranking tool over search_installations or installation_history, so the when-to-use guidance remains implicit.

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