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

With no annotations, the description carries the behavioral disclosure burden. It openly states that the tool does not decide whether a modifier applies, names the external API source, and describes the returned data. It could add more detail about failure modes or exact response structure, but the key behavioral caveat is explicit.

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 definition is a single dense sentence that front-loads the core purpose and output. It contains no filler, though the long em-dash construction makes it slightly harder to parse than a short opener followed by a separate caveat.

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 two-parameter lookup tool with no output schema, the description gives enough to select and call it correctly, including the important modifier-context behavior. It could be more complete by explicitly noting the optional packingGroup parameter and describing the exact return shape, but the schema covers the parameter and the behavior is well explained.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces that unNumber drives the lookup and that context, not an input parameter, decides modifier fit, but it adds little detail about packingGroup 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 states a specific action (builds a base proper shipping name) for a specific resource (UN number from api.kocie.mba) and clearly explains the output (list of modifiers with conditions). This distinguishes it from sibling lookup/search tools even without naming 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?

The description makes clear the tool is for constructing a PSN and that modifier selection depends on user-provided shipping context. However, it does not explicitly say when to choose this tool over related siblings such as lookup_un or search_adr, nor does it state exclusions.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It communicates that the tool 'calculates whether' goods fit the exemption and imposes unit constraints, but it does not state the return value shape or behavior on invalid/empty input.

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

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

Two concise sentences with zero redundancy. The core purpose is front-loaded, and the input requirements are compressed into the second sentence without unnecessary detail.

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

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

The description covers scope, required inputs, and the relevant unit rules. However, with no output schema and no annotations, it should more explicitly state what the tool returns (e.g. a boolean verdict or a detailed result object), leaving this as the main completeness gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds practical workflow meaning: transportCategory is meant to be obtained earlier via lookup_un, and quantities follow the rules of 1.1.3.6.3. This helps an agent prepare items beyond what the schema literally states.

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 the specific verb 'Liczy' and clearly identifies the exact resource: exemption 1.1.3.6 for a set of goods on one transport unit. This is precise enough to distinguish the tool from sibling lookup/decoding tools.

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

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

It explains the prerequisite workflow: transportCategory must been obtained beforehand, e.g. via lookup_un, and quantities must be in kg or litres per rule 1.1.3.6.3. It gives clear context for when to use the tool but does not explicitly list alternatives or exclusion cases.

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?

No annotations are provided, so the description carries the burden of disclosing behavior. It does so by explaining that unambiguous codes yield a hard verdict, while ambiguous codes return both descriptions for interpretation. This is valuable behavioral nuance beyond a simple 'checks compatibility' statement.

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: one sentence states the purpose, and one sentence adds the important behavioral nuance about verdict types. It contains no filler and is easy to parse quickly.

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

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

For a 3-parameter tool with no output schema and no annotations, the description covers the core behavior and the output ambiguity aspect. It could mention exact return formats or edge cases, but the provided information is sufficient for an agent to use the tool in the intended context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context about mixedPacking code format and example values, but parameter meaning is already fully covered by the schema. No significant additional parameter semantics are provided.

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

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

The description names a specific action (checks whether two goods can be packed together) with a specific resource (mixedPacking codes) and gives a concrete example. It is clearly distinct from the sibling tools, none of which address mixed-packing compatibility.

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 is clear that this tool is for deciding whether two goods with mixedPacking codes can share a shipment item. No explicit alternatives or when-not-to-use conditions are given, but the context is specific enough that an agent can infer when to call it.

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

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

There are no annotations, so the description carries the full burden. It does disclose the core limitation of the rule scope, which is important. However, it does not state the return value (e.g., boolean), how invalid codes are handled, or any side effects, leaving some behavioral ambiguity.

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 concise sentences. The first sentence front-loads the main purpose, and the second delivers the critical limitation. There is no filler or redundancy.

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

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

For a simple two-parameter comparison tool without an output schema, the description covers the purpose, the regulatory basis, and the key exclusions. It does not explicitly state the return type, but the comparison semantics are inferable from the wording, making it largely sufficient for correct 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?

