FreightUtils MCP Server

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

Annotations already declare readOnlyHint and idempotentHint. The description adds value by explaining the calculation logic (points = quantity × multiplier) and the exemption threshold. It does not detail how multipliers are determined, but overall transparent.

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 two sentences: first states purpose and formula, second gives usage instructions. No wasted words, front-loaded with key information.

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

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

The tool has no output schema, and the description does not specify what the tool returns (e.g., total points, exemption boolean). For a calculator, this is a gap; agents need to know output format.

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 each parameter. The description adds contextual grouping (single vs mixed) but does not provide new meaning beyond summarizing usage patterns.

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 the tool calculates ADR 1.1.3.6 exemption with a specific formula and threshold. It distinguishes between single substance and mixed loads, making purpose unambiguous compared to siblings like adr_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 provides explicit usage scenarios (single substance vs mixed loads) and input guidance. It does not explicitly list when not to use or compare to alternatives, but the context is clear given the specialized nature.

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=true, idempotentHint=true, destructiveHint=false. The description adds useful context: returns specific fields, covers 2,939 entries across 9 hazard classes, and states that empty result means no match. No contradictions. Adds value beyond 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?

Description is 4 sentences, well-structured, front-loaded with main function. Each sentence serves a purpose: what it does, parameters, return fields, limitations. No fluff.

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?

Despite no output schema, description details return fields, dataset size, parameter constraints, and limitations. For a read-only lookup tool, it is fully complete and leaves no ambiguity.

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%. The description elaborates on each parameter: un_number returns every packing-group variant, search requires min 2 chars and is case-insensitive, hazard_class filters by class/divisions. Provides examples. Adds significant meaning beyond 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 clearly states the tool's purpose: 'Look up dangerous-goods (hazmat) reference data from the ADR 2025 dataset.' It specifies the verb 'look up' and the resource, and distinguishes from siblings by mentioning dataset size and hazard classes. No tautology.

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 tells when to use each parameter: 'Provide exactly one of: un_number (exact lookup), search (case-insensitive partial match), or hazard_class.' Also states what it does not do: 'does not assess or certify regulatory compliance.' Clearly guides agent on usage vs alternatives.

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 provide readOnlyHint, idempotentHint, destructiveHint. The description adds transparency about the tool's scope (reference-data comparison, not certification), the specific checks per item, and the per-outer limit for EQ mode. No contradictions 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?

Description is compact and front-loaded with core functionality. It uses plain language and avoids unnecessary repetition. A minor redundancy ('reference-data comparison' appears twice) prevents a perfect 5.

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

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

Given no output schema, the description adequately covers return values (overall_status, per-item breakdown with limit, reason, flags). It also addresses edge cases (EQ mode, not a certification). The description is complete for the tool's complexity.

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%, baseline 3. The description adds meaning beyond schema by explaining the role of 'inner_packaging_qty' for EQ mode's per-outer check, and the unit and quantity usage. This helps agents understand parameter interplay.

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?

Clearly states it compares quantities against ADR 2025 LQ/EQ reference limits for UN numbers. Describes output flags (within_limit, exceeds_limit, not_permitted) and overall status. Differentiates from siblings like 'adr_exemption_calculator' and 'adr_lookup' by specifying it's for pre-screening before formal classification.

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 says to use it to 'pre-screen small-quantity consignments before formal classification' and clarifies it's a reference-data comparison, not a certification. Provides context for when to use but does not explicitly name alternatives or state when not to use.

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=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is clear. The description adds value by explaining what AWB prefixes are ('3-digit codes on air waybills identifying the carrier'), which helps the agent understand search criteria. It does not contradict 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 two sentences long, front-loaded with the core functionality, and every word earns its place. It is concise, clear, and free of unnecessary information.

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

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

