get_in_the_boxWhat ships in the box for one product, per model or configuration, as the official product page states it: each item, its quantity, whether it is included (false means the official page says it is not), and the page it came from. Optional variant narrows to one configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| variant | No | Part of a configuration name, e.g. 'Pro' | |
| product_slug | Yes | A product_slug, e.g. 'apple-watch' |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description earns credit beyond that by disclosing the data provenance ('as the official product page states it') and the interpretation rule for the output ('included: false means the official page says it is not') – a non-obvious semantic the agent could otherwise misread.
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?
Compact and front-loaded: purpose first, then the returned structure, then the variant note. No filler sentences, though the single dense sentence packing output fields and the variant clause is slightly heavy to parse.
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 helpfully sketches the return shape (item, quantity, inclusion flag, source page). Combined with annotations covering safety and the 100%-covered input schema, an agent has enough to call this correctly; only the exact field names and array/object shape remain 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 description coverage is 100%, so the baseline is 3. The description adds meaning above that by framing the result as 'per model or configuration' and explaining that variant 'narrows to one configuration', clarifying what the optional parameter actually selects rather than merely restating its schema text.
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-plus-resource ('what ships in the box for one product, per model or configuration') and enumerates the returned fields (item, quantity, inclusion, source page). The purpose is unmistakable and distinct from generic siblings like get_product or get_product_facts, though it never names an alternative to route the agent with.
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 strongly by the purpose ('what ships in the box') but there is no explicit when-to-use vs when-not, and no mention of alternatives such as get_product_facts or get_variants_and_offers that might also surface box contents. 'Optional variant narrows to one configuration' is parameter guidance, not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.