Camden Tools

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

Annotations only indicate readOnlyHint and openWorldHint, so the description adds meaningful behavioral context: the entire basket is evaluated as a whole, and a split shipment is not allowed for eligibility. This clarifies important decision semantics beyond what annotations 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?

The description is a single focused sentence that front-loads the core purpose ('Whole-basket Website Express verdict') and then adds the critical constraint. Every word earns its place, with no repetition of schema details.

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

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

The core semantics are clear and the schema covers parameters fully, but there is no output schema and the description does not hint at the response format or what happens when the basket is ineligible. A brief note on the verdict's return shape would make it more 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 description coverage is 100%, so the schema already documents items, id, quantity, and locale. The description adds little beyond naming 'product ids and quantities' and clarifying the basket-level semantics, which is already implied by the schema structure. Baseline 3 is appropriate.

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

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

The description clearly states a specific resource (whole-basket Website Express eligibility) and operation (verdict), and the phrase 'every line must be eligible' distinguishes it from per-line or split-shipment tools like check_shipping_availability. The purpose is unambiguous and not a tautology of the tool name.

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 that this tool is for whole-basket express eligibility checks, but it does not explicitly say when to use it instead of alternatives such as check_shipping_availability, estimate_delivery, or get_express_delivery_status. No direct when-to-use or when-not-to-use guidance is provided.

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 openWorldHint=true. The description adds the 'restriction message' detail, which hints at response content, but does not disclose behavior such as error handling, unsupported countries, or whether results are cached. With annotations present, this is acceptable but minimal.

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 concise sentence with no filler. The main purpose is front-loaded, and every word contributes meaning.

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 documented parameters and no output schema, the description is minimally adequate. However, it could be more complete by clarifying typical output (e.g., boolean or unrestricted) and disambiguating from shipping-related siblings.

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 well-documented. The description adds no meaningful semantic information beyond the schema; it only refers to 'a country', which maps to country_code. 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 clearly states the tool's purpose: checking whether Camden Tools ships to a given country and returning any restriction message. It is specific about the resource and predicate, and the word 'ships' distinguishes it from express-eligibility tools, though it does not explicitly name 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?

No guidance is provided on when to use this tool versus check_express_eligibility, estimate_delivery, or get_express_delivery_status. The description implies a general shipping-availability use case but does not mention alternatives or exclusion criteria.

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 description discloses the read-only comparison behavior and the specific data returned, which adds value beyond the readOnlyHint=true and openWorldHint=true annotations. It does not cover edge cases such as invalid/missing SKUs or how unavailable data is represented, but the annotations already carry 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?

One tightly scoped sentence front-loads the operation, states the input bounds, lists the compared fields, and ends with the agent-facing purpose. There is no filler or duplication of schema details.

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

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

For a two-parameter read-only tool with no output schema, the description is self-contained: it tells the agent what to pass (SKUs), the allowed count, what data will come back, and why the tool exists. The absence of an output schema is mitigated by the explicit list of returned fields and the 'side-by-side comparison' framing.

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

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

The schema fully documents locale and the SKU string format at the item level, while the top-level skus property lacks a description; the description compensates by stating '2 to 5 products by SKU'. This is adequate but not detailed enough to raise the score above the schema-information 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 begins with a specific verb and resource: 'Side-by-side comparison of 2 to 5 products by SKU' and then enumerates the exact compared attributes (price ex/inc VAT, stock, brand, weight, specification bullet points). This clearly separates it from single-product tools like get_product and broad listing tools like list_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?

It provides clear context for when to use the tool: when an agent has 2–5 known SKUs and needs to compare options to make a recommendation. It does not explicitly name alternatives (e.g., get_product for one product or search_products when SKUs are unknown), so it lacks explicit exclusion 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?

The annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds specifics: opening the link twice does not double quantities, the result lists out-of-stock lines, and the shopper pays at checkout. These details go beyond the annotations and explain the effect on the basket and order flow.

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 five sentences long, packing in purpose, idempotency, out-of-stock handling, usage, and id source. It is front-loaded with the core action and flows logically. While slightly verbose, each sentence contributes meaningful guidance and the structure is clear.

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

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

With no output schema, the description discloses that the result includes out-of-stock line information, which is critical for the agent to act on. It also explains the basket behavior, idempotency, and that the shopper completes payment. For a simple tool with two parameters, this is virtually complete; only a minimal gap remains regarding the exact response format, which is not essential for 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?

