Camden Tools

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the verdict is all-or-nothing, every line must be eligible, and split shipments are not permitted — the single most important semantic an agent needs.

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 dense sentence with the resource and the all-or-nothing constraint front-loaded; nothing is wasted and no filler is present.

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?

An output schema exists so return shape needn't be described, annotations cover safety, and the schema covers inputs. The one gap is that 'Website Express' itself is never explained, but for calling the tool correctly the definition is sufficient.

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 items, id, quantity and locale are already documented in the schema. The description reinforces that items are product ids with quantities but adds no new detail (e.g. the 50-line cap or the locale's effect on pricing/names) 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?

States a specific verb+resource: a 'Whole-basket Website Express verdict' computed from product ids and quantities. An agent can tell this is an eligibility-check tool, though it does not explicitly contrast itself with siblings like check_shipping_availability or estimate_delivery.

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 the name and the 'every line must be eligible' framing, but there is no explicit when-to-use or when-not-to-use guidance, and no named alternative for per-line or single-product eligibility checks.

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that a restriction message may accompany the result, which is mildly useful context, but it does not say what an unsupported/invalid country code yields or how strict the check is.

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 zero filler that states the resource and the accompanying result payload. Nothing redundant and nothing buried.

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?

An output schema exists and annotations cover the safety profile, so the description need not explain return structure. However, for a check-style tool the description should at least indicate what to do on an unsupported country or whether the restriction message is the actionable output — the definition stops short of that.

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 both parameters are already documented, including the ISO alpha-2 pattern and the locale options. The description adds nothing about parameters and notably does not explain why locale matters (or that it may be irrelevant) for a shipping check — 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?

The description names a specific question the tool answers — whether Camden Tools ships to a given country — which is concrete enough for an agent to select it. It does not distinguish itself from close siblings like check_express_eligibility or estimate_delivery, which an agent could plausibly confuse it 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?

There is no explicit when-to-use guidance and no mention of alternatives. The description never says to prefer this tool over check_express_eligibility (express options) or estimate_delivery (timing), so the agent must infer the boundary from the name alone.

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=true and destructiveHint=false, so the safety profile is covered; the description adds that the output is a comparison bundle spanning price ex/inc VAT, stock, brand, weight and spec bullets. It does not disclose any failure behavior (what happens if a SKU is unknown or out of range) or rate/locale 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?

A single dense sentence with the scope constraint front-loaded and the outcome framing at the end. No filler and nothing repeated verbatim from structured fields beyond the count range.

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 an output schema and read-only annotations, the description need only convey scope and intent, which it does. The one gap is that locale's effect on which currency the ex/inc VAT prices are reported in is not hinted at, though it is documented in the schema.

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 50% and both parameters carry their own descriptions; the description's '2 to 5 products by SKU' merely restates the schema's minItems/maxItems and item description. It says nothing about locale, whose effect on currency and naming is 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?

Names a specific verb and resource ('Side-by-side comparison of 2 to 5 products by SKU') and enumerates the compared fields, so an agent knows exactly what comes back. It is clearly distinct from single-item siblings like get_product and from list/search siblings.

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 clause 'so an agent can recommend between options' tells the agent the situation that selects this tool (decision support between candidates). It stops short of naming alternatives such as get_product for a single SKU or search_products for discovery.

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 the description reinforces the idempotency contract in plain language (\"opening it twice does not double them\"), which is more useful than the hint alone. It also discloses the handoff boundary (the shopper reviews and pays themselves) and that the result flags unbuyable lines — details not present in the annotations. It stops short of covering link lifetime, sharing scope, or failure modes.

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?

Four compact sentences, front-loaded with the core transformation and followed by the behavioral contract, the failure handling, and the id provenance. Every sentence carries information an agent would otherwise have to infer.

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?

Output schema exists, so return values need not be spelled out, and the description picks the one return detail that changes agent behavior (out-of-stock lines). Safety is covered by annotations. Minor gap: nothing about how long a generated link remains valid or whether it must be shared rather than acted on directly.

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 baseline is 3; the description earns a notch by naming the three specific sibling tools that supply the id parameter, which is more actionable than the schema's generic \"Product id from search/product tools.\" The locale parameter and quantity/count limits 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: turning product ids and quantities into a single link that fills a shopper's basket on camdentools.com. It also distinguishes itself from the retrieval siblings by naming where ids come from (search_products, list_products, get_product), so an agent can place it correctly in a workflow.

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?

"Use it to finish a shopping conversation" gives a clear situational trigger, and the out-of-stock instruction (\"offer an alternative before sharing the link\") tells the agent what to do when the preconditions fail. No explicit when-not-to-use or competing alternative is named, but no sibling overlaps this capability.

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=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the result is an estimate computed with placeholder contact details and exact rates are only confirmed at checkout, which warns the agent about result fidelity. It does not cover latency, caching or rate limits, so it falls 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 tight sentences with zero filler: purpose and input scope first, accuracy caveat second. Every clause carries information the agent can 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?

With an output schema present, return-value explanation is not the description's burden, and the accuracy caveat fills the main behavioral gap. Minor omissions remain: it does not say whether unvalidated or missing postcode/city degrades the estimate, nor whether charges are returned in a specific currency tied to locale.

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 every parameter (country_code, postcode, city, locale, items) is already documented, and the baseline is 3. The description echoes the destination shape ('country plus postcode/ZIP and city') and 'basket', adding only orientation, not new semantics such as whether city/postcode are optional or how locale affects charges.

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 (delivery services, charges and transit times) and scope (a basket to a country + postcode/ZIP + city), so the agent knows it returns shipping rates for a cart, not product data. It does not, however, explicitly distinguish itself from near-siblings like check_shipping_availability, check_express_eligibility or get_prices_for_country, which an agent could easily confuse it 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 only implied: the agent can infer it should call this with a basket and a destination to obtain rates. There is no explicit when-to-use statement, no mention of when to prefer check_shipping_availability / check_express_eligibility, and no prerequisites such as required destination granularity.

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=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds that the returned content is plain text rather than HTML/markdown, which is useful, but says nothing about what happens with an unknown slug or an invalid locale.

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 fragment that front-loads the resource and the return format with zero waste. It is arguably too terse, 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?

An output schema exists, so return structure needn't be described, and locale is documented in the schema. However, for a tool whose locale parameter 'controls product names, slugs and prices', the description never notes whether locale affects the post lookup, which is a meaningful gap 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 coverage is 50%: locale is well documented in the schema, while slug has no description but is self-evident and constrained (1-200 chars). The description's 'by slug' confirms the lookup key but adds no meaning 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?

States a specific resource (blog post) and what it returns (full text, plain text) retrieved by slug. It is clearly distinguishable from search_blog_posts, though it does not name that sibling 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?

The 'by slug' phrase implies this is a single-item exact-lookup versus a search, but there is no explicit when-to-use/when-not guidance or reference to search_blog_posts as the alternative for discovery.

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=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that products are paged and that promotions are 'active,' which is useful behavioral context, but it omits anything about authentication, rate limits, or 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?

A single sentence, front-loaded with the resource and its returned components, with zero redundant text. Every phrase—brand details, active promotions, paged products, brand slug—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?

An output schema exists, annotations cover the safety profile, and the input schema fully documents all four parameters, so the description need not explain return values or parameter formats. It adequately states the composite response shape and pagination, though it could clarify that only active promotions are returned and how pagination interacts with brand details.

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%, with every parameter including slug, page, per_page, and locale documented in the schema itself. The description reinforces the slug scoping and paging but adds no syntax or format detail beyond what the schema already provides, so the baseline 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 names a specific resource (a brand) and enumerates the payload: brand details, active promotions, and paged products, scoped by brand slug. It is clear what the tool returns, though it does not explicitly differentiate itself from siblings like list_brands or get_products.

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?

There is no when-to-use guidance, no mention of alternatives such as get_products or list_brands, and no prerequisites stated. The agent can infer usage from the phrase 'by brand slug,' but nothing tells it when this tool is preferable to its siblings.

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=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: it discloses that the tool evaluates fulfillment feasibility, identifies promotions including free-delivery offers and free gifts, and returns an adjusted basket value, matching the checkout 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?

The description is a single front-loaded sentence that immediately states what the tool evaluates. Every clause contributes useful information about outcomes and checkout parity, with no redundant or filler text.

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 an output schema present, annotations covering safety, and complete parameter descriptions in the schema, the description provides enough context for an agent to call the tool correctly. It could go slightly further in explaining edge cases or error behavior, but the core evaluation scope is clearly stated.

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 input schema already documents all parameters, including the nested item id and quantity fields. The description adds no additional parameter-level semantics, so the baseline score of 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 ('Evaluate') and clearly identifies the resource ('a prospective basket') and its scope: fulfillment eligibility, applicable promotions, and adjusted basket value. It also distinguishes this basket-level evaluation from product-level promotion lookup by focusing on a whole basket and stating it is the same check the checkout runs.

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 when to use the tool by explaining that it evaluates a prospective basket and mirrors checkout behavior. However, it does not explicitly mention when not to use it or name alternatives such as get_product_promotions, so the agent must infer the routing from the wording.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully adds that the embedded product list is paged, but it does not say whether pagination applies only to products or also to category metadata, nor any limits.

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 short sentence with the resource and payload front-loaded and zero filler. It is a fragment rather than a full clause, and it spends its few words on return contents rather than selection guidance.

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?

An output schema exists, so return shapes need not be described, and annotations cover safety. For a 5-parameter composite read, though, the description leaves open how paging interacts with the nested product list and offers no disambiguation from get_products or list_categories.

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%: slug, page, per_page, sort, and locale are all documented, including allowed sort values and locale examples. The description adds no parameter meaning beyond the word 'paged', 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?

The noun phrase names the resource (a category) and precisely what comes back: name, description, and its products, keyed by slug. It is clear enough to distinguish from get_product or list_products, but it never explicitly contrasts with the most confusable sibling, list_categories.

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?

No guidance on when to fetch a category versus calling list_categories first, or versus get_products filtered by category. The routing knowledge that 'slug comes from list_categories' exists only in the schema, not in the description.

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?

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds meaningful behavioral context beyond the annotations: the open status is evaluated in Europe/London time and respects bank holidays, which tells the agent this is a time-sensitive lookup rather than a static record.

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 with the resource front-loaded and every clause contributing useful information about the returned data. There is no redundant explanation or repetition of structured fields.

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 zero-parameter read-only tool with an output schema and clear annotations, the description supplies all the context an agent needs: what location is covered, what fields are returned, and how open status is computed. Nothing essential 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?

There are zero parameters, so parameter semantics carry no burden and the baseline is 4. The description appropriately does not invent parameter details for a no-argument tool.

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 resource (the London Click & Collect warehouse) and enumerates the exact information returned: address, opening hours, current open status, and next opening time. It is immediately clear what the tool does and there is no sibling tool for collection point information, so no further differentiation is needed.

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 the resource name and listed fields, but the description gives no explicit when-to-use guidance, prerequisites, or alternative tools to consider. An agent can infer it should call this when collection point details are needed, but the definition does not actively route between this and related tools like estimate_delivery or check_shipping_availability.

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=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful domain-specific behavior beyond annotations: it clarifies that this is a free same-working-day dispatch for eligible UK orders, and that the response includes the order-by cutoff and promised dispatch date. It does not describe caching or update frequency, but that is a minor gap given the rich 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?

The description is a single, front-loaded sentence that packs the key concepts—availability, cutoff, and dispatch date—with no wasted words. It is appropriately sized for an agent 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?

With an output schema present, the description need not explain return values, and it does well to enumerate what status information is provided. The only missing piece is explicit routing guidance relative to sibling tools, but for a read-only status check the description is otherwise 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%, and the single optional locale parameter is fully documented in the schema. The description adds no further meaning about the locale parameter, so the baseline score of 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 resource (Website Express availability) and enumerates the specific outputs: current availability, order-by cutoff, and promised dispatch date. It does not, however, explicitly differentiate itself from sibling tools like check_express_eligibility or check_shipping_availability.

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 phrases like 'available right now' and 'order-by cutoff', suggesting a live status check. But there is no explicit guidance on when to use this tool versus check_express_eligibility or estimate_delivery, nor any stated 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful detail that the return is full text in markdown format, which is not conveyed by annotations. It does not disclose other behaviors like localization effects, but with annotations covering safety and an output schema present, 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, compact sentence that front-loads the core purpose (full text of a policy) and immediately lists the valid values. There is zero redundancy or fluff, and every word contributes to understanding.

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 read-only tool with two parameters, an output schema, and safety annotations, the description is nearly complete. It covers the return format (markdown) and the allowed policy types. The only minor gap is that it does not explicitly mention the locale parameter's role, but that is fully documented in the schema, so the description is sufficient 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 coverage is 50% because only the 'locale' parameter has a description; 'policy' is just an enum with no explanation. The tool description compensates by listing the allowed policy values, which adds meaning to the 'policy' parameter. However, it does not clarify the 'locale' parameter's effect on the returned text, though the schema does provide a detailed description for it.

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: retrieving the full markdown text of a store policy, and enumerates the exact policy types (delivery, returns, payment-options, faqs, contact). This is a specific verb+resource pairing that distinguishes it from all sibling tools, which are unrelated (e.g., get_product, list_categories).

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 implicitly communicates when to use the tool by listing the policy types, making it obvious that this is the go-to for any policy text. There are no sibling tools with a similar purpose, so no alternative routing is needed. However, it does not explicitly state 'use this when...' or mention any exclusions, 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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety and world-access profile are covered. The description adds that prices are currency-dependent on destination country and enumerates the price tiers returned, but says nothing about how locale interacts with country or about caching/staleness of pricing.

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 tightly written sentence with the core purpose front-loaded. The trailing parenthetical about checkout currency overlaps with 'Country-specific pricing' but is brief enough not to be wasteful.

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?

Low-complexity read tool: 3 parameters at full schema coverage, an output schema present, and annotations carrying the safety profile. The description covers scope and return shape adequately; only the interaction between locale and currency (both affect prices per the schema) is left unremarked.

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%, with locale, shipping_country and nested items/quantity all documented in the schema itself. The description only echoes the country and product-set concepts, adding no syntax or semantics beyond what structured fields supply, so 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 and resource ('Country-specific pricing for a set of products') and clarifies the scope: destination country drives currency and pricing. No sibling tool in the list computes per-country basket pricing, so it is distinguishable by inference, though no sibling is 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?

No explicit when-to-use or when-not-to-use guidance and no named alternatives (e.g. get_product for single-product detail, get_product_promotions for deals). The parenthetical about the checkout applying destination-country pricing implies the intended context without stating it as a rule.

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, openWorldHint and non-destructive, so the safety profile is covered. The description adds which fields are returned (prices ex/inc VAT with bulk breaks, stock, variants, documents, canonical URL), which is useful, but since an output schema exists it is largely redundant and no additional behavior (caching, locale fallback, rate limits) is disclosed.

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?

One information-dense sentence plus one directive sentence. Scope and returned data are front-loaded, nothing is padded, and the identifier constraint lands last where the agent will act on it.

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 a full schema, existing annotations and an output schema, the description covers scope, identifier selection and returned content adequately for a read-only lookup. The only shortfall is not steering the agent toward sibling tools when the product is unknown or when only stock/documents are needed.

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 handled and the baseline is 3. The description earns a bump by stating a cross-parameter constraint the schema cannot express — exactly one of slug, sku or id must be supplied, none are schema-required — which materially prevents malformed calls.

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 + scope: 'Full details for one product by slug, SKU or id'. The 'one product' framing cleanly distinguishes it from the list/search siblings (get_products, list_products, search_products), and the colon-enumeration tells the agent exactly what data comes back.

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?

Clear context for use — fetch a single known product — and the closing constraint 'Provide exactly one of slug, sku or id' directs the call. It stops short of naming alternatives (search_products for discovery, get_stock_level / get_product_documents for narrower needs), so there is no explicit when-not 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 readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful context beyond that by enumerating the document types returned and stating that the result is a set of document URLs, which helps the agent predict the response without needing to open the output schema.

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 entire description is two short sentences with high information density. It front-loads the document types, adds the identifier options, and states the return shape with no filler or repetition of the tool name.

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 simple parameter set, full schema coverage, read-only annotations, and presence of an output schema, the description is essentially complete for selecting and invoking the tool. A minor gap is that it does not explicitly say that at least one of slug or SKU should be provided, even though that is strongly implied by 'by slug or SKU'.

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 sku, slug, and locale. The description adds only the clarification that a product can be identified 'by slug or SKU', which is useful but not a major addition beyond the schema's own parameter descriptions.

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 retrieves product documents (safety data sheets, specification sheets, COSHH hazard codes) and returns their URLs. This is specific enough to distinguish it from sibling tools like get_product or get_related_products, which return general product or relationship 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 implies the right usage context: when document-level data such as safety or specification sheets is needed for a product. It also tells the caller the lookup can be done by slug or SKU, but it does not explicitly list when not to use it or point to alternatives, so it stops 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 readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds that only *active* promotions are returned, which is useful behavioral context, but says nothing about result size, whether an empty result is possible, or locale-dependent behavior beyond what the schema states.

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 compact clause with the scoping constraint ('one SKU') and the payload contents front-loaded. Nothing is redundant and nothing needs trimming.

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 read tool with an output schema, a full-annotation safety profile and fully documented parameters, only the routing relative to get_cart_promotions is missing. Otherwise an agent has what it needs 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 description coverage is 100%: both sku and locale are documented in the schema, including the default locale and its effect on names and prices. The description only restates SKU scoping, so 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 resource (promotions) and scope (active, applying to one SKU), and enumerates what is returned: discounts, free gifts, end dates. This clearly separates it from cart-level or catalogue-wide tools, though it never names the closest sibling (get_cart_promotions) 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?

The 'one SKU' scoping implies this is the product-level lookup rather than a cart-level one, but there is no explicit when-to-use or when-not-to-use statement, nor any note about prerequisites such as needing an active storefront context.

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 the safety profile (readOnlyHint, destructiveHint false, openWorldHint true), so the bar is lower. The description adds useful behavior: a 50-item cap and a 'compact' return shape (name, price ex/inc VAT, stock, link). It does not disclose what happens with ids that don't resolve — skipped, error, or null slots — which matters for a batch lookup.

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, no waste, key constraint (batch size) and return shape front-loaded. Every clause carries information an agent can 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?

With an output schema present, return values needn't be explained, and the safety story is carried by annotations. The remaining gap is edge-case behavior: partial resolution of unknown ids, and the fact that neither ids nor skus is required by the schema, so the description should say at least one must be given.

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 only 33%: ids has no schema description and locale's effect is documented in-schema. The description compensates by clarifying that ids must be numeric and that either ids or skus can be used, and repeats the batch cap. It does not say whether ids and skus may be combined in one call or what happens if neither is 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?

States a specific verb (look up), resource (products), batch scope (up to 50 at once) and the two lookup keys (SKU or numeric id), which separates it from the single-item get_product and the filter-based list_products/search_products. It stops short of naming those siblings explicitly, so the differentiation is inferable rather than stated.

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: call it when you already have SKUs or numeric ids in hand. There is no explicit 'when not to use' or pointer to search_products / list_products as the alternative when you only have a name or category.

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?

The annotations already establish that this is a read-only, non-destructive, open-world operation. The description adds useful behavioral context by listing the categories of related items returned, but it does not discuss pagination, limits, or other operational details beyond the safety profile.

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?

It is two concise sentences with no wasted wording, and the returned item categories are front-loaded before the stock-alternative use case.

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 read-only lookup with a complete input schema, annotations, and an output schema, the description provides sufficient context. A minor gap is that it does not clarify whether at least one of slug or SKU should normally be supplied, despite neither being marked required.

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 sku, slug, and locale are already documented in the schema. The description mentions lookup by slug or SKU, but adds no syntax, precedence, or locale-specific detail beyond that baseline.

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 identifies the resource as related product data and enumerates the kinds returned: variants, similar products, recommendations, and 'you may also like' items. It is specific enough to distinguish this from get_product or search_products, though it does not explicitly name those siblings.

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 one contextual use case, 'alternatives when something is out of stock,' which implies when to reach for it. It does not state when not to use it or explicitly contrast it with sibling tools such as search_products or compare_products.

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, non-destructive and openWorld, so the safety profile is covered. The description adds useful scope detail about what content is bundled (VAT rules, announcements, policy summaries), which is not in the annotations. It stops short of noting anything about response shape or staleness, but the presence of an output schema reduces that burden.

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, both earning their place: one content inventory and one routing instruction. The content list is dense but front-loaded and free of 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 an output schema present, the description need not explain return values, and it covers content scope and the sibling boundary. What remains unstated is any locale/default behaviour or caching note, but nothing essential for correct invocation 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?

Schema coverage is 100% and the single optional locale parameter is fully documented in the schema with examples and its effect on names, slugs and prices. The description adds nothing about locale, 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?

The description names the resource (Camden Tools' store information) and enumerates the specific contents returned: contact details, VAT display rules, page links, announcements, and policy summaries. It is clearly distinct from get_policy, which it explicitly routes to for full policy text.

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 the boundary against the obvious sibling: this tool gives summaries, and 'Call get_policy for the full text of a policy.' That is an explicit alternative plus the condition that selects it, which is exactly what an agent needs to choose between the two.

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?

The annotations already establish that this is a read-only, non-destructive, open-world operation. The description adds useful behavioral context by explaining that the result is live/fresh and highlighting the staleness limitation of product-result stock data.

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 two tight clauses that front-load the core purpose and then add the freshness differentiator. There is no filler, and every sentence contributes useful selection context.

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 one-parameter read-only tool with a full input schema and an output schema, the description is complete enough: it states the purpose, what the check answers, and why it is fresher than product-result stock data.

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 single sku parameter is already documented as the product SKU exactly as shown on the site. The description does not add further SKU format or interpretation detail beyond what the schema provides, so the baseline score of 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 names a specific verb and resource: a live availability/stock check for a SKU, including what the result means (buyable now, orderable units). It also distinguishes this from the stale stock_level field on product results, so an agent can tell when this tool is the right source of stock information.

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 positioning the tool as a live availability check and explicitly contrasting it with product results that can be hours old. It does not spell out when-not-to-use cases or name a sibling tool directly, so it falls short of fully explicit 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 and non-destructive behavior, and the description adds value by revealing the conditional behavior: no query returns popular brands, while a query searches brand names. This goes beyond the annotation signals without contradicting them.

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 with no filler. The resource and scope are front-loaded, and every clause contributes useful behavioral 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 simple list tool with no required parameters, a high-coverage schema, an output schema, and safety annotations, the description is complete. It covers the main call patterns and the scope of the brand catalog, leaving no critical behavioral 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%, so the schema already documents all four parameters. The description adds modest context around the query parameter (searches brand names) and the default popular-brand behavior, but page, sort, and per_page semantics remain entirely schema-defined.

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 identifies the exact resource (Camden Tools' brands) and gives concrete examples (DeWalt, Makita, Milwaukee). It also distinguishes the tool from sibling product/category tools by focusing on the brand catalog and by stating the query/no-query behaviors.

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 explains when to include or omit the query parameter, which is useful internal guidance. However, it does not explicitly compare this tool with siblings such as get_brand_products, list_products, or search_products, so selection guidance is implied 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 declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered externally. The description adds only that bundles are 'curated' and include items and prices, but says nothing about pagination, result limits, locale effects, or other behavioral traits beyond what annotations and schema provide.

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?

It is a single short sentence with no wasted words, but it is under-specified rather than optimally concise. The fragment lacks a leading action verb, so the core purpose is not front-loaded as clearly as it could be.

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?

An output schema exists, so return values need not be explained in the description, and annotations cover safety. However, for a listing tool that competes with many product-listing siblings, the description omits usage context, scope, and behavioral details, leaving the agent without enough information to select it confidently.

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 single optional locale parameter is fully documented in the schema, including examples and its effect on names, slugs, and prices. The description adds no parameter meaning beyond the schema, so the baseline of 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 names the resource ('curated product bundles (kits)') and mentions included items and prices, which distinguishes it somewhat from plain product listings. However, it is a noun phrase rather than a verb-led statement, and does not explicitly say it lists or returns these bundles, leaving the action implied rather than stated.

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?

There is no guidance on when to use this tool versus alternatives such as list_products, get_products, or search_products. The description gives no conditions, exclusions, or sibling tool comparisons.

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=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds that results carry slugs and links and that the unpaginated default is the full catalog, but says nothing about ordering, catalog size, or rate limits on an open-world endpoint.

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, no filler, with the payload contents front-loaded and the parameter branch second where the agent will look for it. Every clause carries decision-relevant 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?

An output schema exists, so return values need not be described, and all three parameters are documented in the schema with defaults and bounds. What remains unstated is ordering of results and whether the full list is paginated beyond the limit cap, a minor gap for a simple read-only listing 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 the baseline is 3; the description earns a bump by clarifying what 'popular' actually means (the curated set shown on the site) and by restating the otherwise-branch as the full list, which the schema's terse 'Only the popular categories' does not convey. Locale and limit are left 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 the resource (product categories) and the shape of the payload (slugs and links), which is more than a restatement of the name. It does not explicitly differentiate itself from the singular get_category sibling, but the plural/full-list framing makes the distinction inferable.

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 second sentence gives an explicit branch between popular_only=true (curated site set) and the default full list, which is real conditional guidance. However, there is no guidance on when to use this tool instead of get_category for a single category, or why one would pick list_brands/list_products in an adjacent task.

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=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds what kind of promotional content comes back and that it maps to the /offers page, but says nothing about volume, pagination, or whether expired offers are excluded — relevant for a live-promotions endpoint with openWorldHint.

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 with the payload described first and the supplementary /offers pointer last. No filler, no redundancy, nothing that could be cut without losing 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?

An output schema exists, so return values need not be explained, and both parameters are fully documented in the schema. What is missing is the routing information an agent needs in a 28-sibling server: which of the three promotion-related tools to pick and under what conditions. Adequate but clearly incomplete for the decision the agent must make.

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 locale parameter's effect on names, slugs, and prices is documented in the schema itself. The description restates the grouping concept ('grouped by brand or category') without adding semantics such as what the 'all' grouping does or whether grouping changes the response shape. 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 resource (current storefront promotions) and enumerates the concrete offer types returned: percentage discounts, fixed discounts, and free gifts. It also discloses the optional grouping axis. It does not, however, distinguish itself from the similar-sounding siblings get_product_promotions and get_cart_promotions.

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 never says when to call this instead of get_product_promotions or get_cart_promotions, which sit in the same domain and are the obvious confusions. The only contextual hint is the passing reference to the /offers page, which implies site-wide rather than product- or basket-scoped promotions but leaves it 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered and the bar is lower. The description adds only that results are paged/sorted/filtered and that locale affects names, slugs and prices — useful but thin, with nothing on page-size limits or total-count behaviour.

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 sentence, front-loaded with the verb and the collection options, with no boilerplate. The trailing 'Supports paging, sorting and brand/price filters' largely restates parameters the schema already documents, so it is slightly padded but not harmful.

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?

An output schema exists, so return values need not be explained, and all ten parameters carry their own descriptions with only one required field. For a read-only browse tool this covers what an agent needs to invoke it correctly; only the sibling-selection question remains, which is scored under usage guidelines.

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 each of the ten parameters is already documented, and the baseline of 3 applies. The description's contribution is the implicit collection-to-parameter dependency ('category by slug', 'on sale'), but it does not add syntax or interaction rules (e.g. min_discount only applying to on-sale) beyond what the schema 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?

States a specific verb (browse/list) and resource (product collection) and enumerates the five collection modes, which is far more informative than the title. It names list_categories for the category-slug path but never distinguishes itself from sibling get_products or search_products, so an agent can't fully rule out the alternatives from the description alone.

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?

Implies usage through the collection enumeration and points to list_categories for resolving a slug, which is genuinely useful routing. However there is no explicit when-to-use-this-vs search_products/get_products, nor any exclusion such as 'use search_products when you have a keyword query', so the choice between curated browsing and search is left 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?

Annotations already cover read-only/open-world semantics, so the description's job is to add what they don't: it discloses upstream rate limiting and the hard refusal of outward-only codes. That is exactly the kind of operational context annotations can't express; only error/return shape is left unstated (and an output schema 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?

Two short sentences, resource first then constraint, zero filler. Every clause carries information the agent can 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?

With a single required param, full schema coverage, and an output schema, the description covers the essentials plus rate-limit and input-validity caveats. It stops short of only minor items such as response size or what happens on a valid-but-unmatched postcode.

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 an example already present, so baseline is 3. The description goes beyond the schema by stating which form of postcode is rejected (outward-only, e.g. NW2), which prevents a plausible failed call the schema alone would permit.

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 specifically that the tool returns addresses for a full UK postcode, with a concrete example. It doesn't need to distinguish from siblings since none of the listed tools overlap, but it also never names or rules out an alternative.

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 exclusion 'a partial postcode ... is refused' gives the agent one clear precondition, which is genuinely useful. There is no broader when-to-use framing or pointer to another tool for partial/outward-code lookups, so guidance is implied rather than complete.

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the content domain (how-tos, buying guides, brand news), which helps set result expectations, but says nothing about result volume, ordering, or pagination limits.

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 tight sentence with a parenthetical that usefully enumerates content types. No filler, though it leads with the resource rather than the action, so the operation is not 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?

With annotations, a full schema, and an output schema, most structured context is present. The remaining gap is the missing differentiation from get_blog_post and the absence of any hint about result ordering or scope — an agent choosing between the two blog tools has to guess.

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 both the page and query parameters are fully documented in the schema. The description adds no additional parameter meaning beyond what is already structured, which is the baseline for fully covered schemas.

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 identifies the resource (blog guides and articles) and its content types, but it never states the operation — the verb 'search' comes only from the tool name. It also fails to distinguish this from the sibling get_blog_post, which retrieves a single post.

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?

There is no guidance on when to use this versus get_blog_post, no mention of pagination approach, and no note that omitting the query returns the latest posts (that behavior lives only in the schema). The agent must infer the search-vs-fetch split.

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/openWorld/no-destructive, so safety is covered. The description adds genuine behavioral context: default exclusion of out-of-stock items and the shape of results (compact products with ex/inc VAT prices, stock, link).

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, front-loaded with what the tool does, then return shape, then filtering/pagination. No filler; each sentence carries operational 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 10-parameter search tool with a full-coverage schema and an output schema, the description covers purpose, results and the key default (out-of-stock). It omits locale/sort/express explicitly, but those are well described in the schema, leaving only a minor 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 every parameter is already documented. The description reinforces the main filter/pagination intent and the include_out_of_stock default behavior, but adds little syntax or semantics beyond what the schema states. Baseline 3 fits.

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+resource (full-text search of the Camden Tools catalogue) and scopes the catalogue contents. It clearly reads as the search entry point, distinguishable from get_products/list_products (browsing) and get_product (single detail).

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?

Explains when to paginate (page/per_page), how to narrow (brand/min_price/max_price) and the out-of-stock default with an escape hatch. It does not explicitly route the agent to a named sibling (e.g. use get_products to browse), so it stops short of full alternative 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond them: no authentication is required, and the postcode acts as the verification token. It doesn't mention failure modes when the postcode doesn't match, but that is a minor gap against an already-thorough annotation set.

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 sentence that leads with the returned data and closes with the required inputs and the no-sign-in guarantee. No filler, no repetition of the title.

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?

An output schema exists, so the return-field listing is a helpful preview rather than a necessity, and annotations cover the read-only/open-world profile. What's slightly missing is any hint about behavior on a postcode mismatch or unknown order number, though this is arguably the output schema's job.

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 both parameters are already documented ('Order number from the confirmation email', 'Delivery postcode / ZIP on the order'). The description only restates that both are needed and adds the implicit pairing constraint; with the schema doing the heavy lifting, 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 (track) and resource (order) and enumerates exactly what the caller gets back: status, tracking number/URL, shipping method, line items. No sibling tool covers order tracking, and the phrase 'for any order, given the order number and delivery postcode' makes the scope unmistakable.

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 '(no sign-in needed)' clause establishes that this is the guest/unauthenticated path for order lookup, which is a clear usage condition. There are no sibling tools for order tracking to route against and no explicit exclusions (e.g., what to do for registered-account orders), 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.