site

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses the 50-item page cap and that category accepts either a path or a name, but it omits defaults (starting page, default sort, default page size), matching semantics for the category filter (exact vs. subtree), and any indication of result shape or total counts.

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 sentence plus a short fragment, front-loaded with the resource and its modifiers, and every clause earns its place by naming an available filter or the page cap. No filler or redundant restatement of the tool name.

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

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

For a 5-parameter, annotation-free read tool with no output schema, the description covers the visible knobs but not the defaults or pagination state an agent needs to page correctly, and it never says what a 'page' actually contains. Adequate but with clear gaps.

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

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

Schema description coverage is only 40%, so the description must compensate, and it partially does: it clarifies that 'category' accepts a path or a name and reinforces the page-size ceiling. It adds nothing for 'page', 'in_stock_only', or the default/'relevance' behavior of 'sort' beyond the schema's bare 'order of the results'.

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 clear resource ('Dresser House's products') with the scope modifiers that define this tool: category scoping, in-stock filtering, sorting, paging. An agent knows it returns a listing rather than a single item, but the description never distinguishes it from the closely related siblings 'search' and 'filter', so the boundary 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 when-to-use statement and no reference to any alternative, despite 'search', 'filter', 'categories', and 'product' all being plausible sibling choices for the same underlying data. The word 'optionally' hints at a browse-everything default, but nothing tells the agent when browse is preferable to 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 discloses the returned fields, which is useful, but does not state that the operation is read-only, whether it has side effects, authentication needs, or pagination behavior.

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

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

Two sentences, front-loaded with what the categories are and their fields, followed by a usage hint. Efficient, though the second sentence is slightly awkwardly phrased.

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 no output schema and no annotations, the description lists returned fields but does not clarify whether the result is a flat list or a hierarchical tree, nor does it mention safety or completeness (e.g., returns all categories).

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

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

The tool has zero parameters, so the baseline is 4. The description adds no input parameter semantics (none exist) and only references output values for use in browse.

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 (categories Dresser House organises products into) and lists the attributes returned (path, name, page URL, product count). It distinguishes itself from siblings by linking to browse, though it lacks an explicit action verb like 'list' or 'retrieve'.

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 sentence 'Use a path or a name as the category of browse' implies a workflow where this tool provides identifiers for browse, but it does not state when to call this tool versus alternatives or explicitly say to call it to fetch categories.

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 and does well for a read-only tool: it explains the different link types returned (product page, store cart for own products, retailer buy link for affiliate products) and explicitly states no order is placed and no payment is taken. It omits auth requirements and any rate/expiry caveats.

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

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

A single dense sentence with the scope front-loaded and the key non-charge guarantee trailing. It is slightly run-on due to stacked parentheticals, but nearly every clause carries information.

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

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

No output schema exists, so the description must convey return value, which it does by enumerating the link types returned. Combined with the safety guarantee, an agent has enough to call and interpret it, though auth/permission context is absent.

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 is a single optional parameter with 100% schema description coverage, so the schema already defines it. The description's 'one product instead of the cart' adds a small amount of framing about the alternative scope but little beyond the schema, so baseline 3 applies.

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

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

States a specific verb-and-resource: it returns the link(s) where a person completes purchase for the current cart or one product. It clearly distinguishes itself from siblings like cart and product by noting it is a human handoff and that 'this server never places an order or takes a payment.'

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

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

Usage is implied by 'for this session's cart (or one product),' which tells the agent the scope. However, it never explicitly says when to prefer this over cart, product, or store, nor does it name any exclusion, so routing guidance remains inferential.

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. It usefully discloses matching semantics (exact, case-insensitive, keys are the store's own spec attributes) and the currency unit for prices, but says nothing about pagination behavior, default sort, result shape, or limits despite page/page_size/sort parameters existing.

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 primary behavior. The parentheticals are information-bearing rather than filler, though the sentence crams a lot together and could be split for scanability.

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 tool with a nested attributes object and no output schema, the description covers the core filtering semantics adequately but omits pagination, sort ordering, and result-shape guidance, leaving meaningful gaps an agent would need to guess at.

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 30%, so the description has to compensate. It does add real meaning for the confusing params — attributes (key:value, exact, case-insensitive, store-specific keys) and price units (major units of Dresser House's currency, with 200/1500 examples) — but page, page_size, sort and fulfilment remain unexplained 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?

The description states a clear verb (filter) and resource (Dresser House products) and specifies the two filter axes — attribute key/value matching and a price range. It does not, however, distinguish this tool from siblings like search or browse, leaving the agent to infer the boundary.

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 hints at composition ('Combine with a category, brand and in-stock') which implies intended usage, but never states when to reach for filter versus search or browse, and offers no exclusions or alternative routing.

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 exist, so the description carries the full burden. It discloses the payload contents (price, stock, images, availability) and implicitly reads rather than writes, but says nothing about auth requirements, rate limits, caching/staleness, or what happens for unknown/discontinued identifiers.

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 front-loaded sentence with no filler; the field enumeration is the only bulk and it is doing real work because there is no output schema.

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 one-parameter read tool with no annotations and no output schema, the description compensates well by listing the returned fields. Only miss is lookup failure behavior and identity precedence among id/URL/GTIN.

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 already documents 'product id, product page URL, or GTIN'. The description restates the same three identifier forms without adding format, precedence, or validation detail, 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?

States a specific retrieval verb-scope ("Everything ... about one product") and enumerates the resource's contents (description, price, stock, identifiers, attributes, images, availability). It is clearly distinguishable from list-oriented siblings like search/browse/filter by virtue of keying on a single identifier, but it never names those siblings 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?

Usage is implied rather than stated: the accepted keys (id, product URL, GTIN) signal 'use this when you already have a specific product reference,' but there is no explicit when-to-use versus search/filter/browse, and no exclusions or prerequisites.

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 load, and it does disclose the matching behavior (all words, any order, case-insensitive) and the searched fields. It says nothing about pagination behavior, default page size, ordering default, or the 50-item cap that the schema imposes, so the behavioral picture is only partial for a read 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 front-loaded sentence that defines the resource, the matching rule, and the searched fields with zero filler. Nothing could be removed without losing information.

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

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

There is no output schema, so the description should ideally say something about what comes back (ranked result list, per-page size), and with no annotations it should say more about the read-only, non-mutating nature and pagination limits. As written it is adequate for a simple search endpoint but leaves result shape and pagination unspecified.

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

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

Schema description coverage is 25% (only 'sort' is documented), so the description must compensate. It clarifies the semantics of the required 'query' parameter (tokenized, unordered, case-insensitive matching across five fields), which the schema does not, but contributes nothing for page, page_size, or sort.

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 concrete operation (full-text match) and enumerates exactly which product fields are searched (title, description, brand, category, attributes), which is far more specific than the bare name 'search'. It does not, however, contrast itself against siblings like filter or browse, so an agent still has to infer which one to pick.

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

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

Usage is only implied through the matching semantics: keyword-in-any-field searching naturally suggests this is the tool for free-text queries rather than structured narrowing (filter) or top-level navigation (browse, categories). No explicit when-to-use or when-not-to-use statement and no named alternative is given.

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 full burden. It usefully discloses the returned fields, which is behavioral context for a tool with no output schema, but it says nothing about authentication, whether any state is created, or rate limits.

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

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

Two compact sentences, front-loaded with the most important routing instruction implied by the content list and closed with the imperative 'Call this first.' No filler, though the comma-run of return items is slightly dense.

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

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

For a zero-parameter tool with no output schema and no annotations, the description does the necessary work by enumerating what comes back, leaving the agent able to decide whether to call it. Input-side completeness is moot and return-side is adequately covered.

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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate or compensate for.

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 specific resource (store-level metadata: catalogue contents, currency, shipping, checkout flow, catalogue size) with enough specificity that an agent can distinguish it from product/search/browse siblings. It lacks an explicit verb like 'Get', but the enumerated return content makes the purpose 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?

'Call this first.' gives explicit ordering guidance that tells the agent when to reach for this tool relative to the rest of the toolkit. It does not name when *not* to use it or point at a specific alternative, so it falls 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.