Fortitude21 Dangerous Goods Tools

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds important behavioral context beyond annotations: the all-or-nothing refusal when any line cannot be read, and the fact that the response lists transport categories when packing_group is needed. It does not describe rate limits or detailed response structure, but it significantly improves 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 compact and front-loaded: it states what is calculated, the decision threshold, coverage, refusal behavior, and the packing_group requirement in only a few sentences. No sentence feels wasted.

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

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

For a single-parameter computational tool with no output schema, the description covers purpose, scope, failure behavior, and the main conditional input requirement. It could go further in explaining the output fields, but it provides enough context for an agent 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 description coverage is 100%, and the schema already documents lines, UN numbers, package counts, packing groups, and quantity per package. The description reinforces the packing_group condition but adds little syntax or format detail beyond the schema, so baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: total ADR 1.1.3.6 points for a vehicle load and determine whether the small-load exemption applies. It also scopes the tool to 92 UN numbers and names related concepts like transport category and packing group, making it distinguishable from sibling tools such as un_number_packaging.

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

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

The description clearly explains the context in which the tool is used: vehicle loads, small-load exemption checking, and cases where packing_group is required. It does not explicitly name alternative sibling tools or when-not-to-use cases, so it falls short of full routing guidance.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, so the safety profile needs no repetition. The description adds value beyond that: it states the output units and content (litres, governing rule, passing spill pallets) and the error behaviour of returning 16 region codes for an unrecognised region. It leaves the default 'mode' (bund vs tray) and the definition of a 'passing' pallet unexplained.

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

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

Three sentences, front-loaded with the action and result, then prerequisites, then the failure mode. Dense but every clause carries information; the one long region enumeration is the only mildly costly stretch, though it does real work by pre-empting invalid inputs.

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 9-parameter, no-required-fields, no-output-schema calculation tool, the description covers what is computed, what is returned, required input, and error handling — enough to call it correctly. The remaining gaps are the unmentioned bund/tray mode and what the container-size parameters do, both of which the schema does cover.

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 every parameter is already documented, which sets the baseline at 3. The description contributes the full region enumeration ('England, Wales, ... world') and confirms that at least one of the four count parameters is required — a constraint the schema cannot express since nothing is marked required. Other semantics (mode, liquid, sizes) are left entirely to 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?

Specific verb + resource: 'Apply the secondary containment rule ... to the containers stored together, and return the minimum sump capacity in litres'. It also names the concrete return payload (capacity, governing rule, passing spill pallets), which is far more than a restatement of the name. No sibling tool (ADR points, UN packaging marks, IBC inspection dates) does anything similar, so the boundary is obvious.

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

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

Gives real preconditions — 'Needs at least one container count (drums, ibcs, small or other)' — plus the fallback for an uncovered region, so an agent knows both how to call it and what happens on failure. It stops short of comparing itself to siblings or telling the caller when to prefer a different tool, which keeps it at 4 rather than 5.

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

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

Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the safety bar is low, and the description adds genuine domain caveats beyond them: results reflect publisher statements only, UN approval is per design type and the authority decides plant coverage. It does not describe return shape or empty/missing-data behavior, which keeps it short of a 5.

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 payload information is front-loaded in the first sentence, and the disclaimer sentence earns its place by preventing over-reading of the results. It is dense and slightly convoluted in the opening clause, but there is no filler.

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

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

With only three fully documented parameters, a read-only annotation set, and no output schema, the key risks an agent faces are over-interpreting the result as a compliance verdict or a certification guarantee — and the description addresses both explicitly. Nothing needed to call it correctly is absent.

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

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

Schema coverage is 100% with clear per-parameter descriptions, so the baseline is 3. The description adds meaning by framing the tool around 'the information a quotation still needs', which implies the optional intended_contents and destination_market feed that gap analysis rather than filtering the product lookup.

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 enumerates the concrete outputs for a single product: published certification and cautions, exact UN status scope, existing documents, and outstanding quotation gaps. This is specific enough to separate it from get_product_details and get_product_documents, though the opening noun phrase ('For one product, what Fortitude21 publishes about...') is not a clean verb+resource statement and no sibling is named.

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?