The input schema provides complete descriptions for both parameters (items array and locale), achieving 100% coverage. The description adds a note about where ids come from, but that information is already in the schema. No additional semantics are introduced beyond the schema baseline, so a 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 that the tool converts product ids and quantities into a basket link on camdentools.com. It uses specific verbs and names the resource, distinguishing it from all sibling tools (there are no other create tools). The purpose is unambiguous.

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

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

It explicitly says 'Use it to finish a shopping conversation,' giving a clear when-to-use scenario. It also directs that ids come from search_products, list_products, or get_product, which sets a prerequisite. It does not mention exclusions or alternatives, but given the unique function, the guidance is sufficient.

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 indicate readOnlyHint=true, so the description aligns with read-only behavior. It adds value by disclosing that the estimate uses placeholder contact details and is not the final rate, which is a meaningful behavioral caveat beyond the annotations. It doesn't mention rate limits or further data, but the read-only nature is well covered.

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

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

The description is two sentences long, front-loaded with the primary function, and includes a crucial caveat about placeholder details. No waste; every sentence earns its place.

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

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

Given the moderate complexity (5 parameters, all documented, read-only, no output schema), the description is sufficient. It tells the agent what the tool does and the key limitation (placeholder rates), which is the main contextual gap. It doesn't need to explain return values since no output schema is expected, and the safety is clear from annotations.

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 does not add extra meaning to parameters beyond what the schema provides, but it reinforces the context that the estimate depends on the destination and items. No parameter is undocumented, so the schema carries the weight.

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

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

The description clearly states the verb 'estimate' and the resource 'delivery services, charges, and transit times' for a basket to a destination. It distinguishes itself from siblings like check_shipping_availability and check_express_eligibility by focusing on estimation with placeholder details, which is a unique purpose.

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: when an estimate is needed before checkout, and notes that exact rates are confirmed at checkout. It doesn't explicitly name sibling alternatives like check_shipping_availability, but the context is clear enough for an agent to infer.

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 and openWorldHint, so the safety profile is covered. The description adds that the output is plain-text full body, but it does not mention missing-post behavior, locale defaults, or any notable side effects.

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

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

The description is a single, front-loaded sentence with no redundant filler. Every word contributes to the core behavior, making it highly efficient.

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

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

For a simple get-by-slug operation, the core input and output are stated, but the description omits guidance on not-found behavior and the relationship to sibling search tools. With no output schema, those gaps are not filled elsewhere.

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 50%; locale is fully explained in the schema, while slug has no schema description. The tool description confirms slug is the lookup key but adds no detail about slug format or how locale affects the returned content beyond what the schema already says.

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 post), the lookup key (slug), and the return type (full plain-text content), making the purpose clear. It lacks an explicit verb, but the tool name and 'by slug' make retrieval unambiguous. It only implicitly differentiates from siblings like search_blog_posts.

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 about when to use get_blog_post instead of search_blog_posts or other content tools. The description simply states the lookup mechanism, leaving the agent to infer that this tool is for fetching by a known slug.

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?

Beyond the readOnlyHint and openWorldHint annotations, the description adds meaningful behavioral context: it returns only active promotions, and products are paged. This helps the agent set expectations about filtering and pagination without contradicting the annotations.

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 sentence that packs in the key elements: resource scope, filtering, pagination, and lookup key. There is no redundancy or 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?

Given there is no output schema, the description could do more to clarify what 'details' includes and how the returned promotions/products are structured. The schema covers parameter semantics well, but the description is somewhat thin for an agent that must understand the full return context.

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

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

The input schema already provides 100% description coverage for all parameters, including slug, page, locale, and per_page. The description adds little beyond the schema, 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 identifies the resource: a brand's details, active promotions, and paged products, scoped by brand slug. It is specific enough to distinguish from generic product tools like get_products or list_products, though it lacks an explicit verb like 'retrieves'.

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

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

