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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint, but the description goes further by disclosing concrete behavioral traits: deterministic arithmetic, no silent guessing on ambiguous UNs, NOT SUBJECT TO ADR and CARRIAGE PROHIBITED handling, rate limits with 429 retry behavior, and the non-legal-advice caveat. This adds substantial 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?

The description is long and dense, but this is a complex tool with multiple edge cases. Each section earns its place: invocation modes, ambiguity handling, scope verdicts, return fields, rate limits, and related tools. It is front-loaded with the core calculation and progressively covers exceptions, though it is not especially concise.

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 what the tool does, when to use it, how to disambiguate inputs, edge cases for not-subject and prohibited carriage, rate limiting behavior, return structure, and limitations. Even with an output schema present, the description provides enough context for an agent to call this tool correctly without additional research.

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 useful parameter-level semantics beyond the schema, such as the precedence of items over un_number/quantity, the meaning of variant_index for concentration bands, and the consequence of omitting a disambiguator. It does repeat some schema detail, but it still enriches the agent's understanding of how parameters interact.

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 precise statement: 'Calculate ADR 1.1.3.6 "small load" exemption points for a dangerous-goods load.' This names the specific regulation, the computation, and the domain. It also distinguishes itself from related tools by naming adr_lookup and adr_lq_eq_check, so an agent can tell them apart.

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 clearly explains how to invoke the tool: single substance via un_number+quantity, mixed load via items[], and that items takes precedence. It also specifies when disambiguation is required, how scope verdicts are handled, and points to adr_lq_eq_check as the alternative for LQ/EQ relief routes. This is explicit and actionable.

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?

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses result caps (50 entries for search, 100 for class filters), NOT_FOUND error behavior, 429 rate-limit handling with retry_after_seconds, and special scope-flagged rows returning packing_group null with not_subject_to_adr/carriage_prohibited. None of this contradicts 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?

The description is organized into clear blocks: purpose, input selection, behavior, returns, limitations, and related tools. It is long, but almost every sentence adds needed operational detail; the in-line return-field enumeration is partly redundant with the output schema but not excessive.

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 input constraints, edge cases, error responses, rate limiting, volume limits, legal disclaimers, and sibling-tool routing. Combined with a high-coverage input schema, rich annotations, and an output schema, an agent has everything needed to decide whether to call this tool and how 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?

The input schema already covers all three parameters, but the description adds selection constraints: exactly one of them, exact-only UN number with normalization examples, name search case-insensitive, and class/division matching. It also flags the leading-zero explosives edge case, which goes well beyond the schema's static 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 leads with a specific verb and resource: 'Look up European road dangerous-goods (ADR 2025) reference data for a substance,' then lists the returned fields. It also explicitly distinguishes the tool from related siblings like adr_lq_eq_check, adr_exemption_calculator, and consignment_calculator.

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 says to provide exactly ONE of un_number, search, or hazard_class and explains which one fits which lookup style. It also names alternatives for adjacent use cases and points to get_subscribe_link for rate-limit relief, so an agent knows when to call this tool versus another.

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 declare readOnlyHint and idempotentHint, and the description does not contradict them; it adds substantial behavioral context: deterministic reference check, per-item status/reason, ambiguous UNs producing blocking_errors and candidates with no verdict, not_subject/not_permitted states, rate limits with 429 retry behavior, and the limitation that packaging/marking/documentation compliance is not assessed.

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 long but proportioned to the domain's complexity. Every section—input requirements, unit families, ambiguous UNs, statuses, return envelope, limitations, related tools—adds necessary information and is front-loaded with the core purpose before expanding into edge cases.

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 a complex tool with an output schema, the description still fully prepares an agent: it covers all input modes, edge cases, status values, overall_status possibilities, error behavior, rate limiting, and operational limitations. Nothing required to select and invoke the tool correctly is left to inference or 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%, but the description compements meaningfully beyond the schema: 'quantity is per INNER packaging, not the whole load'; it explains mass-vs-volume dimension incompatibility leading to inconclusive status; and it clarifies when packing_group or variant_index are needed and when inner_packaging_qty applies in EQ mode.

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: 'Check whether dangerous goods qualify for ADR Limited Quantity (LQ, ADR 3.4) or Excepted Quantity (EQ, ADR 3.5) relief.' It clearly distinguishes itself from sibling tools by pointing to adr_lookup for per-substance values and adr_exemption_calculator for the 1.1.3.6 load-points route.

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 explicit: 'Provide mode ("lq" or "eq") and 1-20 items,' with required fields and units spelled out. It also tells agents when to use related tools instead, and advises 'Send the quantity in the unit given by lq_limit_unit to get a verdict,' plus the adr_exemption_calculator alternative for load-points checks.

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 establish readOnly/idempotent/non-destructive; the description adds concrete behaviors beyond those: fuzzy match quality is surfaced via the envelope's confidence (0-1) and a FUZZY_BEST_MATCH advisory, no-hit queries return count 0 with NO_MATCH instead of an error, a 429 response includes retry_after_seconds, and dataset provenance is flagged as pending verification. That is meaningful transparency for a lookup in a critical logistics 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?

