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

With no annotations, the description carries the full burden, and it does add domain context: the results are 'certified' and 'aggregated', and the tool applies FuelEU Annex I rules with Article 2 scope validation. However, it says nothing about whether this is a pure computation or persists state, what permissions are needed, or how validation failures surface, leaving meaningful behavioral gaps for a tool with zero annotation coverage.

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

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

A single front-loaded sentence with no filler; the computed outputs are listed early and the regulatory scope follows. It is dense but every clause earns its place, with only minor loss of readability from packing three output metrics and two regulatory references into one sentence.

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 no-annotation, no-output-schema calculation tool the description usefully names the three output quantities, which partially substitutes for a return schema. Still missing are permission/state assumptions and any indication of how scope-validation failures are reported, so an agent has an incomplete picture of calling behavior.

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 67%, above the 50% baseline, so the schema documents ports, fuels and voyage scope reasonably well. The description adds only the notion of 'multi-leg voyages' (mapping to voyage_legs) and the returned metrics; it contributes no syntax or format detail beyond what the schema already provides, 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?

The description states a specific verb (calculates) and names three concrete output quantities (Well-to-Wake GHG intensity in gCO2eq/MJ, energy consumption in MJ, net compliance balance in tCO2eq) scoped to multi-leg maritime voyages under FuelEU Annex I. This clearly distinguishes it from siblings like calculate_fueleu_maritime_penalty and calculate_maritime_ets_surrender, though it never names an alternative explicitly.

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 when-to-use or when-not-to-use guidance and no mention of sibling tools, so an agent cannot tell from the description alone whether this should be called instead of calculate_fueleu_maritime_penalty or calculate_fueleu_banking_borrowing. The 'Article 2 scope validation' phrase hints at a domain constraint but gives no routing instruction.

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