site

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

With no annotations, the description carries the full burden, yet it only repeats capabilities found in the schema and does not disclose read-only nature, permissions, pagination defaults, or error behavior for out-of-range pages.

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 wastes no words. It efficiently conveys the essential scope and limit.

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 5-parameter tool with no annotations and no output schema, the description is too thin: it does not explain pagination defaults, sort defaults, result contents, or how to distinguish browse from search/filter. It leaves the agent under-informed 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 40%, so the description must add meaning, and it partially does by clarifying category path/name, in_stock_only, sorted output, and the 50-item page limit. It omits the page number semantics and the four sort enum values, leaving gaps.

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 ('Slumber Direct's products') and lists filters (category, stock, sort), making the tool's function clear. It does not distinguish itself from siblings like search, filter, or product, so an agent must infer when to prefer browse.

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 when-to-use guidance or alternatives are provided; the description only enumerates capabilities. An agent receives no help in deciding between browse and search or filter.

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

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

With no annotations, the description carries the full burden and does disclose two meaningful traits: the cart is scoped to this MCP session (not the store's persistent cart) and totals are live from the feed. It does not say what clear destroys, whether operations are idempotent, or how errors (e.g. invalid product) are surfaced, which matters for a mutation-capable tool.

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 the scoping constraint (session cart, never the store's cart) front-loaded before the action list and the checkout handoff. 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?

For a 3-parameter, no-annotation, no-output-schema tool, the description covers actions and handoff but does not describe what view returns (cart shape, totals per line) or failure behavior. Adequate but leaves an agent guessing about the return surface.

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 67%: qty and product both carry schema descriptions, while action relies on the enum alone. The description adds marginal context by mapping 'set a quantity' to the set action, but adds no detail beyond the schema, so the 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 names the exact resource (a session-scoped cart) and enumerates the full action set (add/remove/set/view/clear), so an agent knows precisely what the tool does. It also explicitly distinguishes itself from the store's own cart, which is the key ambiguity for a shopping MCP.

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 context for the cart's lifecycle and routes the buyer to checkout_link to complete the purchase, which is strong sibling guidance. It stops short of stating when to prefer this over alternatives like product or search for gathering item details.

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

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

With no annotations, the description carries the full behavioral burden. It implies a read (it exposes categories and fields) but never states that it is read-only, whether results are a flat list or a nested tree (despite the title), pagination, or auth requirements. Behavioral disclosure is thin.

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, reasonably front-loaded, but the second sentence ('Use a path or a name as the category of browse') is grammatically awkward and its meaning is ambiguous, costing clarity per unit of length.

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 no-param read tool with no output schema, mentioning the returned fields is helpful, but the description never conveys the hierarchical 'tree' structure the title promises nor whether the list is flat or nested. Adequate but with a clear 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?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to clarify beyond the (absent) inputs.

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 the resource clearly ('The categories Slumber Direct organises its products into') and enumerates returned fields (path, name, page URL, product count). However, it names no verb and does not explicitly differentiate itself from browse/search/filter beyond one oblique reference. Purpose is understandable but under-active.

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 a path or a name as the category of browse' implies the tool feeds the browse sibling, giving a hint of downstream usage. But there is no explicit when-to-call, when-not-to-call, or named alternative, leaving usage 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?

With no annotations, the description must carry the behavioral burden, and it does the most important part: it explicitly declares the server never places an order or takes a payment, ruling out any side effect. It does not cover auth requirements, link expiry, or whether affiliate links are tracked, so it is strong but not exhaustive.

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 tightly packed sentence plus a short safety clause, front-loaded with the deliverable and then the variants. Slightly dense with parentheticals, but no sentence is wasted.

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 and no annotations, the description covers what the tool returns (product page, own store cart link, affiliate buy link) and what it explicitly does not do, which is the key ambiguity for a link-producing tool. Auth, expiry, and rate-limit behavior remain unaddressed but are secondary for this handoff-style 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% and the single parameter's description ("one product instead of the cart") is already fully documented in the schema. The description mirrors that same meaning ("or one product") without adding format, ID, or identifier guidance, 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 states a specific deliverable: the link(s) where a human completes checkout, for the session cart or a single product. It also differentiates the two link sources (own checkout via Slumber Direct vs retailer buy link for affiliates), which lets an agent understand the output without opening anything else. It stops short of naming which sibling tool to use instead for other checkout-related needs.

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 through the scope statement ("for this session's cart (or one product)"), which tells an agent the tool operates on the current cart unless a product is supplied. There is no explicit when-to-use vs alternative guidance and no named sibling to route to, so it lands at minimum-viable.

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

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

With no annotations, the description carries the full disclosure burden, and it does add real value: attribute matching is exact and case-insensitive, and price is expressed in Slumber Direct's currency. It omits other behavioral traits an agent needs, such as default sort, pagination behavior, page_size limits, and what fulfilment=affiliate implies.

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 dense sentence with no filler, and the core matching semantics are front-loaded. The run-on construction bundles matching rules, currency, examples, and composition advice together, which hurts scannability.

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, no-annotation, no-output-schema list tool with low schema coverage, the description covers the central filter semantics but leaves pagination, sorting, and fulfilment behavior unexplained. An agent can invoke the primary filters correctly but would guess at result-set control.

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 30%, so the description must compensate, and it does explain the attributes object semantics (key: value, exact, case-insensitive, store's own spec keys) plus price_min/price_max currency and units. It says nothing about page, page_size, sort, or fulfilment, leaving four parameters undocumented in both places.

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 ('Products of Slumber Direct matching attribute values and/or a price range'), so an agent knows this is attribute/price filtering rather than keyword retrieval. It never names siblings such as search or browse, so the differentiation from those tools is left implicit.

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 hints at composition ('Combine with a category, brand and in-stock') and points the agent at any product's attributes for valid keys, which is useful implied usage. However, it never states when to prefer this over search or browse, nor any exclusion conditions.

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

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

With no annotations, the description carries the full burden, and it does disclose that this is a comprehensive read returning description, price, stock, identifiers, attributes, images, and retail availability. It does not state behavior on a missing/ambiguous identifier, nor any auth or rate-limit characteristics.

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 that front-loads the resource and then lists return coverage, with no filler. It is efficient, though the trailing field list runs long relative to the amount of guidance it provides.

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?

No output schema exists, so the description correctly shouldered the job of describing return contents, and it does so with an explicit field inventory. Remaining gaps (error/not-found behavior, image format) are minor for a single-lookup read 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% and the single parameter is already documented as 'product id, product page URL, or GTIN'. The description restates the accepted identifier forms without adding format examples, precedence rules, or lookup semantics 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 (one product, addressed by id, URL, or GTIN) and enumerates the returned fields — description, price, stock, identifiers, attributes, images, where it is bought. That scope clearly separates it from list-oriented siblings like browse, search, and filter, 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?

There is no when-to-use statement, no statement about when not to use it, and no pointer to the alternative tools (search, browse, filter) for multi-product needs. The single-product scope is inferable but never asserted as a selection 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the matching algorithm (all words, any order, case-insensitive) and the fields searched, but says nothing about result caps, default ordering, or pagination behavior, which matter for a search 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?

A single dense sentence with no filler; the matching rule and searched fields are front-loaded. It is fragment-like rather than a complete sentence, but 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?

For a four-parameter search with no annotations, no output schema, and 25% schema coverage, the definition explains the query but omits pagination and ordering defaults. The agent can form a valid call, but not predict result-set behavior.

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 25% (just 'sort'), so the description must compensate. It adds genuine meaning for 'query' (word matching across five field groups, order- and case-insensitive), but leaves 'page' and 'page_size' entirely undocumented in both schema and description.

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 (Products of Slumber Direct) and precisely defines the matching rule across title, description, brand, category and attributes, which an agent can act on. It does not explicitly contrast against the sibling 'filter' or 'browse' tools, so sibling differentiation is left to inference.

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 statement of when to use keyword search versus the sibling tools 'filter' (faceted) or 'browse' (unfiltered listing), nor any exclusion. The semantics of the query are clear, but the routing decision between search and its siblings 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?

No annotations are provided, so the description carries the full burden, and it does disclose the informational, read-only nature of the tool plus the exact content categories returned. It does not discuss whether results are cached, static, or whether the 'first call' is mandatory, which keeps it from a 5 for a zero-annotation tool.

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 terse sentence lists the returned fields and then front-loads the imperative 'Call this first' into the final clause. Every element earns its place and there is 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, no annotations, and no parameters, the description must convey the return content, and the enumerated fields do that adequately. It is complete enough for an agent to call it correctly, though it could note how the store metadata relates to the sibling discovery tools.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. The description correctly signals a no-argument call by focusing entirely on returned content.

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 enumerates exactly what the tool returns — merchandise, currency, shipping destinations, purchase flow, and catalogue size — which is a specific resource description rather than a restatement of the name 'store'. It implicitly separates itself from action-oriented siblings like cart, checkout_link, and search, though it never names 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?

'Call this first' gives explicit sequencing guidance that tells the agent to bootstrap with this tool before the browse/cart/filter siblings. It stops short of saying when not to call it or how to proceed afterward, so it is clear context without full routing detail.

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