site

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

With no annotations, the description carries the full behavioral burden. It does disclose pagination and the 50-item page cap, which is genuinely useful context, but says nothing about read-only safety, authentication, what happens past the last page, or the default sort order.

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, and the resource (products) is front-loaded ahead of the optional modifiers. Slightly list-like mid-sentence, but nothing 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?

No output schema exists, so the description should say more about the shape of a returned page and how `page` behaves at the boundary. It covers the filtering and page-size semantics reasonably but is thin for a 5-parameter listing tool with no annotations to lean on.

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. It glosses category ('path or name'), in_stock_only, sort, and the page-size ceiling, but leaves `page` unmentioned and gives no detail on how 'sorted' interacts with the enum values. It roughly mirrors the schema rather than filling its 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 names a concrete resource (Dining Co's products) and states the operation is a paginated retrieval, so the agent knows exactly what comes back. It does not differentiate itself from the sibling tools `search`, `filter`, or `product`, which also appear to return products — a browsing-vs-searching distinction 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 phrasing 'optionally within a category, in stock only, sorted' implies the use case (browse the catalog with optional narrowing) but never says when to reach for this over `search` or `filter`. No exclusions, prerequisites, or alternatives are 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?

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 burden, and it does disclose the returned fields (path, name, page URL, product count), which implies a read-only enumeration. However it never states read-only/non-mutating behavior, pagination, or whether results are flat or hierarchical despite the title calling it a tree.

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

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

Two compact sentences with the resource and its fields front-loaded; nothing is redundant. The second sentence is slightly awkwardly phrased ("as the category of browse") but still earns its place by hinting at downstream use.

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 appropriately compensates by listing the fields returned, and zero parameters keeps the invocation surface trivial. The main gap is that it does not explain the tree/hierarchy structure implied by the title, which an agent may need to parse results.

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 per the baseline there is nothing for the description to disambiguate; the schema is trivially complete at 100% coverage. No parameter-level meaning is needed.

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 (the category tree Dining Co organises products into) and enumerates the fields it exposes (path, name, page URL, product count). It loosely ties itself to the sibling `browse` tool, but does not sharply differentiate from `filter`, `search`, or `store`.

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" gives an implied workflow hint linking this tool's output to the `browse` tool. It does not state when to call this versus `filter` or `search`, nor any prerequisite ordering, so guidance is implied rather than explicit.

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 well: it discloses that this is a human handoff, that no order is placed and no payment is taken, and that the returned link differs by product type (own checkout vs retailer buy link). Auth, rate limits, and URL formatting are unstated, keeping it short of a 5.

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

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

Two sentences, front-loaded with the core purpose before the negative constraint. The first sentence is dense but every clause (own vs affiliate, cart vs product) carries operational meaning; nothing 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?

There is no output schema, so the description must convey the return value, and it does: one or more links, whose target depends on whether the product is own or affiliate. It stops short of stating the link format or whether multiple links can be returned together for a mixed cart.

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 ('product') is already documented in the schema as 'one product instead of the cart'. The description's parenthetical '(or one product)' restates the same default-versus-override semantics without adding format or scope detail, 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?

Names a concrete resource ('the link(s) where a PERSON completes the purchase') and enumerates the distinct link targets for own products versus affiliate products. An agent can distinguish this from siblings like cart, product, or store without opening any schema.

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?

Specifies the trigger context ('for this session's cart (or one product)') and implicitly frames the boundary by stating the server never places an order or takes payment, which tells the agent not to use it as a purchase action. No explicit alternative tool is named, 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.

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 semantics for attributes (exact, case-insensitive, keys are the store's own spec attributes) and that prices are in the store's currency. It is silent on pagination, sort behavior, and what the response contains, leaving real gaps for a 10-param 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 compact sentences, front-loaded with the core purpose and semantics, with zero filler. Dense but every clause (matching semantics, currency, example, composability) 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 10-parameter, annotation-free tool with a nested object and no output schema, the description covers the filters but omits pagination/sort behavior and parameter-level detail for several fields. It is adequate to justify the core filtering use case but not complete for the tool's full 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?

At only 30% schema coverage the description must compensate, and it does for the hardest parameter: it explains that 'attributes' takes store-specific key:value specs that match exactly and case-insensitively, and it gives price_min/price_max examples in the store's currency. It leaves page, page_size, sort, and fulfilment undescribed, so the compensation is partial but meaningful.

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 action (filtering products) and the two dimensions it filters on (attribute values and/or price range), with a concrete example. It does not, however, explicitly distinguish itself from the likely-overlapping siblings 'search' or 'browse', leaving that differentiation 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?

The closing clause 'Combine with a category, brand and in-stock' gives implied usage guidance on how the filters compose, and 'see any product's attributes' points the agent to a discovery path. There is no explicit when-to-use-this-vs-'search'/'browse' guidance or exclusion, so usage remains inferred.

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 and no output schema, the description carries the full burden. It usefully enumerates what is returned (description, price, stock, identifiers, attributes, images, purchase locations), which implies a read-only operation, but it says nothing about behavior on an unknown id/URL/GTIN, ambiguity between identifiers, or any auth/rate constraints.

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 with the lookup key front-loaded and the returned payload following, with no filler. The em-dash list is dense but readable; nothing needs to be cut.

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 enumerating the payload fields is genuinely necessary and present. For a simple single-argument lookup tool this is nearly complete, though error/not-found behavior and identifier precedence remain unstated.

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 there is only one parameter, so the baseline is 3. The description repeats the three accepted forms (id, product URL, GTIN) already documented in the schema and adds no extra meaning such as format examples or precedence rules.

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 concrete resource ('one product') and a concrete act ('everything Dining Co publishes'), and the scope is distinguishable from siblings like search, filter, browse, and categories. It stops short of explicitly naming which sibling to use instead, so it's clear but not sibling-routing.

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 is implied by scope: fetch a single product by identifier rather than browsing or searching. There is no explicit 'use this when / use search instead when' guidance, and no stated prerequisite for choosing between the three accepted lookup forms.

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 genuinely useful matching semantics (all words required, any order, case-insensitive) that the schema does not express. However, it says nothing about pagination behavior, result ordering defaults, or the page_size ceiling, leaving key operational traits undocumented.

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 zero filler, and the scope (which fields match) is front-loaded. It is efficient, though the parenthetical clause is slightly load-bearing for readability.

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 and no annotations, so the description should do more: it omits pagination/return behavior and how this tool relates to `filter` and `browse` in a crowded 7-tool namespace. It is adequate for a basic keyword search but leaves meaningful 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 25%, so the description needs to compensate; it fully explains the semantics of `query`, which is the important one. The other three parameters (page, page_size, sort) get no added meaning beyond the schema's enum and min/max constraints.

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 (match words) and resource (Dining Co products), and enumerates the searchable fields (title, description, brand, category, attributes), so the agent knows exactly what corpus is being searched. It does not distinguish itself from the overlapping sibling `filter`, so it falls short of a 5.

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 conveys that this is keyword search but offers no when-to-use guidance, no exclusions, and never names the alternatives (`filter`, `browse`) that a shopping agent would otherwise have to guess between. Usage is only implied.

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 burden. It discloses the informational payload and implies a read-only, no-argument call, but never states explicitly that it mutates nothing, requires no auth, or returns static metadata. For a zero-parameter read tool this is adequate but 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?

One compact sentence enumerating the payload plus a two-word imperative. Every clause earns its place. The 'Call this first' instruction is arguably the most actionable part and sits last, which is a minor front-loading miss.

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 input parameters, no output schema, and no nested structures, the description's content list is sufficient for the agent to know what comes back and when to call it. An explicit statement that it is read-only and side-effect free 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?

The tool takes no parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; no syntax or defaults need explaining.

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 what the tool returns: merchandise, currency, shipping destinations, purchase flow, and catalogue size for 'Dining Co'. That is a specific informational resource, and it is distinguishable from siblings like browse, product, or cart, which all do something rather than describe the store. It falls short of 5 only because 'store' is a generic name and the tool is defined almost entirely by its content list.

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' is an explicit ordering instruction that tells the agent when to reach for this tool relative to the others. It does not name any when-not condition or an alternative for when store metadata is unnecessary, so it stops short of full routing guidance.

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