The phrase 'by brand slug' implies the tool is used when a brand slug is available, and the schema notes the slug comes from list_brands. However, it does not explicitly contrast this tool with sibling tools such as list_products or get_products, nor does it state when not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it can report fulfillment status, enumerate applicable promotion types, compute adjusted value, and intentionally mirrors the checkout logic — all without contradicting the annotations.

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 with no filler: the first sentence front-loads the verb, resource, and outcome list, and the second adds the key guarantee that this mirrors the checkout calculation. Every phrase earns its place, making it both compact and informative.

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 read-only evaluation tool with no output schema, the description covers the essential return concepts: fulfillment, applicable promotions, free gifts, and adjusted basket value. It doesn't spell out exact output fields or error conditions, but the annotation coverage and schema completeness keep the remaining gaps minor.

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 input schema already documents all four parameters including country_code, items, locale, and has_tax_id. The description reinforces the basket context and destination-country dependency but adds little parameter-level meaning beyond what the schema provides, 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 a specific verb ('Evaluate'), a precise resource ('a prospective basket'), and the exact scope ('for a destination country'). It also lists concrete outcomes — fulfillment, promotions including free-delivery offers and free gifts, and adjusted basket value — which distinguish it clearly from product-level tools like get_product_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 makes the context explicit: it is for evaluating a prospective basket before checkout, using the same check the checkout runs. It doesn't explicitly name alternatives or state when not to use it, but the basket-level emphasis and the mention of destination-country fulfillment and adjusted basket value give clear application context among the sibling tools.

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

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

Annotations already mark the tool as read-only and open-world, and the description adds that it returns category metadata plus paged products by slug. It does not describe quirks such as default sorting, pagination limits, or locale-dependent output, though some of that is covered by parameter descriptions.

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 concise sentence conveys the core behavior with no filler. The main output fields are front-loaded, though the phrasing is slightly awkward with 'by category slug' placed at the end.

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 well-documented parameters, the description is adequate but minimal. It does not explain the shape of the product pages or provide usage context, and there is no output schema to compensate.

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 parameters are already well documented. The description only reinforces the slug-based lookup and the paged nature of products, adding no substantial 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?

The description clearly states the resource (a category) and the returned content (name, description, and paged products), keyed by category slug. It is identifiable as a single-category lookup and implicitly distinct from list-only or product-only siblings, though it does not name 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?

No guidance is given about when to choose this tool over siblings like list_categories, get_products, or get_brand_products. The slug is mentioned, but the requirement to first obtain it from list_categories appears 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?

Annotations already declare readOnlyHint and openWorldHint, and the description adds useful behavioral context: the timezone is Europe/London, bank holidays are respected, and the open status is computed for the current moment. This goes beyond the structured annotations 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 a single tightly packed sentence with no filler. It front-loads the resource and immediately lists the useful output fields, including edge-case handling for bank holidays and timezone.

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 parameterless read-only tool with no output schema, the description fully covers what the agent needs: the subject, the returned data categories, timezone behavior, and holiday handling. Nothing essential 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?

There are zero parameters and schema description coverage is 100%, so the description has no parameter semantics to explain. The baseline of 4 applies because no parameter documentation burden exists.

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 specific resource (London Click & Collect warehouse) and the exact information returned (address, opening hours, open status, next opening). It lacks an explicit differentiating statement against siblings, but no sibling tool targets collection point info, so it remains unambiguous.

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

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

Usage is implied rather than explicitly stated: an agent can infer this tool is for London Click & Collect warehouse details. There is no when-to-use or when-not-to-use guidance, nor any mention of alternatives like shipping or delivery tools, leaving some routing judgment to the 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 and openWorldHint=true, so the safety profile is covered. The description adds useful context by clarifying this is a real-time status lookup ('right now') and by listing the conveyed facts. It does not detail edge cases, but the annotations carry the main behavioral 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?

The description is one compact sentence that defines the service, specifies its constraints, and front-loads the primary purpose. Every phrase earns its place, and there is no redundant or filler content.

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 status tool with one optional parameter and no output schema, the description provides the core information an agent needs: what is being checked and what results to expect. It does not explain how to distinguish this from eligibility checks, but that gap is minor given the straightforward purpose.

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

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

The schema fully documents the single optional locale parameter, including its format, examples, and effects. The description adds nothing about parameters, but with 100% schema coverage 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 clearly identifies the resource (Website Express) and the specific information returned: current availability, order-by cutoff, and promised dispatch date. It does not explicitly name or distinguish itself from the closely related sibling tools like check_express_eligibility, so it misses the top score.

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

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