Given the tool's simplicity, full parameter schema, and annotations covering safety, the description is mostly complete. It explains the search domain and one key concept (AWB prefixes). It does not detail return format, but for a lookup tool this is acceptable. A score of 4 reflects minor room for improvement (e.g., mentioning output structure).

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 having a clear description (e.g., 'Exact IATA code (2 alphanumeric chars)'). The description adds overarching context about AWB prefixes but does not provide additional parameter-level details beyond the schema. Baseline 3 is appropriate as the schema already carries the burden.

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 the tool's purpose: 'Search 6,352 airlines by name, IATA/ICAO code, AWB prefix, or country.' It uses a specific verb ('Search') and specifies the resource ('airlines') and search criteria. This distinguishes it from sibling tools (e.g., hs_code_lookup, container_lookup) which are for other domains.

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 implies usage context: when you need to find airline information by various identifiers. It does not explicitly state when not to use it or suggest alternatives, but the context is clear given the sibling tools are distinct (e.g., adr_lookup, incoterms_lookup). A score of 4 is appropriate as it provides clear context without exclusions.

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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context: ambiguous name searches return ranked candidates (exact codes first, then larger airports), covers 85,555 airports worldwide, and notes data sources and cross-checking. 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 verbose but well-structured: first sentence defines the main functionality, then details input options, output contents, search behavior, coverage, and usage guidance. Every sentence adds value, though some details (e.g., 'public domain', 'cross-checked') could be considered extraneous for an AI agent.

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 output schema exists, the description need not explain return values, but it does list them. It covers input parameters, output fields, search behavior, data source, limitations ('not for navigation'), and distinctions from siblings. The tool has moderate complexity with 4 optional parameters, and the description is thoroughly complete.

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 covers 100% of parameters with descriptions. The description adds behavioral context for the 'query' parameter (min 2 chars, ranked results) and notes optional type filter, which improves beyond schema. However, the schema already adequately describes each parameter's purpose.

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 the tool looks up airports by IATA code, ICAO code, or free-text name/city search, and enumerates the returned fields. It explicitly distinguishes from sibling tools (airline_lookup, unlocode_lookup) by specifying what each sibling does.

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 states exactly when to use this tool: 'when an agent has an airport code or name and needs the airport's identity, location or codes.' It also warns against using for navigation and mentions alternatives, providing clear guidance on when not to use it.

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=true and destructiveHint=false, making the tool's safety clear. The description adds value by explaining that CBM is used for ocean freight pricing and the relationship to 'freight tonne', which is useful behavioral context beyond 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 three sentences, each providing essential information: the tool's purpose, a definition of CBM, and a shipping context note. No filler; all sentences earn their place.

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 there is no output schema and parameters are well-covered, the description explains the calculation purpose and shipping pricing rule. It lacks detail on output format (e.g., return value), but as a calculator with good annotations, it is largely complete.

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 clear descriptions for each parameter (length_cm, width_cm, height_cm, pieces). The description does not add additional parameter semantics beyond the schema, but it explains the overall calculation context. 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 clearly states 'Calculate cubic metres (CBM) for a shipment', using a specific verb and resource. It distinguishes itself from siblings like 'ldm_calculator' and 'pallet_fitting_calculator' by focusing on CBM for shipping.

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 provides context for when to use this tool (shipping volume calculation) and defines the unit. However, it does not explicitly state when not to use it or mention alternatives like 'ldm_calculator', leaving some ambiguity.

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 readOnlyHint and idempotentHint, so the description doesn't need to restate that. It adds value by explaining the IATA factor and the interpretation of the ratio, which goes beyond 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 three sentences, each with a distinct purpose: function, standard, and interpretation. It is front-loaded with the main purpose and includes no fluff.

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 complexity (6 parameters, no output schema), the description covers the key calculation logic and standard. However, it could mention output format or units, but the score is still high due to clear explanation.

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 has 100% coverage with descriptions for parameters. The description mentions the factor and pieces defaults indirectly, but does not add new semantics beyond what the schema already provides.

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 the tool calculates air freight chargeable weight by comparing volumetric and actual weight. It distinguishes itself from siblings like cbm_calculator and ldm_calculator by focusing on the specific air freight concept of chargeable weight.

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 when to use the tool (to determine the greater of actual vs volumetric weight) and provides the IATA standard factor. However, it does not explicitly state when not to use it or compare with sibling tools.

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. The description adds critical context: flags are advisory only, not compliance advice, and the tool uses best-effort deterministic calculation. It warns about verification and disclaims regulatory responsibility, which 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 well-structured: first sentence provides an overview, then explains input format, then details flags and disclaimers. It is front-loaded with the main purpose. Slightly verbose with the disclaimer section, but every sentence adds value.

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?

