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

The description discloses the destructive side effect, the required user confirmation, the post-action verification read of the cart, and the two-step confirmToken fallback. This adds substantial behavioral context beyond the annotations.

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

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

Three focused sentences with no fluff: purpose first, then confirmation behavior, then fallback mechanics. Every sentence earns its place.

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

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

For a destructive tool with no output schema, the description covers the key behavioral requirements: removal, confirmation, verification, and token handling. It does not detail empty-cart or declined-confirmation edge cases, but those are secondary.

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?

Input schema already documents confirmToken in detail, and the description reinforces the phase-1 preview and repeat-call semantics. It adds useful operational context about when the token is needed without contradicting the schema.

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

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

The description states a specific verb and exact scope: 'Remove ALL items from your signed-in Groupon cart.' This makes it clearly distinct from sibling tools like groupon_view_cart and groupon_purchase.

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 clearly explains when to use the tool and how the confirmation flow works, including the fallback path for clients without elicitation support. It does not explicitly name alternatives when not to use it, but the ALL-items scope is explicit enough.

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

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

Annotations already declare readOnlyHint=true, and the description is consistent with that safety profile. Beyond the annotation, the description adds valuable behavioral detail: the default slim projection lists its exact fields (title, subtitle, merchant, price, rating, division, url, option id/title/price/isSoldOut) and the view='full' alternative. This exceeds what the annotation conveys.

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

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

Two sentences with zero repetition of the schema: the first names the resource and key, the second discloses the default projection, the full-view alternative, and the purchase workflow. Every clause earns its place and the most decision-relevant fact (single deal, fetched by slug) is front-loaded.

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

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

With no output schema present, the description compensates by stating the default return shape and listing its fields, plus the full-record alternative. All three parameters are fully documented in the schema and read-only behavior is covered by annotations. Only minor gaps remain (e.g., 404/not-found behavior for bad slugs), which is acceptable for a simple 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 description coverage is 100%, so the schema already documents dealId (slug/URL, last-path-segment behavior), view (compact vs full), and optionId (optional focus). The description adds one genuinely useful bit — that option IDs are what you pass to groupon_purchase — but the schema carries the bulk of parameter meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description opens with a specific verb+resource pair — 'Fetch a single Groupon deal' — and identifies the exact key (permalink slug or full deal URL). This clearly distinguishes it from groupon_search_deals (multi-result search) and groupon_purchase (transactional action). An agent can tell what this does without opening the 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?

The description implies usage context: use this when you have an exact deal slug or URL, and use groupon_purchase when you have an option id from the returned projection. It names groupon_purchase as a downstream step, but never explicitly says 'use groupon_search_deals when you lack a deal identifier' or otherwise contrasts this with sibling tools. The when-to-use is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, and the description's 'report' is consistent with that. The description adds that deal-read tools are 'a later phase,' providing context about the server's current deployment state. No side effects are claimed, and it does not contradict annotations.

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

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

The description is two sentences, with the primary purpose in the first and a context note in the second. No filler, front-loaded, and each sentence earns its place.

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

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

For a simple health-check tool with no parameters and no output schema, the description is adequate. It defines the tool's purpose and phase context. However, it does not specify the exact return format (e.g., what version string or status field is returned), which could be a minor gap for agents expecting a structured response.

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

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

There are zero parameters, so the schema covers 100% of the parameter information. The description adds nothing about parameters because none exist. Baseline 4 is appropriate for a parameterless tool.

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

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

The description states a specific verb ('report') and resource ('groupon-mcp server') along with what is reported (running status and version). It also distinguishes itself from the deal-related sibling tools by noting that deal-read tools are a later phase, making the purpose unmistakable.

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

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

The description does not explicitly state when to use this tool versus the sibling deal tools. The phrase 'Deal-read tools arrive in a later phase' implies this is the only currently available tool, but since deal-read siblings exist in the tool list, this creates ambiguity rather than clear routing guidance. It lacks explicit exclusions or alternatives.

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

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

The readOnlyHint annotation already establishes safety, and the description adds meaningful behavioral detail: default returns a slim {title, url, children} tree, while view='full' returns Groupon's whole payload. This clarifies response shape and default behavior beyond the annotation.

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

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

Two sentences with no filler; the core action and resource are front-loaded, and the optional view behavior is stated efficiently.

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

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

