FreightUtils MCP Server

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds value by explaining the calculation formula and the exemption threshold. It clarifies that the tool is a calculator, not a mutator. 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 three sentences, each serving a distinct purpose: defining the calculation, stating the threshold, and specifying input modes. No wasted words; front-loaded with 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 tool's complexity (calculator with two modes) and the absence of output schema, the description adequately covers inputs and expected behavior. It explains the rule and inputs completely, leaving no ambiguity about usage.

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 descriptions for items, quantity, and un_number. The description adds context about how parameters relate (single vs mixed), but does not add new details beyond the schema for each parameter. Baseline 3 applies.

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

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

The description clearly states the tool calculates ADR 1.1.3.6 exemption, explaining the formula (points = quantity x multiplier per transport category) and threshold (<= 1,000). It distinguishes between single substance and mixed loads, which differentiates it from sibling tools like adr_lookup or adr_lq_eq_check that serve different ADR functions.

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 guidance on when to use: for single substance (provide un_number + quantity) or mixed loads (provide items array). It does not explicitly state when not to use or mention alternatives, but the context of sibling tools includes adr_lookup and adr_lq_eq_check, which are clearly different in purpose.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is clearly safe and non-destructive. The description adds the specific database year (ADR 2025) and the number of entries, providing context beyond annotations. It also lists the returned fields (hazard class, packing group, labels, etc.), which adds transparency about output format.

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 purpose, and every sentence adds value. No superfluous 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 has no output schema, the description compensates by listing key return fields. With 3 parameters all optional, the description clarifies the lookup logic. It is sufficient for an agent to understand how to 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?

Schema coverage is 100%, so the schema already documents all three parameters. The description adds meaning by explaining the two distinct usage modes (exact lookup vs. name search) and that hazard_class is a filter. However, it does not elaborate on the format or constraints beyond what the schema provides, earning a baseline 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?

The description clearly states it looks up dangerous goods from the ADR 2025 database, specifies the 2,939 entries count, and explains the two lookup methods (exact by UN number or name-based search). It distinguishes itself from siblings like adr_exemption_calculator and adr_lq_eq_check by focusing on lookup of substance details.

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 each parameter (UN number for exact lookup, search term for name-based), but does not explicitly tell when not to use this tool or mention alternatives for hazardous goods beyond lookup. It lacks guidance on combining parameters or required fields.

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=true, idempotentHint=true, and destructiveHint=false, establishing this as a safe, non-mutating check. The description adds behavioral context: it performs a qualification check for exemptions under specific ADR regulations, handles multiple items at once, and implies the tool does not modify any data. No contradiction with annotations exists.

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: three sentences, front-loaded with the core purpose, and zero wasted words. Each sentence adds distinct value: the first states the purpose, the second explains LQ applicability, the third explains EQ and batch capability.

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 check tool with no output schema, the description is complete enough: it covers purpose, modes, legal references (ADR sections), and batch processing. The schema fully documents all parameters. Minor gap: no mention of what the output looks like (e.g., boolean or list), but this is acceptable as output schema is absent.

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

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

The schema has 100% description coverage, so the schema already documents all parameters with descriptions. The description adds semantic context about LQ/EQ exemptions (referencing ADR sections) but does not provide additional parameter-level meaning beyond what the schema already offers. Thus a score of 3 is appropriate per the guidelines.

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 'Check' and the resource 'dangerous goods qualify for ADR Limited Quantity (LQ) or Excepted Quantity (EQ) exemptions'. It distinguishes between related but distinct checks (LQ vs EQ) and mentions batch processing ('multiple items at once'), differentiating it from siblings like adr_exemption_calculator or adr_lookup which may serve broader or different purposes.

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 when to use this tool: to check if dangerous goods qualify for LQ or EQ exemptions. It describes the two modes (LQ and EQ) and their applicability (LQ for inner packaging per ADR 3.4, EQ for very small quantities per ADR 3.5). However, it does not explicitly state when NOT to use this tool or mention alternative tools, though the sibling context implies alternatives exist.

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 does not need to restate safety. The description adds behavioral context by noting the tool searches a specific set (6,350+ airlines) and explains what an AWB prefix is, which helps the agent understand the return type.

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 that are front-loaded with the key purpose, followed by a useful clarifying example. Every word earns its place; 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 is a simple lookup with no output schema and annotations cover safety, the description is complete. It informs the agent what the tool does, what parameters are available (implied), and adds an example. No additional behavioral details are needed.

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 each parameter has a clear description (e.g., 'Exact IATA code (2 chars)'). The tool description adds general context but does not add significant meaning beyond that already in the schema. 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 it searches airlines by multiple criteria, including name, codes, AWB prefix, or country. It includes a concrete example (176 = Emirates) and distinguishes this tool from siblings like 'adr_lookup' or 'uld_lookup' by specifying its unique search targets.

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 when to use the tool (to look up airline or AWB information) and lists search parameters, but does not explicitly state when not to use it or provide alternatives. However, given sibling tools have distinct purposes (e.g., 'hs_code_lookup' for HS codes), confusion is unlikely.

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. The description adds that it returns per-item breakdown, totals, trailer utilisation, and suggested vehicle, providing 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?