Organized into clearly labeled sections (Behavior, Returns, Limitations, Related) with a front-loaded summary. It is somewhat long, but almost every sentence carries distinct information; the rate-limit guidance could arguably be trimmed, yet it is directly actionable.

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 read-only, 0-required-param lookup with a rich output schema, the description covers input selection, behavior in edge cases, rate limits, return envelope highlights, verification caveats, and related tools. Nothing an agent needs to make a correct first call 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 coverage is 100%, so the schema already documents all five parameters and their formats. The description adds the rank-ordering behavior of query, the AWB prefix definition with '176 = Emirates', and the mutual-exclusion rule (provide exactly one parameter), which is not expressed 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 names a precise action and resource ('Search 6,357 airlines'), lists the search axes, and distinguishes itself from airport_lookup in Related. The airline domain is unmistakable and its scope is fully delimited.

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 says to provide ONE parameter, explains the semantic difference between query (fuzzy ranked search) and iata/icao/prefix/country (exact filters), documents rate limits and a retry path, and points to validate/airport_lookup as alternatives. There is no ambiguity about when to use this tool.

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?

Beyond the annotations, the description discloses important behaviors: exact code hits return one record, ambiguous name searches return ranked candidates with match_quality confidence, unknown codes produce a not-found error, and rate limits with 429/retry_after_seconds/Retry-After behavior are clearly explained. It also backs off recommendation and points to get_subscribe_link for higher limits.

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 long but every sentence earns its place: usage modes, data coverage, behavioral rules, rate limiting, response envelope, limitations, and sibling distinctions. It is front-loaded with the most essential information—lookup methods—and then provides structured depth without 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 is fully complete for a lookup tool of this complexity. It covers input constraints, output shape, error/rate-limit behavior, limitations, and relationships to siblings. Combined with a rich output schema and full annotation coverage, there is no critical missing context 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?

Although schema coverage is 100%, the description adds significant semantic value: it states that iata, icao, and query are mutually exclusive ('Provide ONE of iata, icao, or query'), that type is a narrowing filter, and that query is free-text with minimum length. It also explains ranking behavior based on input choice, which is not captured 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 states a specific action—'Look up an airport'—and clearly enumerates the supported lookup keys (IATA, ICAO, free-text name/city). It differentiates itself from related tools by explicitly naming nearest_airport, airline_lookup, and unlocode_lookup, making its 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 tells the agent exactly when to use this tool and when not: it explicitly says 'Provide ONE of iata, icao, or query' and gives a dedicated 'Related' section contrasting this tool with nearest_airport (coordinate-based lookup), airline_lookup (carrier/AWB search), and unlocode_lookup (general transport locations). This removes ambiguity about alternative selections.

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?

The description goes well beyond the annotations by disclosing determinism, the exact calculation formula, validation behavior for missing or non-positive dimensions, the 429 rate-limit contract with retry_after_seconds and Retry-After header, and the response fields. This is valuable operational behavior that annotations do not provide.

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 structured in clear sections — purpose, behavior, returns, related tools — with each sentence contributing useful information. No filler or redundant restatement of structured metadata appears, and the core purpose 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?

For a read-only, idempotent calculator with fully specified parameters and an output schema, the description covers the result payload, error behavior, rate limiting, retry handling, and alternative tools. No important invocation-related detail 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?

The input schema already provides 100% documented parameter coverage, including descriptions, examples, and value constraints. The description adds helpful context about per-piece dimensions and linear scaling, but the schema is already doing the heavy lifting, so the 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?

Opens with a clear verb-resource action: 'Calculate cubic metres (CBM) for a shipment from per-piece dimensions' — then situates it in the shipping domain and distinguishes it from related tools. The purpose is specific and not merely a restatement of the tool name.

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 'Related' section explicitly names alternatives with their distinct use cases: chargeable_weight_calculator for air cargo billing weight, consignment_calculator for multi-line totals, unit_converter for single conversions, and shipment_summary for full composite analysis. This gives an agent concrete guidance on when to choose this tool versus a sibling.

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 mark the operation as read-only and idempotent. The description adds important behavioral context beyond those: per-piece volumetric weight rounded to 2 decimals before totalling, basis reporting which weight governs, deterministic behavior, exact error behavior for missing/non-positive inputs, and rate-limit/retry handling via 429 responses. No contradiction with 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 long, but each section earns its place: main calculation, behavioral rules, error handling, response envelope, and related tools. It is front-loaded with the core purpose and then organized topically, so an agent can quickly extract the essential directive.

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 6 parameters, output schema, and annotations, the description is complete: it covers scope, transformation logic, error conditions, rate limits, result envelope, and alternatives. It does not need to explain return values in detail because the output schema is present.

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%, so the baseline is 3. The description still adds meaning: it explains the formula (L x W x H cm divided by divisor), the IATA vs. express-carrier divisor conventions, per-piece interpretation, and the distinction between volumetric and actual weight across pieces. This goes beyond the schema but does not need to fully repeat parameter details.

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 statement: 'Calculate air freight chargeable weight' and explains the core concept. It distinguishes the tool from explicit siblings (cbm_calculator, consignment_calculator, uld_lookup), so an agent can clearly tell what this tool is for.

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 this tool applies: air mode only, and when it does not: sea W/M is covered by consignment_calculator with mode=sea. It also points to related alternatives and even behavior on rate limits with get_subscribe_link. Nothing is left ambiguous about choice of tool.

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 mark the tool as read-only, idempotent, and non-destructive, and the description adds important behavioral detail on top of that: calculations are deterministic, flags are advisory and can never imply compliance, invalid lines error with the offending field, and the API is rate-limited with a 429 body containing retry_after_seconds and Retry-After. This gives an agent a clear picture of expected behavior, error handling, and side-effect constraints beyond what annotations provide. No contradiction with 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?