The input schema already describes both parameters with 100% coverage, so the baseline is 3. The description merely rephrases the parameters ('alternatywa', 'wymaganej') without adding new semantic details such as format, allowed values, or examples.

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 ('Sprawdza'), the exact rule (ADR 4.3.3 hierarchy), and the precise relationship between 'offeredCode' and 'requiredCode'. It also distinguishes itself by explicitly excluding special provisions 4.3.5 and mandatory individual code assignment, separating it from generic ADR tools like search_adr.

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 tells the agent when not to use the tool by listing exclusions (special provisions 4.3.5, mandatory individual assignment). It does not name an alternative sibling to route to, but the scope boundary is explicit and actionable enough for an agent to decide if this tool fits.

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?

No annotations are provided, so the description carries the behavioral burden. The verb 'Wyjaśnia' signals an informational, non-mutating operation, and 'w kontekście jego klasy zagrożenia' adds useful context about the hazardClass dependency. However, it does not describe what the explanation returns or any error/side-effect behavior, though that is less critical for a simple explainer tool.

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

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

The description is a single well-structured sentence with no filler. It front-loads the core purpose, gives two concrete examples, and clarifies the hazard-class relationship, all without redundancy.

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

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

For a simple two-parameter tool, the description is practically complete: the schema fully documents both parameters, and the description supplies the domain context and examples. There is no output schema, and the description could go further by stating what the explanation looks like, but the low complexity and clear purpose make this a strong, usable definition.

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

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

Schema description coverage is 100%, so the baseline is 3 even without additional parameter detail in the description. The description adds the domain field name 'classificationCode' and repeats examples already present in the schema, which provides marginal value but not significant new semantic meaning.

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

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

The description states a specific verb ('Wyjaśnia') and resource (kod klasyfikacyjny towaru / classificationCode), and gives concrete examples ('FT1', '1.1D') along with the hazard-class context. This clearly differentiates it from sibling decoding tools like decode_tank_code and decode_hazard_id by naming the target field.

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: use this tool when you need to explain a goods classification code in relation to its hazard class. It does not explicitly name alternatives or state exclusions, so it falls short of a 5, but the context is specific enough for an agent to select it appropriately.

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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It correctly communicates that the tool is a read-only decoder that produces an explanation of digits and the X prefix. However, it does not mention the output format, error behavior for invalid codes, or edge cases like unknown code patterns.

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 contains the verb, resource, examples, and a key semantic detail. There is no filler or repetition; every part of the sentence 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?

For a one-parameter, read-only decoder with no output schema, the description is mostly complete. It gives the input format and the kind of explanation produced. The only missing piece is a clearer statement of the return value shape, but that is less critical given the tool's simplicity.

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

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

The input schema already fully documents the single parameter with the same examples. The description adds semantic value by explaining that the X prefix relates to water reactivity, which is relevant input interpretation knowledge beyond a bare schema description. This is a small but real addition.

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 ('Wyjaśnia' / explains) tied to a specific resource: the Kemler hazard identification number, with concrete examples ('336', 'X462'). It also mentions the exact elements of the explanation (digit meanings and the X prefix), which clearly differentiates it from siblings like decode_tank_code and decode_classification_code.

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 Kemler numbers and not for tank codes or classification codes, but it never explicitly states when to use it instead of a sibling. There is no 'use X for tank codes' style guidance. An agent must infer the usage boundary from the resource name.

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?

With no annotations provided, the description carries the burden of explaining behavior. It does disclose the core decomposition behavior and the four semantic parts, which is useful. However, it does not describe what happens on invalid input, whether the code is validated, or the exact output format, leaving behavioral gaps.

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 front-loaded sentence with no filler. It immediately states the verb and resource, then provides the output breakdown. Every word contributes to understanding the tool's purpose.

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

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

The tool is simple, but the description lacks usage guidance and does not specify the response structure (e.g., field names for the four parts). Since there is no output schema, the description should clarify what the agent can expect back. It is adequate but not 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?