For a simple read-only tool with one optional, fully documented parameter and no output schema, the description covers the default behavior and the full variant. Nothing essential for invocation 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?

The schema already documents the view parameter thoroughly with enum values and descriptions, so the baseline is 3. The description adds extra value by specifying the default choice and the concrete response shape, reinforcing rather than merely repeating the schema.

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

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

The description clearly states the specific action ('Fetch') and resource ('Groupon's category taxonomy tree'). It is readily distinguishable from sibling tools focused on deals, cart, and purchase operations.

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 about when to use this tool versus alternatives, nor any exclusion or prerequisite information. The agent must infer selection from the resource name and sibling context rather than from stated usage direction.

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

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

Annotations only mark readOnlyHint=false and openWorldHint=true; the description goes much further by disclosing that the tool re-reads the cart to verify quantity, returns a checkout URL rather than placing the order, and requires user confirmation before adding. It also exposes the token-based two-step fallback 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?

Around four sentences, each carrying distinct information: core action, post-add verification, payment limitation, and confirmation modes. Front-loaded with the main purpose; no filler. Slightly dense but all content is earned.

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 mutation tool with no output schema, the description covers the return value (checkout URL), the verification behavior, the payment limitation, and both confirmation paths. It even references MCP_CONFIRM_MODE for clients without elicitation, so an agent has sufficient context to call it correctly.

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

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

Schema coverage is 100% with detailed per-parameter descriptions, so the tool description doesn't need to re-elaborate. It adds value by explaining how confirmToken fits the overall two-step flow and how the returned checkout URL relates to the purchase, which helps the agent orchestrate the call sequence.

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: adds a Groupon deal option to the user's cart. Clearly distinguishes from siblings like groupon_get_deal (fetch) and groupon_view_cart (read-only) by describing the mutation flow and checkout handoff.

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?

Explains the intended use (add to cart, get checkout URL, user completes payment) and the confirmation requirement, including the two-step fallback with confirmToken. It does not explicitly enumerate alternative tools or when-not-to-use, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context by disclosing the default return shape ('slim deal summaries') and how to get 'Groupon's whole cards' via view='full'. No contradiction with annotations.

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

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

Three concise sentences, front-loaded with the core action and resource, then mode guidance, then response-shape behavior. Every sentence adds value and there is no redundancy.

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

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

For a read-only search tool with 100% schema coverage, the description covers the main behavioral choices: search vs browse, city scope, and response verbosity. It does not describe error conditions or pagination, but those are adequately covered by the schema and annotations.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema by explaining the semantic difference between passing `query` (free-text search) and omitting it (category/city browse), and by framing `division` as the city context.

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

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

The description uses a specific verb ('Search or browse') and a specific resource ('Groupon deals for a city (division)'). It also distinguishes the two operating modes (free-text query vs category/city browse), which clearly separates this from siblings like groupon_get_deal and groupon_list_categories.

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

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

The description gives explicit guidance on when to pass `query` versus omit it for a plain browse, and clarifies the default vs 'full' view behavior. It does not explicitly name alternative siblings or state when not to use this tool, but the usage context is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description bears less burden. It adds valuable behavioral context beyond annotations by specifying the authentication requirement (GROUPON_SESSION_COOKIE or fetchproxy browser bridge), which is critical for an agent to anticipate failures when no session exists.

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

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

The description is two sentences with no wasted words. The primary purpose is front-loaded, and the second sentence adds a necessary operational constraint. Every phrase contributes meaning, and the length is proportional to the tool's simplicity.

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, read-only tool, the description covers everything an agent needs: what it does, what it operates on, and the required session context. No output schema exists, but a cart-view operation's expected response (cart items) is reasonably inferable, and no other operational details are 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?

The tool has zero parameters, so there is nothing for the description to explain about arguments. The schema fully covers the empty parameter set, and the description appropriately focuses on behavior and prerequisites rather than inventing parameter details.

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

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

The description states a specific verb ('View') and resource ('items currently in your signed-in Groupon cart'), making the tool's function immediately clear. It also naturally distinguishes itself from siblings like groupon_purchase and groupon_clear_cart by focusing on viewing rather than modifying the cart.

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

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

The description gives clear context for when the tool applies—when a user wants to inspect their current cart—and states the prerequisite session requirement. It doesn't explicitly name alternatives or exclusion conditions, but the purpose is unambiguous given the sibling tool names.

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