The description implies the tool is used to check the current availability of Website Express, but it gives no explicit when-to-use guidance and does not mention alternatives such as check_express_eligibility or estimate_delivery. An agent is left to infer the correct selection among several shipping-related 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 and openWorldHint, so the safety profile is covered. The description adds useful behavioral detail by disclosing that the result is the full policy text formatted as markdown, which is beyond what the annotations or schema specify.

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 that efficiently communicates the resource, format, and allowed policy types. There is no redundant or filler content.

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 one required enum parameter and an optional locale documented in the schema, the description is complete. It explains the return format (markdown full text) and the policy types, so an agent has enough context to invoke 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 coverage is 50%; the locale parameter is well documented in the schema, while the policy parameter has only an enum. The description restates the enum values in prose but adds little semantic meaning beyond what the enum already conveys. It does not explain locale behavior or defaulting, though the schema covers that.

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

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

The description states a specific verb ('get') and resource ('store policy'), specifies the output format (markdown full text), and enumerates the exact policy types. This makes the tool's purpose unmistakable and naturally distinguishes it from content-retrieval siblings like get_blog_post or get_site_info.

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

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

The description implies the tool is for retrieving store policy text, but it does not explicitly state when to use it over alternatives or provide exclusion criteria. The resource scope makes the intended use reasonably clear, but no direct guidance or alternative routing is provided.

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 mark this as read-only and open-world, so the safety profile is covered. The description adds transparency beyond that by revealing currency and pricing behavior tied to the destination country and enumerating exactly what price components are returned.

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 with no filler. The operation is front-loaded)Skip , and the return values are stated immediately, making the description efficient and scannable.

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

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

With no output schema, the description's enumeration of returned prices fills the most important gap. Combined with fully documented parameters and readOnly/openWorld annotations, this is sufficient for an agent to select and invoke the tool correctly; a note on sibling distinctions would be the only minor enhancement.

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 fully documents shipping_country, items, and locale. The description only provides general framing like 'set of products' and 'destination country' rather than adding parameter-level detail, which aligns with the baseline for high schema coverage.

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 ('prices for a country') and further scopes it to a set of products. The explicit return values—unit, sale, final prices, and subtotal—make the operation concrete and distinguishable from single-product or promotion tools.

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

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

Country-specific pricing for a set of products gives clear context for when this tool should be used, such as checkout or basket pricing for a destination country. It does not explicitly name sibling alternatives like get_product or get_product_promotions, but the purpose is clear enough that an agent can route correctly.

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 openWorldHint=true, covering the safety profile. The description adds meaningful behavioral context by enumerating exactly what will be returned (prices ex/inc VAT with bulk breaks, stock, variants, documents, canonical URL) and by adding the exclusivity constraint on identifiers. No contradiction with annotations.

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 carry the full purpose, return content, identifier options, and a hard usage constraint. No filler, no repetition of schema text; information is front-loaded and every clause earns its place.

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

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

With no output schema, the description compensates by listing the major return categories in enough detail for an agent to gauge response shape. Minor gaps remain, such as error behavior when zero or multiple identifiers are supplied, but the description is otherwise self-sufficient for a safe read-only lookup.

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 each parameter already has a clear description. The description adds genuine value beyond the schema by imposing the constraint that exactly one of slug, sku, or id be provided, which the schema does not enforce. This guides correct invocation beyond the structured parameter docs.

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 ('Full details for one product') with a specific resource and scope ('by slug, SKU or id'). The phrase 'full details' plus the enumerated content (description, specifications, prices, stock, variants, documents, canonical URL) clearly distinguishes it from specialized siblings such as get_product_documents and get_product_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 communicates how to use the tool ('Provide exactly one of slug, sku or id') and implies it is the general-purpose product lookup, but it never explicitly names alternatives or states when not to use it. An agent can infer usage context but is not given 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 openWorldHint=true, so the safety profile is covered. The description adds that the tool returns document URLs and can identify a product by slug or SKU, but it does not disclose response structure or behavior for missing/ambiguous inputs.

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 tool's purpose and immediately states the key output ('Returns document URLs'). Every word earns its place with no 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 no output schema, the description provides the essential output type (document URLs) but omits which parameter combination is expected or whether sku/slug is required. It is adequate for selection but leaves some invocation ambiguity, especially since all parameters are optional.

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 fully documents sku, slug, and locale. The description reinforces that slug or SKU can identify a product, but it adds no meaning beyond what the parameter descriptions already provide.

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 ('product documents') and enumerates the document types returned: safety data sheets, specification sheets, and COSHH hazard codes. This differentiates it from siblings like get_product or get_related_products, though it does not explicitly contrast with them.

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

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