Despite no output schema, the description explains the tool calculates per-line and grand totals plus advisory flags. It covers input details, mode selection, and the nature of flags. This is sufficient for an agent to understand inputs and expected outputs.

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 baseline is 3. The description summarizes input structure (lines vs items, dims, weight, options) but does not add significant meaning beyond the schema's own field descriptions. It does not clarify edge cases or provide additional semantic hints.

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 the verb 'Calculate' and the specific resources: total CBM, loading metres, volumetric and chargeable weight, plus advisory flags. It distinguishes from siblings like cbm_calculator and ldm_calculator by emphasizing multi-item mixed consignment and advisory flags.

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 provides clear instructions on providing a transport mode and either 'lines' or legacy 'items' arrays, and mentions configurable options like air_volumetric_divisor. However, it does not explicitly state when to use this tool over the more specific sibling calculators (e.g., cbm_calculator), lacking exclusionary guidance.

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=true, idempotentHint=true, destructiveHint=false, so the description doesn't need to repeat safety. It adds value by listing the output fields (dimensions, capacity, weight, pallet counts) and mentioning the number of container types.

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?

Single sentence covering purpose and output. Listing 7 of the 10 container types is somewhat redundant with the schema examples, but overall efficient and 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?

Given the simplicity (one optional parameter), the description adequately explains what the tool returns and the scope (growing container types). No output schema exists, so describing return fields is sufficient.

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

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

Schema coverage is 100% and the parameter description in the input schema is detailed. The tool description adds examples of container types but does not significantly enhance the schema-provided semantics.

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 the action ('Get') and the resource ('ISO shipping container specs'), listing specific container types and what data is returned (dimensions, capacity, weight, pallet counts). It distinguishes from sibling lookup tools (e.g., vehicle_lookup, uld_lookup) by focusing on shipping container specs.

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

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

No explicit when-to-use or alternatives, but the purpose is clear: use it when you need container specifications. Sibling tools like calculators indicate it's for lookups, not calculations. Could mention it's for ISO containers specifically.

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 (readOnlyHint, idempotentHint, destructiveHint), the description adds critical behavioral context: it's a best-effort reference estimate, not audited; sea/air are low-representativeness defaults; it does not compute distances; and unknown inputs return no factor. 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 dense and well-structured with front-loaded formula and required inputs. Every sentence adds value, though some consolidation could improve conciseness without losing meaning.

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, output schema, and annotations, the description is comprehensive. It covers input constraints, behavioral caveats, return format (emissions breakdown, factor details, source citations), and edge cases (unknown sub_mode/region).

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?

Despite 100% schema coverage, the description adds essential context beyond the schema: mass must be actual gross mass (not chargeable), distance must be provided, and sub_mode behavior (unknown returns available:false). It also warns against common air-freight mistakes.

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 the tool estimates freight transport GHG emissions per ISO/GLEC, with a specific formula. It distinguishes from sibling tools like cbm_calculator and chargeable_weight_calculator by explicitly naming them and stating its unique 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 states when to use (known shipment with determined mass and distance) and what not to do (do not route, do not pass chargeable weight, do not add empty-return leg). It also explains behavior for unknown values (returns available:false).

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=true, idempotentHint=true, destructiveHint=false. The description adds that the tool returns a URL and that agents must not process the subscription themselves, which is a key behavioral constraint not covered by 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?

Three sentences, no redundancy, front-loaded with the core purpose, and every sentence adds necessary information.

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

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

Given the simple nature of the tool (one optional parameter, no output schema, full schema coverage, and thorough annotations), the description is complete. It covers purpose, usage, and behavioral constraints without needing more.

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

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

Schema coverage is 100% and the enum parameter is fully documented in the schema. The description adds that only 'pro' is supported, which is already listed in the enum, so it adds minimal value 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 explicitly states the tool retrieves a URL for subscribing to FreightUtils Pro, using specific verb-noun phrasing. It clearly distinguishes itself from sibling tools, which are all unrelated calculators or lookups.

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 (user asks to upgrade, hits rate limit, asks about pricing) and when not to (agents must not complete subscription). This provides clear decision 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context about the code system but no additional behavioral traits. It is consistent with annotations, no contradictions.

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?

Two sentences, zero wasted words. The first sentence states the core function, the second provides essential background and usage. Perfectly front-loaded and 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?