The schema covers 100% of the single parameter, including an example, so the baseline is 3. The description repeats the example but adds no new constraints, format rules, or normalization behavior beyond the schema. It adds marginal context by linking the parameter to the four output parts, but nothing essential.

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 ('Rozkłada' – decomposes) and identifies the exact resource (tank code like 'L4BH'), then enumerates the four output components. This clearly differentiates it from sibling decoders such as decode_hazard_id or decode_classification_code, which target different code types.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention compare_tank_codes, decode_hazard_id, or any condition that would route an agent to this tool. The intended use is only implied by the resource name, not 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?

No annotations are provided, so the description carries the full burden. It discloses the non-obvious behavior that one UN number may return multiple rows and explains the disambiguation mechanism. However, it does not explicitly state the operation is read-only, describe the raw record format, or mention error/network behavior, leaving gaps for a tool with zero annotation coverage.

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

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

Two concise Polish sentences with no filler. The first sentence front-loads the core function, and the second addresses the only ambiguity handling needed. Every sentence 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?

For a simple 2-parameter lookup tool with no output schema, the description covers the primary behavior and the important multi-result edge case. It lacks explicit alternatives and read-only confirmation, but nothing critical is missing for correct 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 description coverage is 100%, so the baseline is 3. The description repeats the packingGroup disambiguation logic that already appears in the schema's property description, adding no new meaning beyond what the structured data 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?

Description uses a specific verb ('Zwraca' – returns), a precise resource ('surowy rekord Tabeli A Umowy ADR'), an explicit source (api.kocie.mba), and the key parameter (numer UN). This clearly distinguishes it from sibling tools like search_adr or decode_* that perform different operations.

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

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

The description gives a clear conditional usage instruction: if a UN number returns multiple entries, refine using packingGroup. It does not explicitly name alternatives or state when not to use the tool, but the exact-UN-number scope is implied strongly enough to guide selection.

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

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

No annotations are present, so the description carries the transparency burden. It discloses the data source and that the tool returns values, making the read-only nature inferable, but it does not describe edge cases, response format, or behavior when no LQ/EQ data 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?

A single, front-loaded sentence with no filler. It communicates the action, the target resource, and the data source efficiently.

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 and no annotations, the description is the only source of contextual detail, yet it omits the packingGroup parameter's role and any output or failure behavior. An agent calling this tool would still need additional schema or external knowledge to use all parameters meaningfully.

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 only 50%: unNumber is documented in the schema, but packingGroup has no description. The tool description mentions only the UN number and does not clarify the meaning or effect of the optional packingGroup parameter, so it does not compensate for the schema 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?

The description states a specific verb ('Zwraca' / returns) and a precise resource: LQ and EQ limits for a UN number, sourced from specific fields. This clearly differentiates it from broader siblings like lookup_un or search_adr by naming the exact output domain.

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

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

Usage is implied: use this when you need limited/excepted quantity limits for a UN number. However, it does not explicitly mention when not to use it or which alternative tool to prefer for other lookups, leaving routing decisions mostly to inference.

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?

With no annotations provided, the description carries the full burden. It discloses that the tool returns a shortened list of matches (UN number, name, class) and that full data requires a subsequent lookup_un call. This goes beyond a generic 'search' statement and sets expectations about the output and workflow.

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 with no filler. The main purpose is front-loaded, and the guidance to use lookup_un for full data is placed efficiently. Every sentence 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?

For a single-parameter search tool with no output schema, the description is complete: it identifies the target, the accepted query types, the abbreviated return fields, and the next step in the workflow. No critical information for invoking it correctly is missing.

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

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

The input schema already fully describes the only parameter, query, as 'Fragment nazwy lub numeru UN'. The description adds that the search is PL/EN and matches names or UN fragments, but it does not provide additional syntax, formatting, or example values beyond what the schema already says. Baseline 3 is appropriate since schema coverage is 100%.

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 ('Wyszukuje' — searches), a specific resource ('towary niebezpieczne' — dangerous goods), and search criteria (name PL/EN or UN number fragment). It also differentiates itself from the sibling lookup_un by noting it returns a shortened list rather than full data.

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 indicates when to use lookup_un after finding the right position, giving a sequential workflow. It does not explicitly state when not to use this tool (e.g., when an exact UN number is already known, lookup_un might be more direct), but the context is clear enough for an agent.

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