Strong negative scoping: it explicitly says it does NOT state what any market requires and does NOT confirm Fortitude21 holds a certificate, and it redirects to 'the dangerous goods tools on this same server' for the regulations themselves. What is missing is naming those tools (decode_un_packaging_mark, un_number_packaging) or stating when to prefer get_product_details/get_product_documents instead.

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

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

Annotations already cover read-only, idempotent, closed-world and non-destructive behavior, so the description is free to add the genuinely non-obvious trait: results are split into fully-comparable rows and partial rows with missing products named, so a blank is never misread as a worse value. That is real behavioral context beyond the annotations, though error handling for invalid SKUs or out-of-range counts is unstated.

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

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

Three sentences, front-loaded with the core operation, and each carries distinct information (scope, return shape, non-ranking caveat). The middle sentence is long and clause-heavy, but nothing is redundant.

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

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

With no output schema, the description carries the burden of explaining returns and does so: comparable rows versus separately returned partial rows with missing products named. Combined with the non-ranking caveat, an agent has enough to call it and interpret the result 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% and the single parameter already documents 'Two to six part numbers or slugs', so the description's restatement of the 2-6 bound adds little. It does imply that only attributes shared across all supplied SKUs are compared, which slightly enriches the meaning of the list, but the baseline of 3 applies when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Compare two to six products') plus a precise scope: only attributes every product publishes. That scope cleanly separates it from get_product_details or search_products, which an agent can tell apart without opening a schema.

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

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

The closing sentence implies the tool should not be used to pick a 'best' product, which is useful interpretive guidance, but it never names an alternative tool or states an explicit when-to-use/when-not-to-use condition relative to the siblings (e.g. get_product_details for a single SKU). Usage is implied rather than directed.

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 openWorldHint=true and destructiveHint=false, and the description adds real context on top: SKUs are validated against the catalogue, missing information comes back in the response, and consent is a hard gate with a stated rationale ('the agent calling this is not the buyer'). The one omission is duplicate behavior – annotations say idempotentHint=false but the description never warns that a repeated call creates a second enquiry.

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 negative scope ('nothing else: no price, no stock, no delivery date, no order') is front-loaded in the second sentence where it does the most work. Each sentence carries distinct information; the only slack is the slightly wordy closing clause about information being 'named back in the response'.

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 an 11-parameter, non-idempotent, open-world write with no output schema, the description covers enough: it sketches the return value ('a reference back') and the validation loop without needing a schema. What it lacks is any statement about duplicate submissions or what the reference looks like, which an agent retrying after a timeout would want.

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, and the description earns a point above it by explaining *why* consent must be true rather than restating that it must be – a semantic the schema's own one-liner only partially conveys. It also gives meaning to the `lines` payload ('every part number is validated against the catalogue'), though the other nine parameters are left entirely to 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?

States a specific verb and resource ('Submit a quotation request for one or more products') and immediately scopes what is produced ('get a reference back'). It also draws a hard boundary against pricing and ordering, which is what separates it from siblings like get_product_pricing and check_product_requirements in an agent's mind.

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 when-not is unusually explicit: 'accepts no price, confirms no stock, commits no delivery date and creates no order' tells the agent not to reach for this tool when it needs a price or availability. It stops short of naming the sibling tools to use instead for those needs, so the routing is implied rather than spelled out.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile needs no restating. The description adds useful behavioral context beyond the annotations: tolerance for marks with or without the 'UN' prefix, acceptance of bare codes like 3H1, and the ADR 2025 basis for the compatibility check.

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?

Opens with the core action and what it decodes, then layers the optional compatibility check and the input-source caveat. Dense and front-loaded, though the parenthetical list of mark variants is slightly long relative to the rest.

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

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