For a simple lookup tool with 3 optional parameters and no output schema, the description provides sufficient context: what it does, how many codes, and what HS codes are. It lacks details on return format, but that is acceptable given tool simplicity and annotation coverage.

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 already described. The description adds only a general usage hint ('Provide a search term or exact code'), which does not significantly enhance 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 clearly states the tool searches HS tariff codes, specifies the number of codes (6,940), and explains what HS codes are. It distinguishes from sibling lookup tools by targeting a specific domain.

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 instructs to 'Provide a search term or exact code,' which is clear usage guidance. However, it does not specify when to use this tool over alternatives like adr_lookup or container_lookup, nor does it mention any exclusions.

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=true and destructiveHint=false, indicating safe read operation. Description adds details about return values (flagged terms, clean boolean, caveat, source), and discloses limitations (non-exhaustive list, clean not a guarantee). No contradictions.

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 comprehensive but somewhat lengthy; however, each sentence adds value. It is well-structured with clear sections and 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 the single parameter and existence of output schema, the description is complete: it explains input, output (flagged terms, clean boolean, etc.), usage context, limitations, and legal basis. Meets all needs for an AI agent.

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?

Single 'description' parameter with schema coverage 100%. The description adds context that it is a goods description to check against stop-words, which is necessary and adds value beyond the schema's minimal description.

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 the tool checks a goods description against the EU ICS2 stop-words list, with specific verb 'check', resource 'goods description', and explicit scope before filing ENS. It distinguishes from siblings like hs_code_lookup and uk_duty_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?

Provides explicit when to use (before filing ENS), what it does not do (not ENS filing, not legal advice), target users (customs/documentation teams, brokers, etc.), and mentions the list is non-exhaustive. Clear exclusions and alternatives 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 the tool as read-only and idempotent. The description adds useful context about the content (Incoterms 2020, transport/insurance/customs responsibilities, mode categories) without contradicting 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?

Two concise sentences with no superfluous information. The first sentence states the purpose, the second provides key details.

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

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

Given no output schema, the description explains the domain and categories but does not explicitly describe the response format. However, the input schema and description together allow an agent to reasonably infer expected output.

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 both parameters described. The description adds value by listing example codes for each category, making it easier to understand valid inputs beyond the schema pattern.

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 the tool looks up Incoterms 2020 trade rules, listing the 11 rules and their categorization. This distinguishes it from sibling lookup tools like hs_code_lookup or unlocode_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 implicitly indicates usage for retrieving incoterms information, but provides no explicit guidance on when to use this tool versus alternatives, or when not to use it.

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, idempotentHint, and no destructiveness, so the tool is a safe calculation. The description adds context about trailer utilisation and defaults (e.g., 13.6m length, 2.4m width), which informs behavior beyond annotations. It does not contradict 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 concise (two sentences) and front-loads the key purpose. It includes useful details without verbosity. Minor improvement could be to use bullet points for clarity.

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 low complexity (read-only calculator), no output schema, and complete parameter documentation, the description adequately covers purpose and scope. It could mention typical return format or units, but is sufficient 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 description coverage is 100%, so the schema already documents all parameters. The description adds context about pallet presets and vehicle types (e.g., listing specific values) but does not explain relationships between parameters or calculation logic. 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 clearly states the tool calculates loading metres for road freight, specifies trailer dimensions, and lists supported pallet presets and vehicle types. It distinguishes itself from siblings like cbm_calculator and pallet_fitting_calculator by focusing on LDM specifically.

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 implies usage for road freight LDM calculation and mentions European trailer standards, but does not explicitly state when to use this versus other calculators like cbm_calculator or pallet_fitting_calculator. No exclusion criteria or alternatives are provided.

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, idempotentHint, destructiveHint. Description adds that coordinates are input-only, not stored/logged, and lists data source (85,555 airports from OurAirports). No contradictions.

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?

Every sentence serves a purpose: core function, inputs, behavioral notes, usage guidelines, sibling differentiation. Efficient and well-structured.

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 purpose, usage, parameters, behavior, and discrimination. Output schema exists, so return values are not needed. Fully complete for the tool's complexity.

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 has 100% description coverage, but description adds value: explains radius_km and max_results defaults, type filter with example. This enhances understanding beyond 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 clearly states the tool finds airports nearest to coordinates, sorted by distance, using specific verb and resource. It distinguishes from sibling tools like airport_lookup and unlocode_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?

Explicitly states when to use (when coordinates are already available) and what not to use (no geocoding, no routes). Names alternative tools for different scenarios.

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 indicate readOnlyHint=true and idempotentHint=true, which the description aligns with. The description adds that the tool determines optimal arrangements and volume utilization, which is useful context beyond 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 a single sentence that efficiently conveys the core function and constraints. No unnecessary words.

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 input schema's rich descriptions and annotations, the description covers the main purpose. It does not mention return values or output format, but there is no output schema, so some expectation is set. Could mention that it returns a number or arrangement details.

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 parameters are described in the input schema (100% coverage). The description does not add additional meaning beyond what the schema provides, so a 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?

