ZonRival

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

Annotations only declare readOnlyHint and openWorldHint; the description adds real context beyond that — the data source (Keepa), the marketplace availability restriction, and the rank interpretation ('lower is better; a falling rank means rising sales'). It does not discuss latency, credits, or result size, so not 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?

Front-loaded with the core purpose, then a dense but useful metric enumeration, then usage and a constraint. The long parenthetical metric list is information-rich rather than padded, though it is somewhat crowded into one sentence.

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 carries the return-value burden and does so by enumerating price stats, rank, ratings, review counts, launch date, units bought, and a weekly trend. The only gap is that it does not note the marketplace restriction's interaction with the schema enum (au/ae remain valid inputs), which an agent might trip 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 coverage is 100% so the baseline is 3, but the description adds interpretive meaning the schema lacks — the rank direction convention and the default window (90 days). It does not explain the marketplace codes beyond the schema's own list.

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 resource (Amazon product history over N days) with the exact metrics returned, which clearly separates it from siblings like amazon_product or amazon_listing_audit. An agent can identify it 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?

Gives concrete use cases ('tell whether a competitor is growing, how they price around events, how fast they gain reviews') and a hard exclusion ('Not available for au and ae'). It does not name a competing sibling tool for adjacent needs, 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?

Annotations already declare readOnlyHint and openWorldHint, and the description adds substantial value beyond them: the credit cost model with a worked example, the ranking basis, and a caveat about how results must not be interpreted. This is exactly the kind of extra behavioral context that annotations cannot carry.

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 first defines the operation and its output, the second front-loads the scope limitation and then the cost. Every clause 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?

With no output schema, the description compensates by describing the return content and its ordering, and it adds the cost and interpretive caveats an agent needs before invoking. Nothing material is missing for a read-only, 3-parameter comparison 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 67%, with patterns, defaults, and the marketplace code list already documented in the schema. The description adds no parameter-level detail (e.g. ASIN format, marketplace codes, competitor cap) beyond what the schema provides, so the baseline 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?

States a precise verb+resource ('compare the TEXT of your Amazon listing with up to 5 competitors') and the exact output ('words/phrases that appear in their titles and bullets but not in yours, ranked by how many competitors use them'). It also explicitly distinguishes itself from search-ranking/search-volume tools, so an agent can separate it from siblings like amazon_search or amazon_listing_audit.

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?

Gives clear context for when this applies (listing-copy comparison, up to 5 competitors) and an explicit exclusion ('it is not search-ranking or search-volume data'), plus a cost rule (1 credit per listing compared). It does not name a specific sibling to use instead when the user actually wants ranking data, which keeps it 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real context the annotations do not: the 0–100 scoring scale, the seven evaluation dimensions, and that the result includes specific fixes. Gaps remain around cost (credit-consuming siblings exist in this server) and latency, but the operation's nature is well 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 with the scoring action front-loaded and the evaluation criteria parenthesized; every clause carries information and nothing is repeated from the schema or annotations.

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 carries return-value burden and does so by naming the score and the fixes it produces. What it does not cover — cost/pricing, whether the marketplace affects scoring, or the shape of the 'fixes' output — is minor for a read-only audit 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?

With 100% schema description coverage, both parameters (asin with a regex pattern and example, marketplace with its code list and default) are fully explained by the schema. The description mentions no parameter-level detail, 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?

States a specific verb (score) plus resource (Amazon listing) and the output form (0–100 against best practice), so an agent immediately knows this is a quality-assessment tool rather than a raw data fetch. The dimension list (title, bullets, images, video, A+, rating, review volume) makes it clearly distinct from amazon_product, amazon_search, and amazon_review_complaints.

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 purpose implies when it is useful — evaluating/improving an existing listing — but the description never states prerequisites (listing must exist, marketplace must be chosen) or names alternatives such as amazon_product for fetching raw attributes. Usage is inferable but not 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the returned field set, which is useful given there is no output schema, but it discloses nothing further about authentication, rate limits, or marketplace 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 front-loaded sentence with zero waste: verb and resource first, then the payload enumeration. It is appropriately sized for a two-parameter read tool.

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 low-complexity read tool with full schema coverage and annotations, the description is nearly complete: it enumerates outputs to compensate for the absent output schema. It leaves out usage routing among siblings and any input guidance, which are minor gaps here.

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 both parameters (asin, marketplace) are already fully documented in the schema. The description adds no input semantics beyond that, 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?

The description states a clear verb and resource ('Get an Amazon listing') and enumerates the exact payload fields returned, making the product-detail intent legible. It does not explicitly differentiate itself from siblings like amazon_search or amazon_listing_audit, so it stops just 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?