The description implies this tool is for retrieving product safety/spec documents rather than general product details, but it provides no explicit when-to-use versus alternatives or exclusions. The context is clear enough to infer, but the guidance is not directly 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 and openWorldHint=true, so the description does not need to restate that. It adds context about what 'active' means (promotions with discounts, free gifts, end dates) but does not disclose any pagination, empty-result behavior, or rate limits. Given the annotations cover the main safety profile, a 3 is appropriate – the description adds some value but not rich behavioral detail.

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 that includes the core purpose and scope, with zero filler. Every word earns its place, and the most important info (one SKU) appears first.

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 well-documented parameters and no output schema, the description is sufficient for an agent to invoke it correctly. It could explicitly mention that it returns only active promotions and possibly that it may be empty, but the current text covers the essentials. No significant gaps that would prevent correct usage.

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

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

Schema description coverage is 100%, so both parameters (sku and locale) are fully documented in the schema. The description adds no additional meaning beyond what the schema already provides – it just restates that it applies to a single SKU. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description clearly states the verb (get), the resource (product promotions), and the scope (one SKU), and distinguishes it from siblings like get_cart_promotions (cart-level) and list_offers (broader). It also specifies the content types (discounts, free gifts, end dates), leaving no ambiguity about what the tool returns.

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 usage for a specific product SKU, and the sibling names make it clear this is distinct from cart-level promotions. However, it does not explicitly state when NOT to use it or mention alternatives, though the context is sufficient for an agent to infer correct usage.

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 provide readOnlyHint and openWorldHint, and the description does not contradict them. It adds useful behavioral detail by specifying the 50-item limit and the returned compact fields (name, price ex/inc VAT, stock, link). It does not cover not-found behavior, but the safety profile is already handled by annotations.

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 short, front-loaded sentences with no filler. It states the action, constraints, and return fields efficiently, and every sentence adds value.

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 batch lookup with no output schema, the description covers the essential lookup keys, the maximum batch size, and the main returned fields. It omits edge-case behavior such as invalid or missing identifiers, but these are minor for safe invocation.

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

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

Schema description coverage is only 33%, and the description partially compensates by explaining the two lookup keys (SKU or numeric id) and the batch size. However, it does not clarify whether at least one of ids/skus is required or whether both can be used together, which is a meaningful gap given that required parameters is 0.

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 and resource: 'Look up up to 50 products at once by SKU or by numeric id.' It clearly identifies the batch-lookup scope and distinguishes it from single-product get_product or search-oriented siblings like search_products and list_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?

The context is clear: this tool is for retrieving multiple known products by SKU or numeric id, not for searching or listing. It does not explicitly name alternatives or exclusions, but the identifier-based lookup context leaves little ambiguity about when it applies.

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 the operation read-only and open-world, so the safety profile is covered. The description adds the behavior of returning a collection of related item categories but does not describe ordering, pagination, or whether results vary by locale beyond what the schema already indicates. It adds some value without contradicting annotations.

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 with no filler: the first lists the resource and input format, the second gives a practical use case. All content earns its place and is 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?

This is a low-complexity read-only tool with no required parameters and full schema coverage. The description explains the return categories and the practical scenario for use. A minor gap is not explicitly stating that at least one of slug or SKU should be supplied, but 'by slug or SKU' strongly implies it.

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 clear descriptions for sku, slug, and locale. The description echoes that the product is identified by slug or SKU but adds no semantic detail beyond the schema, 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 explicitly lists the returned content types (variants, similar products, recommendations, 'you may also like' items) and identifies the input as a product slug or SKU. This clearly distinguishes it from sibling tools like get_product (single product details) and list_products (product listings).

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

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

The description gives a concrete use case: finding alternatives when something is out of stock. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to select this tool over product-detail or search tools.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds context about what information is returned (contact details, VAT rules, links, announcements, policy summaries), but doesn't disclose any additional behavioral traits such as locale-specific behavior or potential variability in announcements. The description is consistent with the annotations, so no contradiction.

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 concise and front-loaded, stating the core purpose in the first sentence and then listing the specific content areas. The final sentence about get_policy is a useful routing hint. No wasted words.

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 read-only info tool with one optional parameter and no output schema, the description is quite complete. It lists the types of information returned and points to the sibling for full policy text. The only minor gap is that it doesn't mention whether the output is localized based on the locale parameter, but the schema already covers that. Overall, the description is sufficient for an agent to call the tool correctly.

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

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