The description clearly identifies the tool's purpose: calculating how many boxes fit on a pallet, with layers, rotation, and weight limits. It specifies the output (optimal arrangement and volume utilization) and distinguishes itself from other logistic calculators like cbm_calculator or ldm_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?

The description implies use cases by mentioning key constraints (layers, rotation, weight limits) but does not explicitly state when to use this tool versus alternatives or when not to use it. However, the context of sibling tools suggests it is for pallet fitting specifically.

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=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds that it returns per-mode calculations, DG compliance flags, and customs estimates, which is useful behavioral context. But it does not disclose any potential performance implications or internal tool calls.

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?

Two concise sentences. The first sentence introduces the composite nature and lists key components. The second sentence clarifies inputs and outputs. No unnecessary words, and the most important information 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?

Description covers main output types (per-mode calculations, DG flags, customs estimates) and inputs (items, mode). However, it does not mention the optional input fields (origin, destination, incoterm, freight/insurance costs) that influence the customs estimate, nor does it explain acronyms like 'W&M'. With no output schema, more detail on return value structure would be helpful.

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 descriptions for all parameters. The description adds minimal beyond 'Accepts multiple items with a transport mode', which is already in the schema. No additional meaning or clarification provided for any parameter.

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 explicitly states it's a composite shipment summary that chains multiple calculations (CBM, weight, LDM, ADR, duty) into one response. It clearly identifies the specific verb ('composite summary') and resource, and distinguishes from sibling tools which are individual calculators.

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 implies usage when a combined summary is needed by stating it 'chains' multiple calculations. It lists the included components, but does not explicitly state when to use this tool vs individual calculators. However, the composite nature is clear, and siblings are single-purpose, so the context is sufficient.

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 valuable behavioral context: it uses live GOV.UK Trade Tariff data (implying results may change over time) and flags preferential rates and import restrictions. No contradictions.

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

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

The description is a single, well-structured paragraph that front-loads purpose, then data source, outputs, and additional features. Every sentence adds value; there is no redundancy or unnecessary detail.

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 complexity (6 parameters, 3 required, no output schema), the description explains what the tool returns (CIF value, duty/VAT rates/amounts, total taxes, landed cost) and mentions a flag for preferential rates/restrictions. It is fairly complete for a calculator but could mention error handling or data recency limitations.

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 having a clear description and constraints (e.g., pattern, enumeration). The overall description does not add significant meaning beyond what the schema provides, though it lists outputs that help infer parameter purpose. 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 uses specific verbs ('Estimate', 'Uses', 'Returns', 'Flags') and clearly identifies the resource (UK import duty and VAT for a commodity code and origin country). It differentiates from sibling tools like hs_code_lookup and incoterms_lookup by focusing on duty/VAT calculation rather than classification or term 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 implies usage for import duty and VAT estimation with a given commodity code and origin country. It mentions live government data and output fields, which sets context, but does not explicitly state when not to use it or compare to sibling calculators (e.g., cbm_calculator for volume or chargeable_weight_calculator).

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 specific behavioral context beyond the annotations by listing the returned data: dimensions, weights, volume, aircraft compatibility, and deck position. Annotations already indicate it's read-only and idempotent. The description does not contradict annotations and provides useful output details.

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 extremely concise: two sentences that front-load the purpose and immediately follow with the output. Every sentence earns its place without any wasted words.

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 simplicity, the description is complete. It explains what the tool does, what parameters are available (via schema), and what the output contains. No output schema exists, but the description compensates by listing the return values. For a read-only lookup, this is sufficient.

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 parameters well. The description adds value by providing example ULD codes (AKE, PMC, PLA) and noting that 16 types are available, which helps understand the 'type' parameter. It also mentions the output, which indirectly relates to parameter usage.

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 the tool's purpose: 'Look up air freight ULD specs.' It specifies the number of types and examples, and it distinguishes itself from sibling lookup tools like container_lookup by focusing on air freight ULDs specifically.

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 implies usage through its clear domain, but it does not explicitly state when to use this tool versus alternative lookup tools (e.g., container_lookup) or provide any 'when not to use' guidance. The context is implied but not explicit.

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=true, idempotentHint=true, and destructiveHint=false, so the behavioral safety profile is clear. The description adds contextual information about unit categories but no additional behavioral traits, which is acceptable given the annotation coverage.

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

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