The description is structured and front-loaded: the first sentence captures the core output, and subsequent paragraphs cover behavior, errors, return envelope, limitations, and related tools. Every clause earns its place — even the rate-limit and limitation notes directly affect invocation correctness — while distinct labels such as 'Behavior', 'Returns', and 'Limitations' keep it readily navigable.

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 complex tool with 4 parameters, nested objects, enums, an output schema, and many siblings, the description gives everything an agent needs: direct input combinations, schema, behavior, error semantics, rate-limit handling, return envelope, and explicit comparison to the alternatives. It also appropriately relies on the output schema for structural return details, but adds the meaningful caveat that flags are advisory and not compliance advice.

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 parameters at 100% coverage, so the description does not need to re-explain every field. However, it adds valuable semantic context beyond the schema: the canonical vs legacy distinction, the default for mode, the IATA divisor default of 6000, and that options.container_number/awb_number trigger check-digit sanity flags. The description also clarifies that legacy items are 'dimensions in cm, weight in kg,' which the schema leaves somewhat implicit.

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 stating the exact scope — calculate per-line and grand totals for a multi-item mixed consignment, naming each metric (CBM, LDM, volumetric weight, mode-specific chargeable figure) and the advisory flags. It differentiates the tool from siblings by explicitly labeling cbm_calculator, chargeable_weight_calculator, and ldm_calculator as 'single-figure versions' and by distinguishing shipment_summary as the tool that adds vehicle/container suggestion and duty estimates.

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 concrete guidance on when to choose this tool versus alternatives: single-figure modes are separate tools, shipment_summary is the next step for broader recommendations, and adr_lookup explains a flagged UN number. It also clarifies canonical lines[] vs legacy flat items[], and tells users to call get_subscribe_link when rate limits are hit.

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?

Beyond the readOnlyHint annotation, the description reveals concrete behavior: per-record provenance, unknown-type errors returning the valid slug list, geometric best-effort fits with explicit non-modeling caveats, and rate limiting where 429 returns retry_after_seconds. This is rich behavior the annotations alone do not cover.

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?

While the description is long and dense, each sentence earns its place: covering supported types, invocation variants, fit semantics, provenance, error behavior, rate limits, and sibling routing. It is structured and front-loaded, but a little heavy for agents scanning quickly.

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 readOnlyHint, idempotentHint, and openWorldHint=false, plus an output schema and 100% parameter schema coverage the description still fills important gaps: exact rate limits, best-effort fit limitations, error-response form, and related-tool routing. An agent has all the behavioral context 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 text already covers all six parameters at 100% coverage, including examples like '20ft-standard' and note that length is required to trigger the load-fit calculation. The description restates some of this framing (omit type to list all, adding dims computes fit) but does not add meaning significantly 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 and resource: 'Get ISO shipping-container specifications, with optional load-fit maths.' It enumerates exactly which 10 container types are covered, and this high-level statement is sufficiently distinct from siblings like cbm_calculator, uld_lookup, and validate.

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 Related section explicitly differentiates sibling tools: validate checks a container number's check digit, cbm_calculator/consignment_calculator handle cargo volume, and uld_lookup is the air-freight equivalent. This gives clear context for choosing this tool over alternatives, though it does not give an exhaustive when-not-to-use list.

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 indicate read-only, idempotent, non-destructive behavior, and the description adds substantial behavioral detail beyond that: deterministic results, built-in empty running, low representativeness for sea/air, unknown inputs returning available:false rather than fabricated factors, and rate-limiting behavior with 429 handling. The description is fully consistent with 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?

The description is long but every sentence earns its place. It front-loads the core formula and required inputs, then adds important parameter guidance, behavioral notes, return-envelope content, limitations, and sibling-tool distinctions. It is well-organized into functional paragraphs with no fluff or tautology.

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 7 parameters, an output schema, and a rich context from sibling tools, this description is complete: it covers input requirements, key parameters, edge cases (unknown returns, rate limits), the return envelope, limitations, and explicit distinction from related calculators. An agent has everything needed to select and invoke the tool correctly without external guesswork.

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?