With no output schema, the description compensates by enumerating the components returned for a decoded mark, so an agent knows what to expect. It is silent on failure behavior for an unparseable mark, which is the only notable gap for this two-parameter 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 coverage is 100%, so both parameters are already documented, making 3 the baseline. The description still adds meaning: it clarifies that 'mark' can arrive with or without the UN prefix or as a bare packaging code such as 3H1, and frames 'un' as a compatibility check rather than a lookup key.

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

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

States a specific verb (read/decode) and resource (UN packaging mark), then enumerates exactly what gets parsed: packaging code, performance level, density/mass, test pressure, year, state, maker, plus IBC/large packaging/salvage/reconditioned variants. This is far more specific than the sibling names imply and lets an agent tell it apart from un_number_packaging or ibc_inspection_dates.

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

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

Explicitly says how to use the optional UN number ('add a UN number to check whether the container may carry that substance under ADR 2025') and gives a genuine when-not rule: if the user hasn't read the mark off the container, ask for it rather than passing a container description. It does not name sibling tools as alternatives, which keeps it short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuine behavioral context: the result set is fixed at twelve, it is bipartite, and the 'exactly one category, may be cross-listed' invariant that explains why filtering by slug can return duplicates.

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

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

Two sentences, front-loaded with the return shape before the routing advice. The cross-listing clause earns its place because it prevents a misreading of the data during filtering.

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

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

With no output schema, the description compensates by enumerating the returned fields (slugs, taglines, counts) and the family split. Combined with annotations covering safety and idempotency, an agent has enough to call it and use the result correctly; only the omitted-parameter default is unspecified.

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 0%, so the description must carry the load, and it does explain the two enum values semantically ('container, what the liquid sits in' vs 'system, everything around it') — meaning the bare enum tokens do not convey. It does not state what happens when 'family' is omitted (presumably all twelve), which is the one remaining gap.

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

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

States a specific resource (the twelve product categories) plus exactly what each record contains (slugs, taglines, product counts) and how they are partitioned (container vs system). This is clearly distinguishable from siblings like get_product_details or search_products, which return per-product data rather than the taxonomy.

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

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