The schema description coverage is 100%, so the schema already documents the locale parameter. The description doesn't add much beyond what the schema provides, but it does mention that locale controls product names, slugs, and prices, which is already in the schema. The description doesn't explain how locale affects the store info output, but the schema covers the parameter meaning adequately.

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 purpose: it provides store information about Camden Tools, including contact details, VAT display rules, key page links, announcements, and policy summaries. It also distinguishes itself from the sibling get_policy by explicitly noting that get_policy should be used 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?

The description explicitly tells the agent when to use this tool (to get store info and policy summaries) and when to use an alternative (get_policy for full policy text). This is a clear usage guideline that helps the agent select the correct tool.

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 and openWorldHint. The description adds meaningful context by specifying 'live' and the London warehouse scope, which goes beyond the annotation hints. No contradiction exists.

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

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

A single sentence that is front-loaded with the core purpose ('Live availability check') and includes the key detail (London warehouse) without any fluff. Every word earns its place.

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

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

For a simple read-only tool with one parameter and no output schema, the description adequately conveys what it does (returns availability and quantity) and its geographic scope. It is complete enough for an agent to call it correctly without further clarification.

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

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

Schema coverage is 100% – the sole parameter 'sku' is fully described ('Product SKU exactly as shown on the site'). The description only reiterates 'for a SKU' without adding new semantics, so baseline 3 is appropriate.

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

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

Description states a specific verb ('check'), resource ('availability'), and scope ('for a SKU', 'London warehouse'). It clearly differentiates from sibling tools like get_product by focusing on live stock levels rather than product details or pricing.

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 usage when live stock information is needed but does not explicitly mention alternatives or when not to use this tool. No sibling names or exclusion conditions are given, so 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, so the safe read nature is covered. The description adds valuable behavioral context by specifying that the default result is popular brands and that a query triggers a brand-name search, which goes beyond the structured annotations.

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

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

The description is two sentences long, front-loads the core purpose, and contains no filler. Every clause earns its place: scope, examples, default behavior, and query behavior are all communicated efficiently.

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

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

For a simple read-only listing tool with no output schema, the description covers the key behavior: what it lists, the default vs. search modes, and the scope of brands. It is complete enough for an agent to call correctly, though it could briefly mention pagination or directing users to get_brand_products for product-level queries.

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 fully explains all four parameters. The description adds minor semantic context by tying the default sort to 'most popular' and explaining that query searches brand names, but this is not substantial enough to exceed the 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 tool as listing brands sold by Camden Tools, with specific brand examples (DeWalt, Makita, Milwaukee, Bosch, Stanley). It also explains the two modes: returning popular brands without a query and searching brand names with a query, making the tool's purpose 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 description implies usage context: use without a query for popular brands, use with a query to search brand names. However, it does not explicitly contrast with sibling tools like get_brand_products or list_products, so the when-not-to-use guidance is absent.

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 and openWorldHint=true, so the description does not need to cover safety or completeness. The description adds a little context by specifying the content of the result (items and prices), but it does not disclose any behavior beyond what the annotations and title imply.

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 conveys the resource type, nature of the data, and key output fields without filler. The most distinctive term ('Curated product bundles') appears first, making the purpose immediately clear.

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 listing tool with one optional, well-documented parameter and no output schema, the description is largely complete: it identifies what is returned (kits, items, prices) and the annotations cover safety and open-world aspects. Minor gaps like pagination or ordering are not critical for this simple 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?

The single parameter 'locale' is already fully described in the schema (100% coverage), including its default and effect on product names, slugs, and prices. The description adds no additional parameter information, 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 uses a specific verb and resource ('Curated product bundles (kits)') and clearly states what the tool returns ('their items and prices'). The term 'bundles' is distinct from sibling tools like list_products, list_brands, and list_offers, so an agent can identify the right tool 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?

The description provides no guidance on when to use this tool versus alternatives like list_products or list_offers. There is no mention of scenarios, exclusions, or relationships to sibling tools, leaving the agent to infer usage solely from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds the distinction between popular and full list, which is useful. It doesn't disclose pagination or default behavior beyond the schema, but the annotations cover 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?