Although schema descriptions cover all 7 parameters, the tool description adds critical semantic nuance: actual gross mass vs chargeable/volumetric weight (a common air-freight mistake), the fact that distance is caller-provided with no routing behavior, the meaning of wtw vs ttw, and region/authority mappings (uk=DEFRA, us=EPA, fr=ADEME). This goes well beyond the schema's short 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?

Description opens with a specific verb and resource: 'Estimate freight transport greenhouse-gas emissions (kgCO2e) for a shipment leg' per ISO/GLEC standards. It clearly defines the calculation formula and the required inputs. The closing line distinguishes it from cbm_calculator, ldm_calculator, and chargeable_weight_calculator by stating those size/bill a shipment while this one estimates CO2e.

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 instructs when to use the tool and with what care: pass actual gross mass not chargeable weight, provide distance because the tool does not route, and do not add an empty-return leg. It also names sibling calculators that are distinct and directs to get_subscribe_link for higher rate limits. This is full usage guidance with both affirmative and exclusionary conditions.

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?

The description discloses that this is a static local response with no API call and cannot be rate-limited, which adds meaningful behavior beyond the annotations. It also specifies the return fields and instructs the agent to hand the URL to the user. No contradiction with annotations found.

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 well-structured: it starts with the primary purpose, then adds usage triggers, behavioral details, return information, and usage caution. Every sentence provides meaningful guidance without 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?

For a simple static tool with one optional parameter and an output schema, the description covers all necessary operational context: when to call, what happens, and what the agent should do with the result. There is no missing information that could lead to incorrect 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?

The single optional parameter tier is fully documented in the input schema, including the enum value 'pro' and its meaning. The description mentions the pro tier context but does not need to add more because schema coverage is 100%. This is a case where the schema correctly carries the parameter details.

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?

State a specific action: retrieving the subscription URL for FreightUtils Pro. It explicitly ties to higher API limits and clarifies the condition when it is relevant. The distinction from sibling calculator/lookup tools is clear.

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 explicit when-to-use guidance: when the user asks about upgrade/pricing or after a 429 rate_limited error. It also tells the agent what not to do (agents must not complete subscription), which is clear and actionable.

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 provide readOnlyHint and idempotentHint, but the description goes far beyond by covering rate limits, 429 retry behavior, keyword search matching official WCO phrasing, and the validity of zero-row results. It also clearly states limitations around national tarrifi lines and legal binding. This is strong 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 longer than average but every sentence earns its place: parameter modes, search behavior, rate-limits, return envelope, jurisdictional limitations, and related tools are each clearly structured. It avoids filler while remaining front-loaded with the core purpose.

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 an output schema exists, the description still covers the full operational shape: invocation modes, valid answer semantics, error handling, and stale limitations. An agent can safely invoke it and interpret results without additional information.

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 already documents all three parameters, so the baseline is 3. The description adds meaningful context: the hierarchy of 2/4/6-digit codes, the need for formal tariff wording in queries, and that section means Roman numeral I-XXI. This is more than the schema provides. A minor gap is there is no explicit handling of multiple parameter combinations beyond stating ONE.

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: searching 6,940 WCO Harmonized System HS 2022 codes at the 6-digit international layer. It further explains the code structure and clearly differentiates this lookup from related 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 explicitly says when to use this tool vs alternatives, including which parameter mode to choose. It names uk_duty_calculator and ics2_check as related but different tools, and directs callers to get_subscribe_link for rate limiting. This leaves no ambiguity about selection.

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?

注解已声明readOnlyHint、idempotentHint和destructiveHint，描述在此基础上补充关键行为信息：确定性匹配、无二进制接受/拒绝裁决、clean≠保证通过、限流机制（429响应含retry_after_seconds）、以及超出限制时应调用get_subscribe_link。还披露了非穷尽列表、定期更新等能力边界，远超注解能表达的内容。

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?

描述虽然较长，但每个句子都有明确的信息价值：从核心行为、返回结构、速率限制、限制条款到相关工具路由，信息密度高，没有冗余内容。关键用法说明（确定性匹配、clean含义、非保证性质）前置，限制和替代品放在后部层次清晰。

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?

对于单参数工具，描述已覆盖输入方向、输出结构（echo/flagged/clean/result/caveat/_source等）、已知行为特化、限流边界、误差与使用场景，以及相关工具链接。尽管输出schema存在，描述仍然显式列出返回的关键字段，帮助代理预期输出语义；因此上下文完备，无需额外推断。

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只有一个desc参数，且覆盖了100%，自带对比示例（'gifts' vs 'wooden toys for retail'），因此参数语义已经由schema充分完成。描述中仅复述'Pass description=<goods description>'，没有在schema示例之外增加大量新的参数语义或格式约束，按基线评分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?

描述用明确动词+宾语+范围说明工具功能：检查货物描述匹配欧盟ICS2禁止词列表，用于ENS申报。同时通过与兄弟工具hs_code_lookup和uk_duty_calculator的对比，清晰区分职责范围，代理无需打开schema即可理解工具用途。

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?