Two concise sentences with no wasted words. The first sentence states the purpose, the second lists outputs, making it 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?

Covers purpose and return values adequately. However, it lacks mention of usage context vs siblings, which is a minor gap for a tool with many similar calculators.

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 does not add parameter-specific details 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 it calculates CBM, weight, LDM, and chargeable weight for multi-item mixed consignments, distinguishing it from sibling calculators like cbm_calculator or ldm_calculator that handle single items.

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 guidance on when to use this tool versus alternatives. With many sibling calculators, the description should indicate that this is for multi-item consignments and others for single items.

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 reiterate safety. It adds context about return fields (dimensions, capacity, etc.) and number of types, which is valuable 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 communicates the tool's purpose, scope, and output. It is front-loaded with the core function ('Get ISO shipping container specs') and adds specific details 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?

Given the tool's simplicity (one optional parameter, straightforward output), the description fully covers what the agent needs to know. No output schema is needed, and the tool's behavior is completely documented.

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%, and the description provides example slugs like '20ft-standard' and '40ft-high-cube', as well as behavior when omitted. However, the description does not add much more than 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 it retrieves ISO shipping container specs, listing 10 specific types such as '20ft' and '40ft HC', and specifies the output includes dimensions, capacity, weight limits, and pallet counts. This leaves no ambiguity about the tool's purpose and resource.

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 tells when to use it (when needing container specs) and mentions the option to omit the type to list all. It doesn't explicitly exclude alternatives, but among siblings like uld_lookup or pallet_fitting_calculator, its purpose is distinct.

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=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds context about the dataset size (6,940 codes) and input flexibility. 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 two sentences, front-loading the core purpose and supported inputs. No filler, 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?

Given the tool has no output schema but three optional parameters, the description adequately covers usage. It could mention that results return matching codes and descriptions, but the schema descriptions already cover input. The complexity is low.

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% (code, query, section all described). The description adds meaning by clarifying HS codes are 6-digit, and mentions that an exact code or search term can be provided. This adds value beyond the schema's brief 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 clearly states the tool searches 6,940 Harmonized System tariff codes, specifies HS codes are 6-digit international product classification codes for customs, and provides specific details about inputs (search term or exact code). This differentiates it from siblings like container_lookup or incoterms_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 clear context for use (search by term or exact code) but does not explicitly state when not to use this tool versus alternatives like adr_lookup or vehicle_lookup. However, the niche domain (HS codes for customs) implicitly guides appropriate 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, idempotentHint, and destructiveHint false, so the description does not need to repeat that it is a read-only operation. The description adds value by explaining the categorization of incoterms (any mode vs. sea-only), which aids the agent in understanding the tool's behavior beyond the schema.

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

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

The description is two sentences, front-loaded with the main purpose. It is concise but could be slightly more structured; however, it earns its place without 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 no output schema, the description could mention return format, but the tool is simple (lookup by code or category). The context of 11 rules and mode categorization is sufficient for a tool of this 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 description coverage is 100%, so the schema already documents both parameters. The description adds value by listing examples of incoterm codes for the 'code' parameter and clarifying the 'category' values. While not extensive, it provides meaningful context 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?

Description clearly states the tool looks up Incoterms 2020 trade rules, specifies the number of rules (11), and distinguishes between mode applicability (7 for any mode, 4 for sea-only). This provides a specific verb+resource with clarifying details that differentiate it from sibling 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 lists all 11 incoterm codes, which helps the agent know valid inputs. However, it does not explicitly state when to use this tool over siblings like adr_lookup or hs_code_lookup, though the context (trade rules vs. dangerous goods or HS codes) is implied.

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 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 indicate read-only, idempotent, non-destructive behavior. The description adds that it uses live GOV.UK Trade Tariff data, implying external dependency and potential latency. No contradictions. It could mention rate limits or caching but sufficient given 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?