There is no guidance on when to choose this tool over amazon_search, amazon_listing_audit, or amazon_review_complaints. Usage is only implied by the tool name and returned-field list; no prerequisites or exclusions 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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine behavioral context absent from the structured fields: complaints are ordered first, the summary reflects ALL reviews while theme extraction is limited to featured reviews on the page, and it details the returned breakdowns. It omits auth/rate-limit or failure behavior, keeping it from 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?

Front-loads the core deliverable and keeps the reader oriented with the 'complaints come first' note up front. It is dense and packed with clauses, but nearly every sentence conveys actionable output/usage information rather than 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?

With no output schema present, the description carries the burden of explaining returns, and it does so thoroughly (topics, sentiment labels, mention counts, positive/negative totals, star breakdown, quotes). An agent has enough to know what it will get back.

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 both parameters (asin, marketplace) are fully documented in the schema. The description adds no format, validation, or marketplace-specific meaning beyond that, 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 verb (mine/find) and resource (complaints on an Amazon product), and immediately names the concrete payload: Amazon's 'Customers say' topic summary with counts and quotes. This is clearly distinguishable from siblings like amazon_product or amazon_listing_audit.

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 intent guidance ('Use on competitors to find product improvements and listing angles') and an internal usage rule ('Lead with the negative and mixed topics'). It does not name an alternative tool or state when NOT to use it, 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?

Annotations only cover readOnlyHint and openWorldHint, yet the description discloses the exact result shape (ASIN, title, price, rating, review count), separates organic from sponsored/brand/video ads, and warns that the ad list is inherently incomplete due to Amazon's bot filtering, advising 'seen advertising' framing. That is real operational context an agent could not derive from 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?

Two sentences, front-loaded with purpose then output/limitation, with no filler. The second sentence is dense with three clauses, which slightly reduces scannability but 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?

With no output schema, the description fully carries the burden of describing return values and explicitly flags the reliability limitation of the ad portion. For a two-parameter read tool with only one documented parameter, nothing an agent needs to invoke 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 description coverage is 50% — marketplace is documented inline while keyword is not — and the description adds no format, length, or marketplace-behavior detail beyond the schema. It does not compensate for the undocumented keyword parameter, 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?

The description names a specific verb and resource ('See who ranks for a keyword on Amazon') and enumerates exactly what is returned: organic results in rank order plus ad placements. An agent can distinguish this from amazon_product (single product lookup) or amazon_keyword_gap (gap analysis) 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?

Usage is implied by 'See who ranks for a keyword', which signals a rank-tracking scenario, but there is no explicit when-to-use/when-not-to-use guidance and no sibling tool is named as an alternative. The ad-caveat is a presentation instruction rather than selection guidance, leaving the agent to infer when this beats amazon_keyword_gap.

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 cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description adds real behavioral context beyond them: the call aggregates several analyses at once and 'Shows as a visual report in apps that support it,' which tells an agent the output may be rendered rather than returned as plain data. It stops short of disclosing cost/credit consumption or latency, which would matter for a multi-analysis aggregate.

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, no filler, and the contents of the teardown are front-loaded before the routing guidance. Every clause carries information the agent needs (what it returns, how it renders, when to choose it).

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 return content — and it enumerates the delivered analyses precisely, plus notes the visual-report rendering. Combined with 100% parameter coverage and read-only annotations, an agent has everything needed 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 only three parameters, each already documented including the marketplace enum list and the keyword default. The description only echoes the keyword ranking concept already stated in the schema, adding no new syntax, format, or constraint detail. Baseline 3 applies 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?

Specific verb+resource ('Full teardown of one Amazon product in a single call') followed by an explicit enumeration of the composite outputs: complaint themes, 90-day rank/price/review history, 0–100 listing audit, keyword ranking, advertisers, and takeaways. This clearly separates it from the granular siblings like amazon_review_complaints or amazon_listing_audit.

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?

