container_lookup

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

Beyond the readOnlyHint annotation, the description reveals concrete behavior: per-record provenance, unknown-type errors returning the valid slug list, geometric best-effort fits with explicit non-modeling caveats, and rate limiting where 429 returns retry_after_seconds. This is rich behavior the annotations alone do not cover.

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

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

While the description is long and dense, each sentence earns its place: covering supported types, invocation variants, fit semantics, provenance, error behavior, rate limits, and sibling routing. It is structured and front-loaded, but a little heavy for agents scanning 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?

Given readOnlyHint, idempotentHint, and openWorldHint=false, plus an output schema and 100% parameter schema coverage the description still fills important gaps: exact rate limits, best-effort fit limitations, error-response form, and related-tool routing. An agent has all the behavioral context needed to call it correctly.

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

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

Schema text already covers all six parameters at 100% coverage, including examples like '20ft-standard' and note that length is required to trigger the load-fit calculation. The description restates some of this framing (omit type to list all, adding dims computes fit) but does not add meaning significantly beyond the schema.

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

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

The description opens with a specific verb and resource: 'Get ISO shipping-container specifications, with optional load-fit maths.' It enumerates exactly which 10 container types are covered, and this high-level statement is sufficiently distinct from siblings like cbm_calculator, uld_lookup, and validate.

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 Related section explicitly differentiates sibling tools: validate checks a container number's check digit, cbm_calculator/consignment_calculator handle cargo volume, and uld_lookup is the air-freight equivalent. This gives clear context for choosing this tool over alternatives, though it does not give an exhaustive when-not-to-use list.

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