Two sentences with zero waste. The core purpose is front-loaded, and the usage guidance for popular_only is concise. Every word earns its place.

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

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

For a simple read-only list tool with 100% schema coverage and no output schema, the description is nearly complete. It explains the key behavioral distinction (popular vs full). It doesn't describe the return shape, but no output schema exists and the tool is simple enough that the agent can infer it from the name and description.

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 all three parameters. The description adds context for popular_only ('curated set shown on the site') which enriches the schema's 'Only the popular categories'. It doesn't add meaning for limit or locale beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description states a clear verb and resource: 'Product categories with slugs and links.' It distinguishes itself from siblings like get_category (singular) and list_products/list_brands by focusing on categories. However, it doesn't explicitly name a sibling alternative, so it doesn't fully differentiate from other list_* tools.

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

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

The description gives explicit guidance on when to use popular_only: 'Use popular_only for the curated set shown on the site; otherwise the full list.' This tells the agent when to set the flag. It doesn't mention when to prefer this over list_products or get_category, but the category-specific scope is clear.

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 openWorldHint=true, so the safety profile is covered. The description adds context about the promotion types and the 'current' temporal scope, which is useful. However, it does not disclose any additional behavioral aspects like pagination, rate limits, or the meaning of the /offers page reference.

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 short and front-loads the core purpose in the first sentence. The second sentence ('Also points at the /offers page.') is vague and adds little value, but overall the description is efficient and free of fluff.

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

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

The tool is simple (2 params, both described, no output schema). The description covers the main function and grouping, but it does not clarify the return format, whether results are paginated, or the meaning of the /offers page reference. Given the lack of an output schema, a bit more detail on the expected result would be beneficial.

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% for both parameters, so the baseline is 3. The description adds minimal value beyond the schema: it repeats the grouping capability but provides no extra meaning for locale or group_by. It does not compensate for any gaps because there are none.

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

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

The description states a specific verb ('lists') with a clear resource ('current storefront promotions') and specifies the types (percentage/fixed discounts and free gifts) and an optional grouping by brand or category. It distinguishes from siblings like get_cart_promotions and get_product_promotions by scoping to storefront-level offers, so an agent can tell it apart without opening schemas.

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

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

The description gives no explicit guidance on when to use this tool versus the many sibling tools (e.g., get_cart_promotions, get_product_promotions). The scope is implied by 'storefront promotions', but there is no mention of exclusions or alternatives, leaving the agent to infer the selection criteria.

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 description discloses meaningful behavior beyond the readOnlyHint annotation: it supports paging, sorting, and brand/price filters, and it covers multiple curated collection modes. It does not mention output shape or pagination defaults, but given the read-only annotation and fully described schema, this is a reasonable level of transparency.

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, and the most important information is front-loaded. The description efficiently conveys the tool's scope, collection variants, and available operations while referencing a sibling tool for additional 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 10-parameter browsing tool, the description combined with the fully documented schema is sufficient for an agent to call it correctly. The absence of an output schema is mitigated by the tool name and 'browse' semantics, though explicit mention of the return shape would make it fully 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 description coverage is 100%, so the baseline is 3. The description adds value by mapping conceptual collection types to parameters, clarifying 'category by slug', and highlighting brand/price filtering options in one place. This goes beyond the raw schema without repeating every parameter detail.

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

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

The description opens with a specific verb and resource ('Browse a product collection') and explicitly enumerates the supported collection types: popular, newest, on-sale, Website Express eligible, and category by slug. This clearly distinguishes it from sibling tools like get_product, get_brand_products, and search_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?

The description gives clear context for when to use the tool: browsing a curated product collection with paging, sorting, and filtering. It also cross-references list_categories for obtaining category slugs. It does not explicitly state when not to use it or name alternatives, but the browse-by-collection framing is enough for an agent to select it appropriately.

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

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