Explicitly states when to prefer it: 'Prefer this over calling the individual tools when the user wants an overview of a competitor.' It names the alternative class (the individual tools) and the condition (overview intent) that selects this one, so no inference is required.

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 safety is covered. The description adds the useful behavioral fact that the call is free (no credit consumed), but says nothing further about rate limits, auth, or result freshness.

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, front-loaded sentences with no filler; the scope and the zero-cost trait are the first and last things read.

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 parameterless read tool with no output schema, the description tells the agent what comes back (remaining balance plus per-tool pricing). Only a note about response shape or refresh timing 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 tool takes zero parameters, so the baseline is 4. The description has no parameter semantics to add and correctly does not invent any.

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 ('Show remaining ZonRival credits') plus a second output ('what each tool costs'). It is unmistakably distinct from every sibling (amazon_*, shopify_*, watch_*), none of which concern credits.

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 'Free' note implies this can be called at no cost, and listing per-tool costs implies it is the reference point before invoking paid siblings, but neither when-to-use nor when-not is stated explicitly. Usage must be 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external-reach profile is covered. The description adds that the catalog is 'public' (implying no auth against the target store), but says nothing about rate limits, crawling behavior, or failure modes when a store isn't Shopify.

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 action and the returned fields, then the use case. Every clause carries information; nothing is padded or restated from the title.

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 returned fields so an agent knows what it will get back, and it flags the intent. Minor gaps remain around volume/limits and behavior on non-Shopify domains, but the core 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 coverage is 100% and both parameters are self-documenting, including the store_url example and the 'can be large' warning on include_products. The description adds no parameter-level detail beyond what the schema already provides, 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 ('Pull') and resource ('competitor Shopify store's public catalog') and then enumerates exactly what is returned: product count, price range and median, sale items, sold-out items, top types/tags, newest launches. It is unmistakably distinct from the Amazon-oriented siblings.

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?

Gives a clear use case — 'reverse-engineer a DTC competitor's assortment and pricing' — which frames the intent well. It stops short of naming when-not to use it or pointing at an alternative tool for a different job.

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 annotations only covering the generic mutation profile (readOnlyHint=false, openWorldHint=true, non-idempotent, non-destructive), the description carries the rest and does so richly: daily re-checks, emailed digests, the exact change triggers for Amazon and Shopify, a 2-credit recurring charge billed now and every 7 days, a 25-watch cap, and that it only affects the caller's own list. The recurring billing detail in particular is behavior an agent cannot infer from the schema or 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 long but front-loaded with the two invocation modes, then organized into Amazon triggers, Shopify triggers, and cost/limits. Nearly every clause carries distinct information, though the trigger lists could be tightened slightly.

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 no-output-schema mutation tool with zero required parameters, the description supplies everything needed: what each parameter selects, what will be monitored, how often the user is notified, the recurring cost, and the watch cap. Nothing material is left for the agent to guess.

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, but the description adds real semantic value by framing asin and store_url as mutually exclusive alternatives — important given the schema marks zero parameters as required. It does not discuss the marketplace parameter, though the schema documents it fully.

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 precise verb+resource ('Start watching an Amazon product ... or a Shopify store') and immediately distinguishes the two modes by their required argument (asin vs store_url). It is also clearly separable from the sibling tools watch_list and watch_remove, which manage rather than create watches.

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 states the condition that selects each mode ('pass asin' vs 'pass store_url') and surfaces real constraints: max 25 watches and 2 credits per item per week. It never names watch_list or watch_remove as the alternatives for viewing/removing, so routing guidance is good but not fully 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?

Annotations already declare readOnlyHint=true, so safety is covered, but the description adds genuinely new context: it is free (no credit spend), and it discloses the returned fields per entity type plus that 'recent changes detected' are included. It stops short of saying what window 'recent' covers or whether results are paginated.

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 action and resource before the parenthetical detail about returned fields. It is slightly dense but every clause (data fields, changes, cost) carries information an agent would otherwise have to guess.

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 correctly compensates by enumerating return contents per entity type, and it flags the free cost. For a zero-parameter read tool this is nearly complete; only the definition of 'recent changes' and any result limits are left 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?

The tool takes zero parameters, so the baseline is 4. There is nothing in the schema for the description to clarify, and it does not need to.

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 ('Show') and resource (the user's watched Amazon products and Shopify stores) and enumerates exactly what each entity returns, so an agent knows precisely what comes back. It does not explicitly name watch_add/watch_remove or amazon_product as alternatives, so differentiation is implied by the word 'watching' rather than stated.

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 this is the read counterpart to watch_add/watch_remove. There is no explicit when-to-use or when-not-to-use guidance, and no comparison against amazon_product for users who want product data outside a watch list. The trailing 'Free.' is a useful cost signal but not 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 already declare destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context beyond them: removal from this user's watch list, cessation of further weekly charges, and that the call is free. It does not say whether removal is reversible, which is the one remaining behavioral gap.

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, zero waste, with the routing rule and the key consequence (no further charges) front-loaded. Nothing is restated from the title or 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?

With no output schema and full annotation coverage, the description supplies what is missing: what gets removed, the billing effect, and the cost. The marketplace parameter is never mentioned, a minor omission for a 3-param 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 coverage is 100% so the baseline is 3, but the description adds meaning the schema does not: asin and store_url are alternatives keyed to resource type, and the schema enforces no oneOf/required constraint even though the operation needs one of them. This compensates for the missing mutual-exclusivity rule.

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 ('Stop watching') and two concrete resources (Amazon product, Shopify store), and the parenthetical maps each resource to the parameter that selects it. Against siblings watch_add/watch_list the inverse relationship is immediately obvious.

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?

Gives clear conditional routing: 'pass asin' for Amazon, 'pass store_url' for Shopify, which is exactly the decision an agent must make. It does not explicitly name watch_list/watch_add as alternatives or state prerequisites (e.g. the item must currently be watched), so it stops 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.