container-loading

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

With no annotations, the description fully discloses the tool's behavioral traits: it's a draft generator from a curated DGL, lists fields a DG-competent person must complete (flash point, net explosive mass, unverified PSN), and is never signed. This goes beyond a simple action statement and informs the user about limitations and safety-critical caveats.

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, front-loaded with the primary purpose, and every sentence is informative (outputs, input, draft caveats). No fluff or repetition; it is appropriately detailed without being verbose.

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 lacking an output schema, the description clearly explains what the tool returns: the specific transport-document description, placards/marks, and packing-certificate statements. It also covers the draft nature and the fields left for human completion, giving a complete picture of the tool's behavior and output.

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

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

The schema has 100% coverage for the single parameter packingList, so the baseline is 3. The description adds value by reinforcing that the input is a 'loadingmcp.packing-list' document and explicitly stating the payload is derived 'from its cargo lines,' which helps the agent understand the expected structure despite the opaque 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 specifies a precise action ('Draft the dangerous-goods paperwork') with a clear resource ('for a load from its cargo lines') and enumerates the exact outputs (IMDG 5.4.1 transport-document description, 5.3 placards, 5.4.2 packing-certificate statements). This clearly differentiates it from sibling tools like export_plan or import_packing_list.

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 clear context on when to use the tool: it takes a 'loadingmcp.packing-list' document and produces DG paperwork. It doesn't explicitly state when not to use it or name alternatives, but the purpose is specific enough that a user can infer the appropriate scenario.

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 full responsibility. It discloses a critical limitation (not a retailer certification, verify in portal) and describes the output content. Nevertheless, it does not state whether the operation is read-only or has side effects, nor does it mention any prerequisites like required permissions or data freshness, leaving some behavioral aspects opaque.

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 concise sentences: the first defines the output, the second lists integration targets, and the third states a caveat. Every sentence adds value, and the content is well structured, making it easy to parse and act on.

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

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

The tool has moderate complexity with 4 parameters and no output schema. The description covers the output's key elements and provides integration context and a caveat, which is sufficient for an agent to select and invoke the tool correctly. It does not detail every possible return value, but the summary of output content is adequate.

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

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

Schema coverage is 100%, with detailed descriptions for all parameters, so the baseline is 3. The tool description adds context about what the output contains (e.g., which SKU, where, order, orientation, securing list, declarable figures) and mentions the optional per-retailer check, which helps understand parameter intent. However, it does not elaborate on parameter formats 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's function: exporting a load as a machine-readable loading work order with specific components (stuffing sequence, securing actions, declarable figures, retailer check). It distinguishes itself from siblings by specifying the exact output format and integration targets (WES/TMS, robotic palletiser, worker sheet), making its purpose unambiguous.

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: it is for generating loading work orders to meet retailer/carrier specs, and it explicitly warns that it is not a certification and to verify in the portal. However, it does not explicitly mention when to use this tool over alternatives like plan_load or export_dg_paperwork, so it lacks a direct comparison.

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, the description carries the burden and does well by disclosing fail-explicit behavior ('returns the exact per-line issues, never a silently-dropped row') and the return payload (load plan + container manifest). It doesn't cover side effects or permissions, but for an import/parse operation this is reasonably transparent.

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

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

Two sentences, front-loaded with the core purpose, and every clause adds value. No repetition of schema or annotations.

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

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

The tool has one nested parameter and no output schema, so the description compensates by stating the output ('load plan + container manifest') and the failure mode. It could state more about the output structure or prerequisites, but it's sufficient for an agent to use 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%, so the schema already documents the packingList object thoroughly. The description adds contextual flavor ('WMS/ERP export' and versioned) but does not significantly expand upon the schema's parameter definitions.

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 function: take a versioned 'loadingmcp.packing-list' document and return a load plan and container manifest. The verb 'take' and resource are explicit, and it distinguishes itself from siblings by being the 'ERP/TMS on-ramp'.

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 provides clear context for when to use ('ERP/TMS on-ramp') and explicitly references sibling tool plan_load for a full round-trip. However, it doesn't explicitly state when not to use it or alternative scenarios.

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

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