The description is extremely concise: two sentences. The first sentence states the purpose, the second lists unit categories. No wasted words, front-loaded with the core functionality.

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 converter tool with 3 parameters and no output schema, the description covers the input units and special freight conversions well. It lacks explanation of the return format (e.g., converted number) but that is typical for converters. Overall, adequate for an agent.

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 detailed descriptions for each parameter, including enum values. The description lists unit categories but does not add significant meaning beyond what the schema already provides. 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 clearly states 'Convert between freight units' and lists specific unit categories (weight, volume, length) and special freight conversions. The verb 'Convert' and resource 'units' are precise, and it distinguishes itself from sibling tools like cbm_calculator or chargeable_weight_calculator by being a general converter.

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 provides clear context for when to use the tool (converting among the listed units), but it does not explicitly mention when not to use it or direct users to specific sibling tools for specialized conversions, which would make it a 5.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: the tool searches a specific dataset of 116,129 locations covering various transport functions. No contradictions; it supplements the safety profile with scope details.

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?

Description is two concise sentences: first states the scope and data size, second lists coverage and search methods. Every sentence adds value; no unnecessary words.

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 is provided, but the description covers the tool's purpose, data sources, and search methods. It does not describe the return format or pagination behavior, which would be helpful for completeness given no output schema. Still, it is fairly comprehensive for a lookup 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 the schema already documents each parameter. The description restates the search dimensions (name, code, country, function type) but does not add new meaning beyond summarizing. 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?

Description clearly states the tool searches UN/LOCODE transport locations worldwide, specifying the count (116,129) and covering specific types (seaports, airports, etc.). It explicitly distinguishes from sibling tools which are mostly calculators and other lookups.

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 mentions search methods (by name, code, country, function type) but does not explicitly say when to use this tool vs alternatives. Given sibling tools are distinct (e.g., container_lookup, airline_lookup), it's clear this is the UN/LOCODE tool, so guidance is implicit but could be stronger.

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=true, idempotentHint=true, destructiveHint=false. The description adds valuable context: uses public check-digit algorithms, returns normalized form and validity, and explicitly states the structural-only nature (not existence). 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 moderately long but well-structured: starts with main purpose, explains modes, then output details, then caveats. Every sentence adds value, though it could be slightly more concise without losing information.

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

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

Given the tool's complexity (three identifier types, two modes, output schema exists but not shown), the description covers all necessary aspects: input constraints, mode selection, output details per type, and structural-only limitation. No obvious gaps.

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 descriptions. The description adds meaning by explaining parse mode vs. typed mode, the three type enum values, and what details are returned per type (e.g., owner prefix for container, airline for AWB). This goes beyond the schema's simple 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 uses specific verbs ('Find and validate') and clearly identifies the resources (freight identifiers: container, AWB, IMO). It distinguishes itself from sibling tools container_lookup and airline_lookup, which are mentioned as doing different things.

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 states when to use (confirm well-formedness, extract from freeform string) and when not to (this is not a registry/tracking lookup). Also distinguishes from container_lookup and airline_lookup, providing clear alternatives.

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, and non-destructive behavior. The description adds value by specifying the kind of data returned (dimensions, payload, etc.) and noting 17 vehicle types. There is 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 a single, well-structured sentence that front-loads the action and scope. Every word is informative, with no 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?

Given the tool's simplicity (3 optional params, no output schema), the description adequately explains what the tool does and what it returns. It could be more detailed about exactly which fields are in the output, but it is sufficient for a lookup 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?

Input schema has 100% coverage with clear descriptions for each parameter (slug, region, category). The tool description does not add additional meaning beyond the schema, such as explaining how parameters interact. 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?

The description clearly states the tool's purpose: to look up road freight vehicle and trailer specs. It lists specific vehicle types (curtainsiders, rigids, vans, US trailers) and details what is returned (internal dimensions, payload limits, pallet capacity, features). This differentiates it well from sibling tools, which are calculators and other lookups.

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 implicitly indicates when to use the tool (when vehicle specs are needed). However, it does not explicitly state when not to use it or point to alternatives. Since the sibling tools are distinct, the lack of explicit guidance is a minor gap.

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