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 states the 50-per-page cap, which the schema already enforces via page_size maximum=50. It omits the default page size, whether page numbering is 0- or 1-based, whether a total result count is returned, and any permission or rate-limit behavior.

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

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

A single tightly packed sentence that front-loads the resource and folds scope, filtering, sorting, and the page-size cap into one clause 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?

For a 5-parameter paginated list tool with no output schema, the description should clarify pagination defaults and the relationship to search/filter. It covers the browse surface adequately but leaves the agent guessing about defaults and how results are returned.

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% across 5 parameters, so the description must compensate. It does add useful meaning for category (path or name), the stock-only flag, and sorting direction, but page and page_size semantics (defaults, numbering, behavior at the boundary) remain 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?

The description gives a specific verb (browse/list) and resource (Media Depot's products) and adds scope modifiers: category filtering, stock filtering, sorting, and page size. It is clear what the tool does, but it never distinguishes itself from siblings like search, filter, or product, which an agent could easily confuse with browsing a catalog.

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

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

There is no explicit guidance on when to use browse versus search, filter, categories, or product. The optional category parameter hints at a browsing use case, but the agent must infer the boundary itself, and no exclusions or prerequisites 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only enumeration by describing what the categories contain, but says nothing about side effects, permissions, or the shape/ordering of the returned data.

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

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

Two short sentences with no padding; the resource and its fields are front-loaded. The second sentence is slightly awkwardly phrased ('as the category of browse'), costing a little clarity.

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 usefully enumerates the fields returned (path, name, page URL, product count), which partially substitutes for structured output. It still leaves ambiguous whether the result is hierarchical (tree) or flat, which matters for how an agent consumes 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The mention of path and name describes attribute values of the data (and keys for browse), which is a small bonus rather than a parameter contract.

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 (the categories Media Depot organises products into) and enumerates its fields, so an agent can infer it exposes a category listing. However it is a bare noun phrase with no verb (list/return/fetch) and never states whether the result is a flat list or a tree despite the title 'The category tree'.

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' points the agent toward the sibling 'browse' tool and the values it accepts. It implies usage but gives no explicit when/when-not or the reason to call this tool versus browse directly.

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 so for the most important trait: 'This server never places an order or takes a payment,' setting accurate expectations about a human handoff. It omits secondary behavior (link expiry, whether it mutates the cart), but the critical safety expectation is explicitly disclosed.

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

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

A single dense sentence that front-loads scope then the key assertion. Each clause earns its place, though the parenthetical 'Media Depot's own checkout' is slightly redundant.

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

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

No output schema exists, yet the description explains what the returned links are (own product page/store cart vs affiliate retailer buy link), which covers the main unknown. Minor gaps remain around link lifetime and cart mutation, but nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% and the single parameter is already documented, so the schema does the heavy lifting. The description restates the schema's 'one product instead of the cart' and adds the implicit default (the session's cart), which is a marginal value-add over structured data.

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+resource — it returns the link(s) where a human completes a purchase — and clarifies the tool is a link provider, not a checkout executor. It does not name siblings (cart, product) to differentiate, but the 'links, not the data/order' framing makes its role reasonably distinct.

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

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