明确说明使用场景（在提交ENS之前进行筛查）、目标用户（海关/文件团队、报关行、代理）、以及何时不使用本工具（不是提交ENS，不是合规判定，不是法律建议）。还明确指出哪些兄弟工具用于其他功能的替代选择，让代理能做出正确的路由决策。

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?

The description is read-only, idempotent, and harmful: true for readOnlyHint, so the baseline transparency burden is reduced. It meaningfully adds behavior: read-only reference, errors on unknown codes, rate-limited to 25 requests/day for anonymous use, with retry semantics for 429 responses and a Retry-After header. It also summarizes the response fields, giving more than annotations alone would provide.

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 efficient and logically structured: purpose first, then parameter modes, then behavior/error/rate-limit considerations, then return value. Every sentence adds operational value, and the wording is compact with no repetitive 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?

For a simple two-optional-parameter tool, the description covers invocation, list filtering, error behavior, rate limits, retry handling, and output shape. It is slightly ambiguous about whether code and category can be combined, and it does not explicitly state that list results are an array, but the output schema is available and covered most of that. Overall it provides enough context for correct use.

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% because both code and category have descriptions and examples. The description adds meaning beyond the schema by defining the three valid modes: single code, category-filtered list, or neither to list all 11. This clarifies interaction between the two optional parameters, though it does not explicitly state what happens if both code and category are sent.

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: lookup the 11 Incoterms 2020 trade rules, and specifically covers payment for transport/insurance/customs plus risk transfer. It sharpens purpose by splitting the rules into any-mode versus sea-only modes, which clearly differentiates the domain from sibling lookup tools. This is not a tautology and gives a clear, distinct 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?

The description explicitly explains how to call the tool: provide a code, provide a category, or provide neither for a complete listing, and it warns that unknown codes error with the valid code list. It also directs heavy users to get_subscribe_link for higher rate limits. It lacks an explicit 'when not to use this' statement relative to other lookup siblings, but the intended invocation context is otherwise clear.

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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description needs to add only behavioral context, which it does: rate-limiting at 25/day with 429 retry handling, deterministic behavior, stackable semantics, the length-only fits check, and the warning/depreceived advisories. No contradiction with 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?

The description is long but every sentence earns its place: it defines, lists required/optional combinations, explains behavioral results, names rate-limit/retry rules, and routes to siblings. The structure is logical — concept, usage, behavior, output, related tools — with no filler 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 9 parameters, 2 enums, no required params, and an output schema, the description is complete enough to invoke the tool correctly. It covers the critical success condition (pallet vs custom dimensions), vehicle presets including deprecation, rate limits and retry, the result envelope fields, and the sibling-tool routing. Nothing an agent needs to call it correctly 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 coverage is 100% with rich descriptions for every parameter, so the schema does most of the heavy lifting. The description adds useful cross-parameter semantics that the schema alone cannot convey: the 'pallet preset OR custom length_mm + width_mm' exclusivity, the stack_stack_height effect on floor footprint, and the effect of weight_gg enabling the payload part of fits.

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: 'Calculate loading metres (LDM) for European road freight' and defines the unit precisely ('1 LDM = 1 linear metre of a 2.4m-wide trailer'). It differentiates this calculator from related sibling tools by pointing to vehicle_lookup, pallet_fitting_calculator, and consignment_calculator with distinct one-line scopes.

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 rules: 'Provide a pallet preset OR custom length_cm + width_mm — omitting both fails with a usage hint,' and explains optional-parameter trade-offs such as 'give weight_kg to also see total_weight_kg' and 'stackable = true with stack_height 2 or 3'. It also names alternatives through the Related list, letting the agent route to the right sibling.

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 destructiveHint. The description adds significant behavioral context: coordinate inputs are not stored or logged, the sort is deterministic, confidence semantics are explained, rate limiting is disclosed with retry_after_seconds and Retry-After header, and the tool is reference-only, not for navigation. This goes well 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?

The description is detailed but every sentence carries operational value: scope, dataset size, required and optional parameters, exclusionary behavior, rate-limit details, output format, limitations, and related tools. The key purpose is front-loaded, and there is no 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 covers required inputs, optional parameters, output response envelope, error behavior, limitations, data source, and sibling tools. There is an output schema present, so return values are contextualized. The definition is more than complete for an agent 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 input schema already defines all parameters with ranges, examples, and defaults; the description mostly restates this. It adds no truly new parameter semantics beyond what is in the schema, so a baseline 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 opens with a specific verb and resource: 'Find the airports nearest to a caller-provided latitude/longitude, sorted by great-circle (haversine) distance.' It clearly differentiates itself from siblings like airport_lookup and unlocode_lookup by stating it does not geocode place names and does not compute routes.

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 ('pass coordinates you already hold') and what it does NOT do ('does NOT geocode place names and does NOT compute routes'). It also names related alternatives (airport_lookup, unlocode_lookup) with their different purposes.

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?

