Carbonara freight CO2e

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

Annotations already declare readOnly/idempotent/openWorld=false, so the safety profile is covered; the description adds real behavior beyond that, disclosing that it routes each leg from coordinates or codes, that it may add legs ('legs Carbonara added'), and what the per-leg and step-by-step output contains. No contradiction with the read-only annotation since adding legs is internal to the calculation, not a persisted mutation.

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

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

Three sentences, front-loaded with the purpose and standard, then routing behavior, then return shape. The return-value sentence is long but earns its place because there is no output 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?

With no output schema, the description correctly spells out what is returned (per-leg distance, method, data type, emission factor and source, DAF, added legs, and a step-by-step calculation sheet). It covers standards, routing and output adequately; only the when-to-use guidance 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 every parameter is already documented in the schema and the description need not carry that load. The description adds only a light touch ('Routes each leg's distance from its coordinates or codes'), 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?

States a specific verb and resource ('Calculates one shipment's greenhouse gas emissions') and pins the scope with 'one shipment', implicitly separating it from the plural sibling calculate_shipments. It also names the standards (GLEC v3.2, ISO 14083), so the agent knows exactly what computation this is.

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

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

The description explains what the tool computes but never states when to choose it over calculate_shipments, get_methodology or emissions_report, and offers no exclusions or prerequisites. Usage is only implied by the singular scope and the emission-calculation purpose.

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 semantics, but the description adds important non-annotation behavior: one failing shipment does not stop others, and each failure states a reason plus whether resubmission can help. It also scopes explain to the first 25 shipments. It does not mention the API-key-dependent call limits, though those are covered 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?

Three short sentences, front-loaded with the core purpose, then failure behavior, then the explain option. Every sentence contributes information and nothing is repeated or padded.

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?

Covers batch execution, failure isolation, retry guidance, and the explain limit, while the schema supplies full nested parameter documentation and call limits and annotations cover safety. The only gap is that the success/response shape is not described at all, though no output schema exists to rely on either.

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 carries all parameter semantics and the baseline is 3. The description's only additional parameter-adjacent detail is that explain adds calculation sheets for the first 25 shipments, which largely restates the schema's 'up to 25' note. It adds no extra syntax or constraints for the shipments array.

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 ('Calculates several shipments at once'), and explicitly anchors the per-shipment behavior to the sibling calculate_shipment, so the batch-vs-single distinction is clear without opening either schema. The mention of explain further grounds the tool's 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 phrase 'several shipments at once' and the reference to calculate_shipment make the batch use case clear relative to the single-shipment sibling. It also explains when to set explain. However, it never states a when-not condition or explicitly says to use calculate_shipment for a single shipment.

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 cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the description's job is to add context, and it does: it enumerates the report's contents (coverage/failures, TTW vs WTT totals, intensity, data quality shares, DAF adjustments) and states the dual Markdown + structured return. It does not mention the 100/10,000 shipment limits or key requirements, but the schema carries those.

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 verb and the report's scope, then a compact closing sentence on return format. The middle enumeration is long but each item is a real report section, so it earns its place rather than 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?

No output schema exists, so the description must convey return values, and it does by listing the report sections and the two output formats. The remaining gap is operational context (limits, credentials) which is deferred to the schema rather than the description.

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 8 parameters including nested shipment/leg structure, and the description adds no parameter-level detail. Baseline 3 applies when structured fields do 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?

States a specific verb and resource ('Calculates shipments and returns a report') and the title pins the scope to many shipments, so it is distinguishable from the singular calculate_shipment sibling. It stops short of explicitly naming which sibling to prefer, but the aggregate-report framing is 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?

There is no statement of when to use this tool versus calculate_shipment or calculate_shipments, and no exclusions or prerequisites (e.g. API key, dataset requirements) are surfaced in the description. Usage is only weakly implied by the word '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?

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description meaningfully reinforces the closed-world hint by naming the embedded data sources (GeoNames, UN/LOCODE, OurAirports), which explains why results are limited to a fixed catalog. It stops short of describing result ordering or how 'limit' interacts with matching, but adds real context beyond the 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?

A single dense sentence leads with the action and resource set, then the lookup keys, then the intended use case. Every clause earns its place and nothing is padded or repeated.

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 does note that results carry coordinates, and it explains the identifier formats and result kinds an agent will encounter. Missing only minor operational detail (result ordering, how the limit is applied), which is a small gap for a straightforward search 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 all three parameters are already documented in the schema, including the kinds enum values and the identifier formats. The description repeats the identifier formats (UN/LOCODE, IATA) without adding new semantics such as matching rules, partial-name behavior, or default kind filtering, 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 names a specific verb (Finds) and enumerates the exact resources covered: cities, sea/inland ports, rail and road terminals, inland depots, border crossings, airports. It also states the lookup keys (name, UN/LOCODE, IATA) and the data provenance, which cleanly separates it from the calculation-oriented 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?

It gives explicit usage context: "Use it to fill a leg's from and to," which tells the agent exactly when to reach for this tool. There are no overlapping siblings to disambiguate against, so no exclusions are needed, though a note about resolving unknown place names before calculating would make it complete.

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 readOnlyHint, idempotentHint and openWorldHint=false, so safety and determinism are covered. The description adds genuine value by disclosing the full topic inventory the agent will receive, which is the key behavioral fact for a documentation tool with no output 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?

A single sentence, front-loaded with the core purpose followed by a scannable enumeration of covered topics. The enumeration is long but every item is a distinct section the agent may need, so it earns its space; slightly denser than ideal.

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 parameters, no output schema and rich annotations, the description's topic inventory is exactly the missing piece — it tells the agent what content is retrievable, including formulas, datasets, field meanings and presentation guidance. Nothing needed to call it correctly is absent.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly does not waste words on 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 opens with a specific verb and resource ('Explains the whole method') and then enumerates the exact subject matter covered, making it unmistakably a reference/documentation tool rather than a computation. It does not explicitly name a sibling, but the contrast with calculate_shipment and emissions_report is obvious from the content 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?

There is no explicit statement of when to call this versus the calculation tools (e.g. 'consult before interpreting results' or 'call this if you need formula details'). Usage is only implied by the fact that it describes methodology. No exclusions or prerequisites are given.

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 readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds useful interpretive context (what load_factor 1 means, that aliases are returned), but says nothing about result ordering, size limits, or whether the list is exhaustive/static — modest added value over the 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?

A single front-loaded sentence whose colon-delimited list is dense but every clause earns its place, since there is no output schema to carry the return-value detail. Slightly overpacked, but no filler or redundancy.

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

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

With no output schema, the description carries the burden of explaining what comes back, and it does so credibly for a lookup tool (factors, units, distance basis, source/year, aliases, payload semantics). The main omission is any hint about result size, ordering, or how modes partition the list.

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 67%: search and include_fuels carry their own descriptions, while the mode enum has none. The description partially compensates — it clarifies that fuels relate to the fuel method (extending include_fuels' 'Also list fuels and their factors') — but never mentions mode or what filtering by road/rail/sea/air/inland_waterway does. Baseline 3 is fair.

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?

Opens with a specific verb+resource ('Lists the vehicle types') and then enumerates the exact payload — emission factors in g CO2e per tonne-km, tank-to-wheel and well-to-tank, distance basis, source, year, and truck load model. That level of specificity makes it unmistakably a reference/lookup tool, distinct from the sibling calculate_* tools and emissions_report.

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 only implied: the reader infers this is the tool to call before/alongside a calculation to learn which vehicle types and factors exist. The single hint about usage is 'Optionally the fuels for the fuel method,' which gestures at when to set include_fuels but never states when this tool should be preferred over siblings or what preconditions apply.

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