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?

The description clearly states the tool is a calculator (read-only, idempotent) and lists outputs: per-item breakdown, grand totals, trailer utilisation, suggested vehicle. Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds details about what the tool returns, 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 two sentences, front-loading the purpose with specific metrics. Every sentence adds value: first sentence lists calculations, second describes output structure.

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 enumerates return values (per-item breakdown, grand totals, trailer utilisation, suggested vehicle) sufficiently for an agent. It covers purpose, outputs, and usage context. However, it could mention that items with missing stackability default to non-stackable.

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 description doesn't need to repeat parameter meanings. It adds no extra detail beyond the schema. Baseline 3 is appropriate for high coverage.

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 total CBM, weight, LDM, and chargeable weight for consignments with multiple items. It differentiates from sibling calculators like cbm_calculator, ldm_calculator, and chargeable_weight_calculator by combining these metrics and returning per-item breakdown, totals, trailer utilisation, and suggested vehicle.

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 when calculating consignment-level metrics for multi-item shipments. However, it does not explicitly state when to prefer this tool over individual calculators (e.g., for combined results vs. single-metric needs) or mention prerequisites like dimensions and weights.

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, and destructiveHint=false, so the agent knows it's safe. The description adds behavioral context by stating it chains multiple calculations into one response, which implies it may be resource-intensive. However, it does not disclose potential side effects (e.g., rate limits, whether it calls external APIs) beyond what annotations 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?

The description is a single, dense sentence that efficiently conveys purpose, inputs, and outputs. It uses bullet-like phrasing (— chains, Accepts, Returns) without wasted words. Every part earns its 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 the complexity of the tool (7 parameters, nested objects, no output schema), the description provides a complete overview of what it does and what it returns. It does not explain the return format in detail, but since no output schema is provided, the description covers enough for an agent to infer the structure. Sibling tools show this is a composite counterpart, which is adequately contextualized.

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 documents all parameters. The description provides high-level context but does not add meaning beyond the schema. It lists output types (per-mode calculations, DG compliance, customs estimates) which helps understand what parameters are used for, but this is implied by the schema 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 is a composite shipment summary that chains multiple calculations (CBM, weight, LDM, ADR compliance, UK duty) into one response. It specifies the input types (multiple items, transport mode) and output categories (per-mode calculations, DG compliance, customs estimates). This effectively distinguishes it from sibling tools that perform individual calculations.

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 comprehensive shipment summary is needed, covering logistics and customs. By listing the chained calculations, it suggests when to use this tool instead of individual sibling calculators (e.g., cbm_calculator, adr_lookup). However, it does not explicitly state when not to use it or provide alternatives for simpler queries.

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, aligning with a calculator that reads data. The description adds that it uses live GOV.UK data, which is useful context, but does not mention potential rate limits, caching, or failure modes. With good annotations, the description provides moderate additional transparency.

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: purpose, data source, output list, and additional flags. It is front-loaded with the main action, and 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?

Given no output schema, the description lists key return fields (duty, VAT, landed cost), which is helpful. With 6 parameters, it covers the core inputs. It mentions preferential rates and restrictions, adding context for trade compliance. A more detailed behavior note on calculation method would push to 5.

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 each parameter already has a description. The tool description does not elaborate on parameter usage beyond listing some outputs. For example, it doesn't explain how incoterm affects CIF calculation or when freight/insurance defaults are used. 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 specifies the tool estimates UK import duty and VAT using live tariff data, clearly naming the commodity code and origin country inputs. It lists specific outputs (CIF value, duty rate/amount, VAT rate/amount, total import taxes, landed cost) and flags preferential rates/restrictions, differentiating it from siblings 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 use for UK import cost estimation, and includes filtering details (commodity code, origin country). It does not explicitly state when not to use it versus siblings like adr_lookup or unit_converter, but the purpose is specific enough for an agent to infer context.

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, so the safety profile is clear. The description adds that the tool returns specific info (dimensions, weights, volume, compatibility, deck position), 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?

The description is two sentences, no wasted words. The first sentence clearly states the purpose and scope, the second lists what is returned.

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 that the tool has no output schema, the description covers the key return values. However, it doesn't mention that omitting parameters returns all ULDs, nor does it specify that results are in a list format. Still, it is mostly complete 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?

The input schema covers all 3 parameters with descriptions and enums (100% coverage). The description adds nothing beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool looks up ULD specs, names 15 types and examples, and lists the returned dimensions, weights, volume, aircraft compatibility, and deck position. This distinguishes it from sibling tools like container_lookup and 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 implies the tool is for looking up ULD specs when needed but does not explicitly state when not to use it or suggest alternatives. However, the context of sibling tools shows clear distinct domains.

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.