Adds substantial behavioral details beyond the annotations: deterministic geometric fitting only, no interlocked or mixed orientations, weight-limit capping behavior, default pallet_deck_height_cm, error behavior for missing or non-positive dimensions, and rate-limiting with retry details and 429 handling. The description does not contradict annotations and enriches what it means for the operation to be read-only and idempotent.

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 structured into clear labeled sections: Behavior, Returns, Limitations, Related. The first sentence delivers the core purpose, and each additional section provides vital operational context without wasted words. It is longer than average but every sentence serves a functional purpose.

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 full calling context: what the result includes, which alternative tools to consider, limitations, rate limiting, retry behavior, and callback to a subscription tool for higher limits. The presence of an output schema is not ambiguous, and the in-description return list is sufficient for an agent to plan its use.

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 each parameter described, including defaults and examples. The description does not introduce new parameter semantics beyond that, though it confirms the relation between max_payload_kg and weight_limited and allow_rotation with the mention of 90-degree rotation. Since the schema already carries the full parameter meaning, a 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 opens with a specific verb and resource: 'Calculate how many identical boxes fit on a pallet' and enumerates the exact outputs. It distinguishes itself from related tools by citeing ldm_calculator, vehicle_lookup, and container_lookup with their different roles.

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?

Related tools are named with their distinct purposes ('pallets into trailer length', 'capacity per vehicle', 'pallets into containers'), which implicitly routes an agent. No explicit 'when to use vs when not' statement is present, but the limitations paragraph makes the scope clear.

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?

Although annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds rich behavioral detail: deterministic normalization, exhaustive grammar matching, ranked candidates with inspectable basis, a valid zero-result case, failed check-digit handling, and rate-limit behavior with 429 + retry_after_seconds. This substantially exceeds the minimal safety profile provided by annotations and informs the agent about edge cases, ordering, and failure modes.

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 most, but almost every sentence carries functional content, and the first section immediately communicates the tool's role. It is front-loaded with the use case and then proceeds methodically through behavior, return data, and limitations. The response-schema field enumeration is somewhat redundant with the output schema, but in a complex multi-format tool that redundancy helps the agent mentally map results.

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 high complexity (thirteen grammars, ranking, rate limiting, output envelope) and the rich input/output schemas, the description is exceptionally complete. It explains what the result list contains, how to interpret zero results and invalid check digits, what happens under rate limiting, and which sibling tools to route to for depth. Nothing an agent needs to make a correct call or interpret the output 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 for q is 100%, so the baseline is 3. The description goes beyond the schema by clarifying q must be a single token (max 32 chars), not free text or a manifest line, and by giving identity context (normalization strips prefixes, colliding grammars produce multiple candidates). This adds important semantic nuance about granularity and ambiguity that is not present in 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 a precise verb and resource: "Resolve an arbitrary freight identifier — one opaque string in, typed and cited candidates out." It immediately distinguishes itself from the many sibling lookup tools by framing itself as the agent front door for ambiguous identifier tokens, and reinforces this with a long list of identifier examples. This is a specific, actionable purpose that an agent can reliably select on.

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 the tool: "call this FIRST" when holding an identifier-ish token and not knowing which lookup tool fits, and then "follow the candidate's api_url / canonical_url (or the matching sibling tool) for depth." It also gives true exclusions — single-token only, not free-text, SCAC/BIC not covered — and lists the resolved sibling tools, so an agent receives both inclusion and exclusion criteria.

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 carry readOnlyHint/idempotentHint/destructive=false, and the description adds substantial behavior beyond them: the 2.40 m loading-metre divisor, 'no stackable flag treated as NOT stacked', palletSpaces as floor positions versus palletRows, partial failures surfacing in warnings instead of failing the call, the 25 requests/day IP rate limit with 429 retry_after_seconds and Retry-After header, and the legacy camelCase result shape. No contradiction with 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?

Long (~350 words) but front-loaded: the first sentence states the entire scope, followed by clean Inputs/Behavior/Returns/Limitations/Related sections. Some redundancy exists (engine calls and pallet floor positions appear twice), but for a composite tool merging three engines across four modes, dense detail is warranted rather than waste.

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 7-parameter, 4-mode composite with nested objects and an output schema, the description is complete: all input semantics, mode-specific conventions, error/rate-limit handling, return shape summary, limitations ('planning summary, not a quotation or compliance determination'), and sibling routing are covered. The existence of an output schema excuses full return-value enumeration.

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 relational meaning beyond individual field docs: 'origin/destination and incoterm refine the duty leg,' the conditional enabling of sections (hs_code + customs_value → duty; un_number → DG), and a compressed statement of the items[] field set and units. This is a modest but real increment over 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?

Opens with 'Composite shipment analysis in one call' and itemizes every computation: CBM, gross/chargeable weight, road LDM with pallet spaces and vehicle suggestion, volumetric weight, revenue tonnes with container suggestion, DG presence, and UK duty. The specific resource and scope are unmistakable, and the Related section hard-distinguishes it from the single-purpose 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?