No annotations are provided, so the description carries the full burden. It states what the tool lists but does not explicitly mention read-only behavior, absence of side effects, or any limitations. For a simple list operation, this is acceptable but minimal; it could be improved by adding 'does not modify any data' or similar.

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 fluff. It efficiently communicates what the tool does and what it returns, earning a perfect score for conciseness.

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 the tool's purpose and output content (dimensions and payload), which is sufficient for a simple list tool with one optional parameter and no output schema. It could mention that omitting category returns all types, but the schema already implies the filter is optional, so the description is adequately 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%: the only parameter 'category' is fully described with an enum and 'Optional category filter'. The description adds no extra meaning beyond what the schema already provides, so the baseline score of 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 verb 'List' and the specific resource (standard container, truck, ULD and pallet types) along with the output content (internal dimensions in mm and max payload in kg). This distinguishes it from sibling tools like suggest_containers or plan_load, which have 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 phrase 'LoadingMCP can plan loads into' gives useful context: this tool lists the equipment types supported for load planning. However, it does not explicitly state when to use this tool versus alternatives or when not to use it. The context is clear but lacks direct comparisons 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?

With no annotations, the description carries the full burden of disclosing behavior. It does well by explaining that cargo `type` drives realism (hex-nesting, top-loading big bags), that omitting `equipmentCode` triggers auto right-sizing to the cheapest container, and that the production key uses the PackingSolver optimizer while the demo key uses an offline preview packer. It does not disclose potential side effects or limitations, but for a computation tool this is adequate.

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

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

The description is a single, well-structured paragraph that uses colons and semicolons to pack multiple related details. It is not overly long, and every sentence adds meaningful information. While it is slightly more than two sentences, the density and organization make it concise and front-loaded.

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

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

Given the tool's high complexity, the rich input schema, and the absence of an output schema, the description does a good job of covering the main behaviors and expected outputs. It lists the return values (containers used, utilization, CoG, violations, checklist) and touches on edge behaviors like cargo type handling and auto right-sizing. It could mention mode handling or more details about the difference between production and preview, but overall it is reasonably 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 already has 100% coverage, so the baseline is 3. The description adds valuable semantic context beyond the schema: it explains that cargo `type` drives realism (e.g., drums hex-nest, big bags load on top and are never crushed) and that omitting `equipmentCode` triggers auto right-sizing. This helps the agent understand the intent of these parameters, justifying a 4.

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 what the tool does with a specific verb and resource: 'Compute a 3D load plan for cargo into a container or truck.' It enumerates concrete outputs (containers used, utilization percentages, centre of gravity, crush-protection violations, securing checklist), which distinguishes it from sibling tools like list_equipment or suggest_containers. The scope is unambiguous.

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 clear context for when to use the tool (to compute a load plan) and provides important usage nuances, such as omitting `equipmentCode` to auto right-size and the distinction between a production API key and demo key. However, it does not explicitly compare against alternative sibling tools or state conditions when one should choose a different tool, so it falls 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool provides a 'quick volume/weight estimate', implying approximate results, and points to plan_load for exact calculations. It does not disclose potential edge cases or output format details, but the core behavioral trait (approximation) is transparent.

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

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

Two compact sentences, the first explains the purpose and inputs, the second provides an alternative. No wasted words, extremely efficient.

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

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

Given the tool's low complexity (two simple numeric inputs), the description fully explains its purpose, usage context, and alternative. It does not need to explain return values in detail because the output's nature ('suggest how many of which container') is clearly implied. The absence of annotations and output schema does not leave major gaps.

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

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

Schema coverage is 100% with clear descriptions for both parameters (volume in cubic metres, weight in kilograms). The description restates the same units but adds no new meaning or constraints 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 clearly states the tool's function: given volume and weight, it suggests container types and counts. It distinguishes itself from plan_load by explicitly noting this is a quick estimate, while plan_load is exact and dimension-aware.

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 explicitly states when to use this tool ('quick volume/weight estimate') and when to use the alternative plan_load for exact, dimension-aware planning. This is a clear usage guideline with a named alternative.

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