Usage is only implied: the agent can infer 'use this when a buyer needs to finish a purchase.' The scope toggle ('this session's cart, or one product') hints at when the parameter applies, but there is no explicit when-to-use vs alternatives or when-not guidance.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that attribute matching is exact and case-insensitive and that price is in the store's currency in major units, but it omits whether the operation is read-only, how pagination behaves, and what the default sort is.

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

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

The core filtering semantics are front-loaded in a single dense sentence, and the price example earns its place. The parenthetical 'see any product's attributes' is slightly awkward but functional; little 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?

For a 10-parameter tool with a nested object, low schema coverage, and no annotations or output schema, the description covers the main filtering path but leaves fulfilment, sorting defaults, and pagination unexplained. Adequate but clearly incomplete given the tool's 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?

With schema coverage at only 30%, the description compensates by explaining attributes as the store's own specification keys with exact, case-insensitive matching, and by giving a concrete price example (price_min 200, price_max 1500). It still says nothing about 'fulfilment' (own vs affiliate) or pagination/sort behavior, so several of the 10 parameters remain unclarified.

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 operation: products of Media Depot matched by attribute values and/or a price range. It conveys the filtering purpose well, but never distinguishes itself from the sibling 'search' or 'browse' tools, which likely also return product lists, leaving the agent 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?

The closing clause 'Combine with a category, brand and in-stock' implies how to compose a query, and the 'see any product's attributes' note hints at a discovery workflow. However, it never says when to prefer this over 'search' or 'browse', nor does it state any 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 behavioral burden. It implicitly indicates a read-only lookup by saying it returns what is published, and it usefully lists the full breadth of returned data, but it does not mention error behavior (e.g., product not found), authentication, 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?

A single sentence, front-loaded with the core distinction ('one product'), followed by accepted identifier types and an efficient field list. Every clause adds value 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?

For a simple read lookup with a fully documented input schema and no output schema, the description compensates by listing the returned fields and accepted identifiers. It is nearly complete, with only minor missing behavioral details such as not-found handling.

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 already documents the single 'product' parameter at 100% coverage, including that it accepts an id, product page URL, or GTIN. The description repeats this same information without adding format details, examples, or constraints beyond the schema, 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 specific resource ('one product') and scope ('Everything Media Depot publishes... in full'), and it enumerates the returned data fields (description, price, stock, identifiers, attributes, images, where bought). This clearly distinguishes it from list-oriented siblings like search, browse, and filter, which return multiple items.

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

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

The description implies when to use the tool by specifying accepted keys ('by id, product URL or GTIN'), but it never explicitly names alternatives like search or filter, nor does it state when not to use this tool. Usage is inferable but not spelled out.

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. It usefully reveals the matching algorithm — all query words must appear, in any order, case-insensitive — which is genuine behavioral value not present in the schema. However, it omits pagination behavior, default ordering, result limits and the fact that this is a non-mutating read.

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 rules are front-loaded where an agent will read them. It is efficient, though the parenthetical clause packs several caveats into one parenthetical.

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 annotations and no output schema, so the description is the only source of behavioral context, yet it says nothing about result shape, pagination or ordering. For a paginated search endpoint with a 50-item page cap in the schema, an agent lacks enough to call it confidently.

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

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

Schema description coverage is only 25% (just 'sort'), and the description compensates only for the query parameter's semantics. The page, page_size and sort parameters get no explanation of defaults, ranges or effect on results, leaving three of four parameters under-documented.

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 in the Media Depot catalogue) and precisely defines the operation: a full-text match across title, description, brand, category and attributes. It is specific enough to distinguish a full-text search from a facet tool like 'filter', though it never names 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?

There is no guidance on when to use this versus 'browse', 'filter', or 'categories', and no mention of prerequisites or when a result set is better obtained another way. The agent must infer the routing decision entirely on its own.

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 behavioral burden. It discloses the informational nature and content of the response (currency, shipping, purchase flow, catalogue size), which implies a safe read, but it never states read-only behavior, side effects, or auth requirements explicitly.

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 terse sentences: a content enumeration followed by a directive, with zero filler. The listing is slightly clipped (e.g. 'where it ships'), but nothing is wasted and the action comes after the content, which is a sensible order here.

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 must convey what comes back, and it does by enumerating the five content areas. Input, output and sequencing are covered; only the behavioral/read-only profile is left implicit for a zero-parameter 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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. No parameter meaning is missing because none exist.

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 (Media Depot's store-level facts) and enumerates exactly what it covers: assortment, currency, shipping, purchase completion, catalogue size. That distinguishes it from siblings like browse, search, product and categories, which are per-item or per-listing tools. It lacks an explicit verb (e.g. 'returns'), but the resource scope is 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?

'Call this first' is an explicit sequencing directive that tells the agent this is an orientation call preceding browse/search/cart. It gives clear context for use but names no exclusions and does not contrast against any specific alternative sibling.

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