The description adds useful behavior beyond the readOnly/openWorld annotations: it warns about upstream rate limiting and explains that incomplete postcodes yield suggestions. This helps the agent anticipate throttling and non-exact results, though it does not detail error behavior or suggestion format.

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 convey the core behavior, a caveat, and the edge-case behavior without any filler. The most important information is front-loaded: what the tool returns, then the rate-limit warning.

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 lookup, the description is largely complete: it names the input domain, the output type, and a special case. It could have described the exact shape of returned addresses or suggestions, but the absence of an output schema is partially mitigated by the straightforward nature of the 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 description coverage is 100% and the postcode parameter already has a clear example ('NW2 7JW'). The description itself adds no further parameter-level detail, 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 clearly states the resource and action: it returns addresses for a UK postcode. It also clarifies the incomplete-postcode case where suggestions are returned. There are no sibling tools overlapping with postcode lookup, so no ambiguity remains.

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 intended use is obvious from the description: call it when an address lookup for a UK postcode is needed. It also covers the partial-postcode case by noting suggestions, providing clear context. It does not explicitly state when not to use it, but no alternative address tool exists among the 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 and openWorldHint=true, so the agent knows this is a safe, stateless read operation. The description adds that results are limited to blog content (not products), which is useful, but does not explain pagination or ordering behavior beyond the page parameter. With annotations covering safety, a 3 is appropriate.

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, concise sentence that front-loads the key information: it's about the blog, and the parenthetical lists content types. No wasted words.

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

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

Given the tool's simplicity (2 parameters, no required params, no output schema), the description is adequate. It tells the agent what kind of content will be returned (blog posts), and annotations handle safety and open-world assumptions. Minor missing details like pagination limits are already in the schema. A 4 reflects completeness relative to complexity.

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 'query' and 'page' are already documented. The description implies the query searches blog posts but does not add syntax or behavior details beyond the schema. 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 clearly states the resource (Camden Tools blog) and the content type (guides, articles, how-tos, etc.). It distinguishes itself from siblings like get_blog_post (which likely retrieves a single post) and search_products (which searches products, not blog content).

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 usage (searching blog posts) but does not explicitly contrast with siblings like get_blog_post or search_products. It provides contextual hints about content type, but lacks explicit when-to-use or when-not-to-use 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 mark the tool read-only and open-world; the description adds that it 'Returns compact products with prices ex/inc VAT, stock and a link', setting payload expectations and confirming read-only search behavior. This goes beyond the structured annotations without contradicting them, though it doesn't cover result pagination metadata or external-data caveats.

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

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

The description is two sentences, front-loads the core purpose, and each sentence adds a distinct piece of information: what the tool searches and what it returns, then how to paginate/filter. No filler or repetition.

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 9-parameter search tool with no output schema, the description covers the catalogue scope, the response shape (compact products, VAT prices, stock, link), and the key pagination/filter controls. It doesn't describe the surrounding result envelope or query-matching semantics, but the schema and read-only/open-world annotations cover the remaining structured context.

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

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

With 100% schema description coverage, the schema already documents all nine parameters. The description adds value by grouping them into functional roles: 'page/per_page to paginate' and 'brand/min_price/max_price to narrow down,' which helps an agent assemble a query correctly.

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

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

The description opens with 'Full-text search of the Camden Tools catalogue', naming a specific verb, resource, and scope, and lists the catalogue categories. The 'full-text search' phrasing and the compact-result return set distinguish it from sibling listing/detail tools, though it does not explicitly name 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?

It tells the agent how to use the tool ('Use page/per_page to paginate and brand/min_price/max_price to narrow down'), which implies it is the right choice when the shopper has a free-text query. It does not state exclusions or name alternatives such as list_products or get_product, so the when-to-use guidance is only implicit.

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 mark it read-only and open-world, and the description adds useful behavioral context: no sign-in required and which specific order fields will be returned. It does not mention error behavior for mismatched postcodes, but the read-only annotation lowers the burden and this is still well above minimal.

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 front-loads the return fields and then gives the required inputs and auth condition. No filler or repetition.

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 read-only, two-parameter lookup with no output schema, the description covers what is returned, how to call it, and the auth requirement. An agent has enough information to select and invoke the tool successfully.

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 both parameters already carry clear descriptions (order number from confirmation email, delivery postcode/ZIP). The description only restates 'order number and delivery postcode' without adding per-parameter constraints, so it meets but does not exceed the 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 title 'Track an order' plus the description enumerates the exact return payload (order status, tracking number/URL, shipping method, line items) and the access condition (order number + postcode, no sign-in). This is specific enough to be told apart from a narrower sibling like get_express_delivery_status.

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 a clear trigger: when an agent needs order-status/tracking details for an order using just the order number and delivery postcode, with no account login. It does not name when-not-to-use or point to an alternative, 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.