Explicitly names alternatives and their relationship: consignment_calculator (canonical snake_case lines[] shape with advisory flags), the three engines it actually cals (ldm_calculator, adr_lookup, uk_duty_calculator), and 'the rest are the single-purpose equivalents of arithmetic it does inline.' Also routes to get_subscribe_link for higher rate limits. When-to-us vs alternatives is fully 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?

The description adds a substantial amount beyond the annotations: rates are fetched live per request, unknown or non-declarable codes error with HMRC's message, origin-dependent measures surface as warnings, and there is a rate limit with 429 handling and a retry_after_seconds field. This is exactly the behavioral detail an agent needs and uses.

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 typical but every section serves a purpose: behavior, returns, limitations, related tools. The core purpose and formula are front-loaded, and optional details are clearly segmented. Some return-field details could be left to the output schema, but nothing feels wasted.

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 rich output schema, 6 parameters, external dependency (live GOV.UK Tariff), rate limits, and related workflows, the description is complete. It covers error behavior, retry logic, return fields, limitations, and alternative/related tools. An agent can predict the tool's behavior and side effects without further documentation.

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 covers all 6 parameters with detailed descriptions and examples, so the baseline is met. The description adds extra meaning by defining the CIF calculation, stating optional parameters default to 0, and noting that commodity_code may need extension from 6 to 8/10 digits. It doesn't fully expand on incoterm semantics, but the schema covers 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 opens with a specific verb and resource: 'Estimate UK import duty and VAT for a commodity code using the LIVE GOV.UK Trade Tariff'. It goes on to explain the calculation formula and clearly separates this tool from siblings like hs_code_lookup and incoterms_lookup, so an agent can tell which tool to invoke.

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 identifies required versus optional inputs and provides related-tool guidance such as 'hs_code_lookup (find the 6-digit code first)' and 'incoterms_lookup (who actually pays these costs)'. It does not spell out exact 'use this instead of' conditions, but the context makes the intended usage clear.

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?

Beyond the readOnly/idempotent/destructive annotations, it discloses unknown-type error behavior, rate limiting with 429 and retry_after_seconds, Retry-After header, pending provenance status, and pallet-specific caveats like no internal dimensions. This is rich, honest behavioral context. It is also consistent with 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?

The description is long but front-loaded with the core look-up purpose and organized into explicit sections: behavior, returns, limitations, and related tools. The length is mostly justified by substantive caveats; however, the limitations paragraphs are unusually verbose and repetitive in places,

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?

It covers input values, return envelope structure, error and retry behavior, rate limits, data provenance, domain-specific caveats about pallet dimensions and weight figure reliability, and related tools. Combined with the 100% schema coverage and an output schema, an agent can invoke and interrogate this tool safely.

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 parameters at 100% coverage, including the same examples ('AKE', 'PMC', 'ake-ld3') and filters. The description adds little beyond restating filter behavior and the omission rule, so the high baseline 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 opens with a precise verb and resource — 'Look up air-cargo ULD specifications' — and immediately scopes 16 types across lower-deck containers, main-deck pallets, and temperature-controlled units. It differentiates itself from siblings like container_lookup and airline_lookup via the Related line, so an agent can tell them apart.

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 explicit: provide IATA code/slug or omit for a full list, and use category/deck to filter. The Related line gives alternative tools with clear one-phrase distinctions: chargeable_weight_calculator for billing, container_lookup for sea freight, airline_lookup for aircraft. It lacks an explicit 'do not use when...' but the alternatives are 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?

Beyond the readOnly and idempotent annotations, the description discloses deterministic behavior, formula naming in responses, cross-dimension error behavior with accepted-unit lists, rate limits with retry headers, and specific unit definitions such as IATA divisor, short ton, and long ton. This gives the agent essential runtime expectations.

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 dense but every sentence earns its place: unit inventory, special freight targets, behavior, error handling, rate limiting, return envelope, and sibling-tool routing. It is long because the tool genuinely has multiple behaviors to document, and there is no 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 tool with dimensional restrictions, freight-specific targets, rate limiting, error bodies, and a defined response envelope, the description covers all these aspects without missing any critical context. It even explains when to use sibling tools first, making it effectively self-contained.

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?

Although schema coverage is 100%, the description adds significant meaning: category groupings for units, the IATA 6,000 divisor making 1 CBM = 166.67 kg, the sea W/M freight tonne rule, and the exact difference between tonnes, short tons, and long tons. This goes well beyond the enum lists 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 states a specific verb and resource: converting freight and logistics units across weight, volume, and length dimensions, with two freight-specific targets. It distinguishes itself from sibling calculators by naming cbm_calculator and chargeable_weight_calculator as related but different 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?