Three sentences: first states purpose, second data source, third outputs. No fluff, front-loaded, 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?

Missing output schema is compensated by description listing return values. Does not cover error handling or invalid inputs, but for a calculator tool with annotations, it is largely complete. Almost a 5 but small gap.

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 6 parameters. The description adds context about CIF value computation and outputs but does not explain each parameter's role beyond schema. Thus 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 estimates UK import duty and VAT for a given commodity code and origin country using live data. It lists specific outputs and flags preferential rates/restrictions, distinguishing it from sibling tools like adr_exemption_calculator or hs_code_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 UK import tax calculations but does not explicitly state when to use this tool versus alternatives, nor does it provide 'when not to use' guidance or mention prerequisites like having a valid commodity code.

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, destructiveHint as false, indicating a safe read operation. The description adds value by specifying return fields: dimensions, weights, volume, aircraft compatibility, and deck position. This goes beyond annotations to inform the agent about output content.

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, front-loaded with the purpose and then providing examples and return fields. No wasted words, efficient and clear.

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 lookup tool with no output schema and high schema coverage, the description covers the main functional aspects: what it does, what inputs (implicitly) and what it returns. No missing critical information for an agent to use 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 description coverage is 100%, so the parameters already have descriptions. The description mentions 'deck position' but does not add new param details beyond the schema. It serves as a high-level overview but without deeper 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 verb 'Look up' and the resource 'ULD specs', with examples of 16 types and what is returned. It is specific to air freight ULD, distinguishing it from sibling tools that cover different domains. However, it does not explicitly differentiate from similar lookup 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 provides examples of ULD codes, but no explicit guidance on when to use this tool versus alternatives. Usage is implied by the tool name and domain, but there is no when-not or alternative reference. Sibling tools are different enough that confusion is unlikely, but explicit guidance would be better.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety traits are covered. The description adds context about supported unit types but does not explain error handling or precision.

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, concise sentence that lists all relevant information without redundancy. It efficiently communicates the tool's purpose and supported units.

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 parameter set (value, from, to) and no output schema, the description sufficiently covers the tool's functionality. It lists all supported units and conversion categories, making it complete for agent 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?

Schema has 100% coverage with basic descriptions for all three parameters. The description adds value by listing supported units and conversion types, but does not detail each parameter beyond what is 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 clearly states the tool converts between freight units and lists specific categories (weight, volume, length, freight) with examples, distinguishing it from sibling calculators like cbm_calculator or chargeable_weight_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 general conversion use and lists unit options, but does not explicitly state when to use this tool versus other calculators. However, the unit categories help clarify scope.

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, so the tool is a safe read operation. The description adds context about data scope (116,129 locations) and function types, which aligns with annotations without contradiction.

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 concise and front-loaded with key information. It uses clear, scannable sentences. Could be slightly more structured (e.g., bullet points) but effective.

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, description adequately explains search scope and criteria. It covers what to search and how to filter, but does not mention result format or pagination beyond 'limit' param. Still 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?

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the scale (116,129 locations) and enumerating location types, but param details are already in schema. Slightly above baseline.

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: searching 116,129 UN/LOCODE transport locations worldwide. It lists supported location types (seaports, airports, etc.) and search criteria (name, code, country, function type), making it distinct from siblings like airport_lookup or vehicle_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 clear usage context: search by name, code, country, or function. However, it does not explicitly state when to avoid this tool or mention alternatives among siblings (e.g., use container_lookup for containers).

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?

While readOnlyHint and idempotentHint are already set, the description confirms read-only behavior and adds context about the scope (road freight vehicles and trailers) and return data (internal dimensions, payload limits, etc.), which annotations 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?

Description is extremely concise: two sentences, no filler. First sentence states purpose, second lists types and outputs. Every word contributes.

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 low complexity, full parameter coverage, and read-only annotations, the description is sufficient. No output schema exists, but the return values are clearly stated in the description.

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

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

Schema description coverage is 100% and all parameters have clear descriptions with enums where applicable. The description adds value by listing example vehicle types and expected outputs, complementing 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?

Description clearly states 'Look up road freight vehicle and trailer specs' using a specific verb-resource combination. It lists 17 types and specifies return values (dimensions, payload, pallet capacity, features), distinguishing it from other lookup 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?

Description implies usage for vehicle spec lookups but does not explicitly state when to use this tool vs sibling tools like container_lookup or uld_lookup. No alternative suggestions are given.

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