Explicitly routes the agent onward: 'Use the slugs to filter search_products,' which names the alternative and the follow-up step. It also warns that products may be cross-listed, which affects filtering strategy. It stops short of saying when *not* to call this (e.g., if you only need one product's category, get_product_details may suffice).

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

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

Annotations already cover read-only, idempotent, closed-world and non-destructive, so the safety bar is low. The description still adds real value by disclosing the sentinel behavior: unpopulated fields come back as 'available on request' rather than omitted, so a missing value is never read as zero. It does not cover failure behavior for an unknown SKU, but the non-obvious output semantics are clearly stated.

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 tight sentences in a clear order: what is returned, what input is accepted, then how absent values are represented. The long enumeration is dense but every item is a real payload section an agent might ask for; nothing is redundant enough to cut.

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?

There is no output schema, so the description carries the burden of describing the return payload, and it does so comprehensively, including the provenance of specification figures and the 'available on request' convention. For a single-parameter read tool with full annotation coverage, nothing an agent needs in order to call or interpret it is missing.

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

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

With one parameter at 100% schema description coverage, the schema already documents that sku accepts an F21 part number or a product slug. The description restates those two accepted forms without adding syntax guidance, URL-extraction hints, or resolution order between the two forms. Baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource framing ('The complete published record for one product') and enumerates exactly what that record contains: identity, specifications with provenance, spec tables, orderable units, images, documents, and pricing. That scope implicitly separates it from narrower siblings like get_product_pricing and get_product_documents, though none are named explicitly.

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

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

It gives the accepted input forms (a slug from the product URL or an F21 part number), which tells an agent how to call it, but it never states when to reach for this tool versus search_products, get_product_pricing, or get_product_documents. Usage is inferable — fetch the full record for a single known product — rather than stated.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful non-annotation context: documents are not generic downloads and are tied to a specific design and production run, which explains why a request step is needed.

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 purpose is front-loaded and both sentences contribute useful information. The first sentence is a long conditional list and the closing phrase is slightly awkward, but there is no major waste.

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

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

Given one parameter, rich annotations, and no output schema, the description does enough: it lists the document categories and explains why generic files are not published. It is somewhat vague on the actual request mechanism and return shape, but not severely incomplete.

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

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

The single sku parameter is fully documented by the schema as 'An F21 part number or product slug'. The description adds no additional syntax, format, or lookup 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 resource and scope: which documents exist for a product and how to request them, including conditional document types. It is specific enough to distinguish from sibling product tools, but it does not explicitly name alternatives or contrast itself with them.

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

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

Usage is implied by 'for a product' and by the document-specific conditions, but there is no explicit when-to-use guidance, no exclusions, and no reference to alternative tools such as get_product_details or check_product_requirements.

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

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

Beyond the read-only annotations, the description discloses important behavior: prices are indicative, carry binding=false, exclude freight/duty/taxes, and the highest quantity band is always a quotation rather than a figure. It also explains that priced-on-request products return no number at all, which meaningfully sets expectations.

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

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

The description is dense but front-loaded, opening with the returned commercial terms and then adding critical caveats about indicativeness and quotation behavior. Every sentence contributes to correct interpretation.

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

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

With no output schema, the description does the necessary work by enumerating the returned fields and explaining the binding, exclusion, and quantity-band caveats. It gives an agent enough context to call the tool and correctly interpret its results.

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, but the description adds useful meaning about quantity by explaining quantity bands and that the highest band is treated as a quotation. It does not add format details beyond the schema, but it does clarify how quantity affects returned pricing.

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

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

The description states a specific resource and scope: published commercial terms for one product, including pricing type, currency, MOQ, bands, validity, Incoterms, and lead time. It also clearly distinguishes indicative pricing from a quotation, though it does not explicitly name the sibling tool create_quote_request for binding quotes.

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

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

It gives clear usage context by framing the result as indicative pricing and warning that most products are priced on request and return no number. It does not explicitly say when to use this versus creating a quote request, but the indicative-versus-quotation distinction supplies practical guidance.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive) and closed-world scope, so the description focuses on the useful non-obvious behavior: it derives future due dates rather than returning stored data, accepts several date formats, and scopes the five-year life rule to UN/ADR plastic and composite IBCs. It doesn't say what happens on missing or unreadable input, which keeps it short of a 5.

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

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

Two sentences, front-loaded with the computed outputs, with no filler. The parenthetical qualifiers make the second sentence dense but each phrase carries 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?

For an eight-parameter, no-required-field computation tool with no output schema, the description tells the agent what it returns (dates) and in what format. Behavior on incomplete or inconsistent inputs is the only meaningful omission.

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

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

Schema description coverage is 100%, so the baseline would be 3, but the description adds real meaning: accepted date syntaxes (MM/YYYY, 'March 2024', YYYY-MM) that the schema omits, the made-or-mark alternative, and the tie between the 'regime' parameter and plastic/composite IBCs. It still doesn't clarify how insp, leak, repair, and bottle interact to select a due date.

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?

It names a specific verb ('Work out') and a precise set of computed results: next leakproofness test, 2.5-year and 5-year inspections, last fill month, and end of five-year life. That is far more concrete than the sibling 'decode_un_packaging_mark', which only reads a mark, so an agent can distinguish them without opening either schema.

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

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

It states an input precondition ('Needs made, or a mark it can read the month of manufacture from'), which guides the made-vs-mark choice. But it never says when to use this versus the sibling decode_un_packaging_mark tool, nor does it list exclusions or alternatives.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is fully covered. The description adds genuinely new behavioral context: results include 'a margin', and the water path follows 'Sphere and national advice' standards, plus it hints at the return value ('how many jerry cans that takes'). It stops short of describing defaults or units of the returned figures.

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

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

A single front-loaded sentence that leads with the deliverable and then the scenarios; there is no filler. It is dense to the point of being parenthetical-heavy, which slightly hurts scanning, but every clause carries 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?