It explicitly gives usage context: dimensions must match, freight targets are only valid from cbm, and it names alternatives — cbm_calculator for dimension-to-volume conversion and chargeable_weight_calculator for proper air billing with pieces and a custom divisor. It also advises retry behavior on 429 and directing users to get_subscribe_link for higher limits.

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, and the behavioral paragraph adds meaningful context: exact code hits are provenance-based, fuzzy name hits expose confidence via match quality, unknown codes produce not-ound, and 429 response carries retry_after seconds and Retry-After header. This is exactly the extra behavior information an agent needs beyond annotations. No contradiction with 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 front-loaded with a precise one-line summary, then proceeds into code structure, usage modes and behavior. No sentence is wasted; even the 429/back-off detail earns its place because it is operational guidance an agent would otherwise lack. The length is justified by six-dimensional as in this is a complex 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?

The description covers input options, return content, error behavior, rate limits, retry instructions, and alternatives for higher limits. The only meaningful gap is what happens when no parameters are provided: all schema properties are optional, but the description implies a code or query should be passed. That edge case is not resolved.

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 has 100% description coverage, so the schema carries most of the meaning. The description adds value by framing code vs. query as two modes and noting that country/function_type optionally narrow the name query. That is useful relational/parametric semantics. The examples slightly duplicate schema examples, so not quite max.

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 precise verb-resource pair: 'Search 116,232 UN/LOCODE transport locations worldwide' and enumerates the exact set of location categories. It anchors the resource with the 5-character code structure and true examples (GBLHR, NLRTM), so there is no ambiguity against sibling lookup tools like airport_lookup or container_lookup.

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 modes: provide code for exact record, or name query (min 2 chars) with country/function filters, and states limit caps/default. It also directs the agent to get_subscribble_link on rate-limit, which is useful alternative guidance. It does not explicitly contrast with sibling lookup tools, but the UNLOCODE-specific search conditions are clear.

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?

Even with annotations providing readOnlyHint and idempotentHint, the description richly supplements by disclosing the output detail, the modes, rate-limit behavior with 429 retry_after_seconds, and specific return fields per identifier. It also sets structural limititation explicitly. Nothing in the description contradicts annotations; in fact, annotations align with it.

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 well structured: it leads with a precise purpose, then separates modes, behavior, rate limits, return contract, limitations, and related tools. It is more verbose than strictly necessary, and some return-envelope detail might be redundant with the output schema, but each remaining sentence adds useful operational context.

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 delays with multiple inances, standards, modes, limitations, and a rate limit, the description covers all aspects needed for an AI agent to select and invoke it correctly. It includes enough detail about return envelope, error handling, and relationship to siblings/related tools. No obvious context gap for correct invocation or interpretation.

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?

All three parameters already have full descriptions and examples inside the schema, so schema description coverage is 100%, raising the baseline to 3. The description does helpfully clarify the mutual exclusion of text versus value+type, but it doesn't go materially beyond what the schema already communicates in terms of parameter meaning.

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 validates and parses freight identifiers across three named standards (ISO 6346 containers, IATA AWB, IMO), which is specific and informative. It also differentiates itself from sibling tools like container_lookup and airline_lookup, explicitly saying container_lookup is about type specs and airline_lookup uses the AWB-prefix dataset.

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 on/usage: pass text to scan arbitrary content or pass value with type to validate one identifier. It includes contextual guidance and 'Related' tool alternatives. It also warns what it is not (not a registry or tracking lookup), which reduces risky misuse.

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?

Beyond annotations (readonly, idempotent, non-destructive), the description enriches behavior with substantial context: unknown slugs return an error listing valid ones, per-record provenance includes sources and auditations, rate limiting (20 requests/day IP) produces an 429 with specific retry fields, and return tra data comes with caveats (typical specs, pending verification). This gives an agent realistic expectations about errors, limits, and data quality.

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 dense and well-structured, with labeled sections for behavior, returns, limitations, and related tools; it does not waste space. It is longer than necessary because it covers rate limits, error bodies, and provenance, but those are genuinely useful details. A minar redundancy exists between 'omitting it to list all' and the later mention of a filtered list, but overall it remains 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?

With an output schema present, the description need not duplicate return-fade types and instead covers what the schema does not convey: the FreigheUtils response envelope (result, confidence, _source, citable), literal limits of access, the exact shape of stale limits errors, and the related tools and limitations. Everything an agent needs to successfully call and interpret vehicle_lookup is avaiable.

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?

Sceema covegerage is 100%, but thesccema already describes each parameter (slug examples, región, category). The description adds behavior beyond the schema: providing a slug returns one record, omitting it lists all 17, category and region function as list filters, and an unknown slug errors with the valid set. This is valuated interaction context not present in schess.

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-resource pair ('Look up road-freight vehicle and tarai trailer specifications') and immediately delimiters the exact scope with a concrete list of 17 types. This clearly separates it from sibling tools like airline_lookup, container_lookup, and the calculator tools, which serve different domains and tasks.

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?

Cares clear how to invoke the tool: provide a slug for one record, omit it to list all, and optionally filter by category or region. It also points to alternative tools for related needs — ldm_calculator for pallet-fit questions and get_subscribe_link for rate-limit scafes — but it does not explicitly state 'when not to use this tool' in favor of each calculator.

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