deals

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

The description adds significant behavioral context beyond annotations: it states the feed URL dies immediately, webhook deactivates, idempotency, and that sourcing for promoted products continues. No contradiction with annotations (destructiveHint=true, idempotentHint=true).

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 concise (two sentences) and front-loaded with the core action. Every sentence provides essential information without 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?

Given low complexity (single parameter, no output schema), the description covers all relevant behavioral details: what happens on cancellation, idempotency, and shared state. No gaps are apparent.

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% with good parameter description ('The watch_id returned by register_watch.'). The tool description does not add further parameter semantics, so baseline score of 3 applies.

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

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

The description clearly states 'Stop deliveries for a watch' and specifies the exact consequences (feed URL dies, webhook deactivates). It distinguishes itself from sibling tools like 'register_watch' and 'check_watch' by focusing on cancellation.

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 (when you want to stop deliveries) but does not explicitly state when not to use or mention alternatives. It is clear enough for an AI agent to infer proper usage.

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?

Beyond annotations (readOnlyHint=true), the description discloses included status fields, timing (interpretation 1-2 min, channels auto-activate), and server-verified human_summary. No contradictions.

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 core purpose, no filler. Every clause adds value (status fields, timing, channel activation).

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 tool with one param and no output schema, the description sufficiently covers what to expect (progress, binding, channel states, deals with summaries). Timing hint aids agent decision-making.

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 param description 'The watch_id returned by register_watch.' The tool description merely restates 'by watch_id', adding no additional meaning beyond what the schema provides.

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 it retrieves the status of a watch by watch_id, listing specific fields (interpretation progress, bound product/category, channel states, live deals). This distinguishes it from siblings like register_watch (creation), cancel_watch (deletion), and get_deal (single deal retrieval).

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 use after registration via timing (1-2 minutes for interpretation) but does not explicitly contrast with siblings (e.g., when to use get_deal vs check_watch). No when-not-to-use or alternative recommendations.

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 indicate read-only. Description adds details on output fields, server-verified human_summary, closed vocabulary provenance, and canonical product identity matching. However, mentions a parameter (intent_match_only) not present in schema, which could cause confusion.

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?

Front-loaded with 'Fetch one deal by id.' Each sentence adds value. Could be slightly more concise by removing the reference to the missing intent_match_only parameter.

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?

Without an output schema, the description compensates by detailing the compact vs full record contents. Includes specificity like server-verified, closed vocabulary, and canonical identity. Missing parameter mention is a minor gap.

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

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

Schema coverage is 100% with descriptions, but the description adds meaning: explains what full=true returns and where deal_id comes from. The extra mention of intent_match_only (not in schema) detracts slightly.

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 tool fetches one deal by id and explains the two projections (compact vs full). It distinguishes itself from sibling tools like search_deals, latest_deals, and watch tools.

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?

Provides guidance on when to use full=true vs default, and mentions intent_match_only (though not in schema). Implicitly relates deal_id to search_deals or latest_deals from sibling context.

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?

Discloses behavior beyond annotations: returns up to 5 compact deals (max 10) with server-verified human_summary sentences, and notes what is excluded. 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?

Concise with two clear sentences followed by a longer but informative third sentence. Efficiently packs purpose, alternatives, and key constraints.

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?

Adequately covers purpose, usage context, and behavioral details for a simple read-only tool with no output schema and only optional parameters.

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 description adds little beyond schema. Mentions the limit range and category filter, but these are already described in 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?

Clearly states the tool returns newest approved deals in reverse chronological order, and explicitly distinguishes from siblings like search_deals and register_watch.

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?

Provides explicit guidance on when to use this tool vs alternatives: excludes availability-only price-target matches (use search_deals for those), and suggests register_watch for push delivery or the SSE river for ongoing monitoring.

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 provide no behavioral hints, so the description carries the full burden. It details side effects (token-gated feed, webhook activation delay, email double-opt-in), timing (auto-promotion vs. review), validation (unknown keys rejected, must-have semantics), and non-idempotent nature. This is comprehensive and beyond 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 a single, dense paragraph of 7 sentences. It front-loads the purpose and delivers key behavioral details without waste. Every sentence adds value, and the length is appropriate for the tool's complexity.

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?

Despite no output schema, the description mentions all critical outputs (token returned once, watch_id). It covers side effects, timing, validation, and relationships with other tools (check_watch). For the tool's complexity (8 parameters, nested objects), it is 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?

Schema descriptions cover 100% of parameters with detailed explanations. The tool description adds context about how parameters interact (e.g., specs override extraction) but does not significantly enhance per-parameter meaning beyond the schema, so the baseline of 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 clearly states the tool registers a 'standing intent (deal watch)' and explains the core action. It distinguishes itself from sibling tools like cancel_watch and check_watch by focusing on creation and setup of delivery channels.

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 its use for new watch registrations but does not explicitly state when to avoid using it or suggest alternatives. Sibling tool names provide context, but the description itself lacks explicit when-to-use and when-not-to-use 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?

The description discloses side effects beyond annotations: feedback feeds deal ranking and certain outcomes trigger fast removal of bad deals. Annotations (readOnlyHint=false, destructiveHint=false) are consistent with the description, no contradiction.

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: first defines action and lists options, second explains impact. Concise, front-loaded, no superfluous text.

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?

Covers purpose, outcomes, and impact. No output schema, but description is adequate. Missing explicit mention of idempotency (annotations idempotentHint=false), but not critical for understanding.

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 baseline is 3. The description lists outcomes redundantly with the enum and contextualizes the purpose, but does not add new meaning to individual parameters beyond the schema.

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

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

The description uses the verb 'Record' and specifies the resource 'what happened after a deal was acted on,' listing six distinct outcomes, distinguishing it from sibling tools like get_deal or search_deals.

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 indicates when to use the tool (after acting on a deal) and explains consequences (feeds ranking, triggers removal), but does not explicitly state when not to use it or compare to 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?

Annotations already declare readOnlyHint=true, so the tool is read-only. The description adds behavioral details: token-AND matching, maximum 5 results sorted by best score, specific return fields (price, discount, condition, merchant, product URL, human_summary), and zero-match handling with no_match block. This is rich context beyond annotations, though it omits scoring algorithm and pagination.

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 concise with three sentences, each adding value. It front-loads the main action and then provides details on matching and zero-match behavior. Could be slightly more streamlined, but efficient for its content.

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?

The description provides a complete picture: what it does, how matching works, what it returns (with specific fields), and how to handle zero results (register_watch alternative). It does not cover error handling or rate limits, but for a read-only search tool with no output schema, it adequately informs an AI agent.

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 each parameter with descriptions. The description adds context about token-AND matching and overall search behavior, but does not add meaning beyond what the schema provides for individual parameters. Baseline score of 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 uses specific verb 'search' with resource 'live deals', details token-AND matching over product name, brand, category, and merchant, and explains return fields and zero-match behavior, clearly distinguishing from sibling tools like get_deal and latest_deals.

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 explains usage context (keyword search), including normal zero-match behavior and the register_watch alternative for no results. It lacks explicit when-not-to-use or comparison with siblings like latest_deals, but provides sufficient guidance for an AI agent.

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