For a 17-parameter tool with zero required parameters and no output schema, the description covers the major modes but leaves key gaps: it does not say which parameters are needed per scenario, how days vs weeks or volume vs scenario interact, or what the returned quantity looks like. An agent could pick the wrong input set and still be within the text of 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 coverage is 100%, so per-parameter meaning is already documented and the baseline is 3. The description goes beyond that by explaining how parameters combine into a computation (people x days x litres for water; distance/consumption, hours/consumption, or kVA/load for fuel), which is coordination semantics the flat schema does not convey.

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

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

The description states a concrete verb ('work out') and a concrete resource ('how much water ... or fuel to hold, and how many jerry cans that takes'), and it even sketches the calculation inputs (people x days x litres, distance/consumption, generator kVA). The purpose is unmistakable, but it never contrasts itself with the sibling tools (bund_size, adr_1000_points, ibc_inspection_dates), so there is no explicit sibling differentiation.

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 parenthetical breakdown implies which input family belongs to which scenario (water = people/days/rate, fuel = distance/consumption, hours/consumption, or kVA), which is useful routing. However there is no explicit statement of when to use this versus an alternative, no prerequisite conditions, and no exclusion such as what to do if you already know the volume.

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, non-destructive and closed-world, so safety is covered; the description adds genuinely useful semantics beyond them: terms are ANDed, products lacking a filtered attribute are excluded rather than assumed to match, and an empty result has a precise meaning. It does not discuss pagination limits or result ordering beyond what the schema provides.

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

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

Three sentences, front-loaded with the scope and facets, then matching semantics, then return shape. The material list is long but earns its place by anchoring search relevance; no filler sentences.

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

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

With 11 optional parameters, no output schema and no required arguments, the description supplies enough to call the tool correctly: what is searchable, how filters combine, and what comes back (a per-product summary plus a url). Minor gaps remain around pagination defaults and sort behaviour, which the schema only partially covers.

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 82%, so the schema already documents nearly every parameter, including material family resolution and category slugs. The description restates the filter dimensions and units (litres) and clarifies the AND/conjunctive behaviour of combined filters, but adds no new value per individual parameter, so the 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?

States a specific verb (Search) plus the exact resource (the Fortitude21 liquid containment catalogue) and enumerates the product families covered. It clearly differs from siblings such as get_product_details, get_product_categories and compare_products without the agent needing the schema.

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

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

It makes the intended use clear – faceted filtering of the catalogue by material, capacity, category, application, certification and pricing type – and points to get_product_categories as the source of valid category slugs. It notes that results are summaries with a url for the full record, implicitly routing detail lookups elsewhere, but never states explicit when-not conditions or names alternatives such as check_product_requirements.

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

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so safety needs no restating. The description adds genuinely non-structured context: the dataset covers only 157 UN numbers and only liquids, and the ambiguity behavior of name lookups is disclosed. It does not mention latency or any failure/empty-result behavior.

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

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

Three sentences, front-loaded with the action and source, then the payload, then the edge case. Zero filler; every sentence carries information an agent needs before calling.

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

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

No output schema exists, so the description carries the return-value burden and discharges it by listing the returned fields and the per-container allowed codes and size. The dataset's coverage boundary (157 liquids) and the ambiguous-name path are both stated, leaving nothing essential missing for a 2-optional-param read 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 coverage is 100% with format examples for both params, so the baseline is 3. The description earns above that by explaining the interaction between un and name: name may map to several entries, in which case candidate UN numbers come back and un must be supplied.

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?

Specific verb and resource: look up a UN number or substance name in ADR 2025 Table A plus its packing instructions. It goes further and enumerates what is returned (class, packing group, limited quantity, UN mark level, per-container UN codes and max litres), so an agent can distinguish it from decode_un_packaging_mark without opening any schema.

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

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

Gives explicit follow-up guidance: an ambiguous substance name returns candidate UN numbers and you must call again with un= set to one of them. It does not, however, name a sibling alternative or say when to prefer decode_un_packaging_mark or jerry_can_quantity instead, so routing guidance is partial.

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