Watches in Stock

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds some value by disclosing what content is returned (collections with counts, newest listings), but says nothing about ordering, limits, or behavior for an unknown brand name.

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

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

One sentence, front-loaded with the action and followed by the returned content. No filler, though the enumerated return contents could be tightened.

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 carry return-value information; it partially does by naming collections, counts, and newest listings. What is missing is the disambiguation from explore_brand and open_storefront, which is the main risk for correct tool selection in this crowded sibling set.

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

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

Schema description coverage is 100% and the single parameter already carries the note "The brand, as the store names it." The description adds no matching, casing, or partial-name semantics beyond that, so baseline 3 applies.

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

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

Names a specific verb and resource ("Shows a brand's page in the store") and enumerates what the page contains: collections with listing counts and newest listings. It does not differentiate itself from the closely named siblings explore_brand and open_storefront, so an agent cannot tell which of the three to pick from the description alone.

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 statement of when to use this versus explore_brand, open_storefront, or search_watches. Usage must be inferred from the phrase "brand's page" and the sibling names, which is exactly the overlap that needs clarifying.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds real behavioral context: availability is volatile ("a listing can sell at any time") and a human specialist is authoritative, which tells the agent how much to trust the result.

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 short sentences, no filler, with the core capability stated first and the usage cue and trust caveat following in priority order. Nothing could be removed without losing 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?

For a one-parameter read tool with full schema coverage and no output schema, the description covers what is checked, when to call it, and how reliable the answer is. Only the shape of the per-id result is left implicit, which is a minor gap for such a simple check.

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 already documents "Listing ids from search_watches" plus a 24-item cap. The description's phrase "a watch from earlier" reinforces the source of the ids but adds no syntax or batching detail beyond the schema, 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 — reporting whether listings are still on watchesinstock.com — which is distinct from lookup siblings like get_watch or price_check. It does not explicitly name a sibling, but the operation (a liveness check on previously seen listings) is unambiguous.

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 it when someone asks if a watch from earlier is still there" gives a clear triggering condition tied to previously returned listings. It stops short of naming an explicit alternative, though the closing line about a specialist implies get_specialist_link is the escalation path.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds that output is a side-by-side view including prices and details, but says nothing about failure modes such as invalid or non-existent ids, or whether fewer than two valid listings yields an error.

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 the capability stated first and the usage trigger second. No filler or 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 single-parameter, read-only tool with no output schema, the description covers what it does, its cardinality and when to reach for it. Only the relationship to sibling retrieval tools (e.g., get_watch) is 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?

Schema coverage is 100% and the schema already specifies the uuid format, minItems 2 and maxItems 4, and that ids come from search_watches. The phrase 'two to four listings' merely restates the cardinality constraints rather than adding new meaning.

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 resource ('Shows two to four listings side by side with their prices and details') and bounds the scope at two to four items. It does not distinguish itself from siblings like get_watch, which also retrieves listing details, so an agent must infer the difference.

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 a clear selection condition: 'Use it when someone wants to choose between specific listings.' That tells the agent the scenario, but no alternatives or exclusions are named, so there is no explicit routing advice versus get_watch or search_watches.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value with the hard brand scope ('Covers Patek Philippe, Rolex and Audemars Piguet') and a preview of returned fields including live listing counts and typical prices. It does not say what happens for an unsupported brand or how prices are derived, so with annotations already carrying the behavior it lands at 3.

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 tight sentences: what it returns, when to use it, and the coverage limit. Front-loaded with the resource and no redundant wording.

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 one-parameter, read-only lookup with no output schema, the description covers the return shape and the domain restriction, which is most of what an agent needs. The only gap is error/empty behavior for an out-of-scope brand.

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% for the single 'brand' parameter, so the baseline is 3. The description does add one useful semantic constraint the schema lacks — that valid values are effectively limited to the three named brands — but it doesn't state matching behavior for variants or abbreviations.

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 and resource ('Shows a brand's main models as a guide') and enumerates the payload: what each model is, who it suits, style, listing count and typical prices. That is enough to separate it from search_watches or get_watch, though it never names a sibling 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?

It states concrete triggers: the user knows the brand but not the model, is buying a gift, or asks for help choosing. That is clear when-to-use context, but there is no when-not guidance and no named alternative (e.g. use compare_watches once two models are shortlisted).

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 readOnly, non-destructive, open-world behavior, so safety is covered. The description adds real value beyond them by describing the response shape — listing counts, typical prices, dial variants, references — which is important since there is no output schema. It says nothing about price freshness or behavior on ambiguous model names.

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

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

One dense sentence that leads with what the tool returns and closes with the selection condition. No filler, no repetition of the title, and the most decision-relevant content 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?

For a one-parameter read-only lookup with no output schema, the description covers both the return contents and the usage trigger adequately. The only gap is what happens with an ambiguous or unmatched model name, which would matter in a catalog this large.

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?

Single `query` parameter with 100% schema description coverage, so the baseline is 3. The description's examples reinforce the schema's own example but add no new constraints such as accepted shorthand, fuzzy matching tolerance, or the 80-character limit's implications.

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 ("Shows one model") and enumerates exactly what comes back: current listing count with typical prices, available dials with prices, and references. The examples (Rolex Daytona, Patek Philippe Nautilus) and the emphasis on "one model" distinguish it from brand-level or single-watch 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 an explicit trigger: use when someone names a model and wants an overview before choosing a dial or reference. That also implies the hand-off point to dial/reference-level tools. It stops short of naming alternatives explicitly or stating when not to use it (e.g. an exact reference query).

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?

Goes well beyond the readOnly/openWorld/non-destructive annotations by stating what is returned (a link plus a draft note) and what is explicitly not done: 'nothing is sent, ordered, reserved or paid for.' It also discloses a non-obvious side effect — 'each call asks the store for its next specialist' — warning that repeated calls rotate specialists, which an agent could not infer from structured fields.

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?

Effectively front-loaded: the qualifying scenario comes first, the return value second, the safety disclaimer third, and the usage restriction last. The opening sentence is a long three-clause list, but each clause earns its place by covering a distinct customer case.

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?

Even without an output schema, the description explains exactly what the caller gets back (a WhatsApp link with draft note) and clarifies that no transaction occurs, which is the key risk for this tool. Combined with full schema coverage, an agent has everything needed to call it correctly and set expectations.

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 all three parameters (app, purpose, request) are already documented with examples and an enum. The description reinforces the find-vs-sell distinction through the selling scenario but adds no syntax or format guidance beyond the schema, 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 and resource ('Returns a WhatsApp link to a Watches in Stock specialist with a draft note') and scopes it to watches that are not listed, not listed as wanted, or being sold. That scenario framing separates it from search/inventory siblings, though it never names the closest sibling (get_specialist_link) 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?

Gives clear triggering conditions ('a watch that is not listed... or a watch the customer owns and is thinking of selling') plus an explicit restriction: 'Use it only when the customer asks for that help.' Lacks a named alternative for the adjacent case (e.g., when the watch IS listed, use search_watches), so it stops short of a full routing rule.

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 the readOnly/openWorld annotations, the description discloses two behaviors an agent could easily get wrong: nothing is sent, ordered, reserved or paid for, and each call asks the store for its next specialist (so repeated calls are not idempotent and may return a different person). That is exactly the kind of side-effect and rotation context annotations cannot express.

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?

Four sentences, each doing distinct work: what it returns, what it does not do, when to call it, and when to call something else. The safety constraint is front-loaded immediately after the purpose, before the routing rules.

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, yet the description still characterizes the return value (a WhatsApp link with a draft note) and clarifies nothing is transmitted. For a three-parameter, non-destructive lookup tool, an agent has everything needed to decide and call 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 description coverage is 100%, so id, app and also are already documented in the schema. The description only indirectly hints at those parameters by mentioning the 'draft note' that app and also feed into, adding little semantics beyond the structured fields. 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 a specific verb and resource: it looks up the Watches in Stock specialist assigned to a listing and returns a WhatsApp link plus a draft note. That is clearly separable from siblings like get_sourcing_link or open_storefront, and it explicitly routes informational questions to store_info.

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 stated positively (customer asks to talk to a specialist, or says they want to go ahead) and negatively (holds, offers, payment, shipping, returns go to store_info instead). The alternative sibling is named alongside the condition that selects it, leaving nothing to inference.

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, destructiveHint=false and openWorldHint=true, so the low-risk read profile is covered structurally. The description adds real value beyond that by disclosing the return payload (photo, parsed facts, dealer description), which matters since no output schema exists. It does not state behavior for an unknown or malformed id, which is the main remaining 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, no filler, and the useful part (what the call returns) is front-loaded ahead of the routing hint. 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?

For a one-parameter read tool with full schema coverage and no output schema, the description does the essential job of describing the return contents and the routing from search_watches. Only the error/empty-result behavior is left unstated, a minor omission at this 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?

The single schema parameter is fully documented (100% coverage) as a UUID 'listing id from search_watches'. The description merely echoes that provenance, adding no new meaning about format or reuse. Baseline 3 applies when the schema does the work.

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 ('Shows one listing in detail') and enumerates what comes back: photo, parsed facts, dealer description. It is clearly distinguishable from the sibling list tool search_watches. Slight friction from the name/title saying 'watch' while the description says 'listing', but an agent can still tell these apart.

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 it when someone asks about a specific watch from search_watches" gives a concrete trigger and implies the id originates from a prior search. It stops short of excluding near-neighbors like identify_watch or price_check, which an agent might also consider for a single-watch question.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuine behavioral value by disclosing the shape of the answer — reference coverage, visual description, year ranges — which substitutes for the missing output schema.

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: capability first, then a worked example. Nothing is padded, though the example is illustrative rather than load-bearing and could be trimmed without loss.

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 one-parameter read-only lookup with full annotation coverage, the description is nearly sufficient; it explains both what the tool does and what the caller gets back. The only real omission is behavior for unrecognized or ambiguous nicknames, which matters for an open-world lookup.

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

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

Schema description coverage is 100% and the single parameter is fully documented as "A nickname or reference." The description's phrase "watch nickname or reference" mirrors that wording rather than adding new meaning, 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?

"Explains a watch nickname or reference" pairs a specific verb with a specific resource and states the payload: covered references, appearance, and production years. It is clearly distinct from data-fetching siblings like get_watch or search_watches, though it never names those 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?

The Bruce Wayne example gives a concrete when-to-use signal (natural-language nickname questions), which is better than nothing. However, with ten siblings including get_watch, search_watches, and compare_watches, the description offers no exclusions or routing rule for when a reference-style lookup should go elsewhere.

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, openWorldHint and destructiveHint=false, so the description does not need to argue safety. It instead contributes genuinely new behavioral context: the data is dealer asking prices over the last 14 days, explicitly not sold prices, which changes how an agent should frame any valuation answer. 'Price history when there is enough' also signals conditional, possibly partial output, though it does not say what is returned when data is thin.

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

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

Three sentences, front-loaded with the capability list, then the use case, then the critical data caveat. The middle sentence is dense but every clause names real output content. Minor cost: the enumeration reads as a comma-spliced list and the 'price checker' item invites confusion rather than 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 must convey what comes back, and it does so concretely, plus the asking-price/14-day caveat that an agent needs to avoid overstating a valuation. It is not fully complete: it does not say what happens when no watch is identified or how the optional identifiers combine, which matters for a tool with zero required 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 description coverage is 100% and each of the three parameters (brand, query, reference) is documented with examples, including that query accepts nicknames, references, years and budgets. The description adds nothing about parameters and does not clarify precedence between query and reference when both are supplied. Baseline 3 applies since the schema carries the load.

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 and resource ('Shows analytics for a watch') and enumerates the actual contents: asking-price distribution, prices by year and inclusions, daily new listings, price history, price checker, model background. That is far more informative than the title alone. It stops short of 5 because it never distinguishes itself from siblings with overlapping intent (price_check, compare_watches), and listing 'a price checker' as contained content actively blurs the boundary with the price_check tool.

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 it for questions about value, trends or whether a price is fair' gives a clear use context that an agent can match against a user's question. There are no exclusions and no named alternatives, so an agent facing 'is this price fair?' still has to guess whether price_check or compare_watches is the better call.

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, destructiveHint=false and openWorldHint=true, so safety and open-world reach are covered structurally. The description adds only the content inventory of the returned storefront, with no notes on follow-up behavior or result shape. Nothing is contradicted, but value beyond the annotations is modest.

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

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

Two compact sentences: the first establishes what is shown and its contents, the second establishes when to call it. Zero filler, and the identification of the tool 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 parameters, no output schema and full annotation coverage, the description carries essentially the whole burden and mostly meets it by describing the returned content and triggering conditions. A brief pointer to which sibling to use once a specific watch is named would make it fully self-contained.

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 no parameter meaning to convey; the baseline of 4 applies. The description correctly does not invent or imply any inputs.

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 clear verb-plus-resource framing ('Shows the Watches in Stock storefront') and enumerates its contents: new arrivals, own stock, leading brands, example questions. It is clearly a landing/browse entry point, distinct from narrower siblings like get_watch or price_check, though it does not explicitly name a sibling it differs from (e.g. store_info or search_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 gives concrete triggering conditions: browsing, asking what is new or available, or not having named a watch yet. That last clause implicitly routes to a named-watch tool such as search_watches or get_watch. It lacks explicit exclusions (e.g. 'do not use for price lookup'), so it falls short of the highest band.

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, openWorldHint and destructiveHint, so the safety profile is covered. The description adds the meaningful detail that the figures are *asking* prices drawn from current listings, not sold/transaction prices, which is a real behavioral distinction. It says nothing about empty-result behavior, sample-size caveats, or whether filters are conjunctive.

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 what the tool returns and followed by a worked example. Nothing is padded and every clause carries information an agent needs.

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 14-parameter tool with no output schema, the description does state the shape of the result (low/median/high), which covers the biggest gap. However it never explains how the many filters combine, what happens when filters are too narrow, or the fact that all parameters are optional and an unscoped call is valid. Adequate but thin relative to the surface area.

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 86%, so the baseline would be 3. The description adds meaning the schema does not: the '2021 Batgirl' example demonstrates that the free-text query parameter absorbs nicknames, model names, references and years, telling the agent it need not decompose those into reference/year_min/year_max. That is precisely the kind of guidance the 14-parameter schema cannot supply on its own.

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 ('gives the low, median and high asking price from current listings for a watch') and even defines the returned metric. It implicitly separates itself from search_watches and market_report by emphasizing asking-price aggregation, but never names the siblings it is not.

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 example question ('what does a 2021 Batgirl go for?') gives one concrete cue for when to reach for this tool, which is genuinely useful. But there is no when-not guidance and no routing to the obvious alternatives in the sibling set, such as market_report for trends, search_watches for browsing listings, or check_availability.

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 a non-readonly, non-destructive, non-idempotent write, and the description adds real value beyond that: contact happens through a human specialist, at the customer's preferred time, and details are held privately for 90 days and never shown to dealers. It does not say what confirmation the caller receives or whether duplicate submissions create duplicate leads.

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 sentences, front-loaded with the action, then the usage condition, then the privacy note. The channel list partially repeats enum values already in the schema, but nothing is bloated.

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 nine-parameter submission tool this is close, but the schema requires only name and preferred while leaving phone and email optional — the description's "has given these details" hints at a requirement without resolving whether one contact method is mandatory. There is no output schema, and success behavior (confirmation, reference, next steps) is left implicit.

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 schema already documents all nine fields. The description adds only a little meaning, mainly that phone or email is the channel-dependent contact detail and that timing preference is honored, without clarifying whether at least one contact method is mandatory.

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+resource: passing the customer's name and contact details to Watches in Stock so a specialist follows up about a watch. It also names the channels and timing, which distinguishes it from link-only siblings like get_specialist_link, though no sibling is named 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?

"Use it when the customer asks to be contacted and has given these details for that purpose" gives a clear trigger plus a consent/prerequisite condition. It stops short of naming alternatives (get_specialist_link, get_sourcing_link) or stating when not to use it.

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 establish readOnly/non-destructive/open-world, and the description adds genuinely non-obvious behavior: results are photo cards, data is live dealer inventory with real prices limited to the last 14 days, trade nicknames are understood, and a request for a non-existent production year returns the closest real watch with an explanation rather than an empty result. That last point meaningfully changes how an agent should interpret an imperfect match.

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 sentences, front-loaded with what the tool returns followed by when to prefer it and what it knows. Dense but every clause carries information; the middle sentence is long and stacks several claims, which is the only cost to readability.

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

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

For a 19-parameter, zero-required search tool with no output schema, the description covers purpose, data freshness, ranking intent and free-text interpretation well. It leaves the 'Listings per group' concept in `limit` unexpanded and does not explain how the photo-card results are grouped or paginated, which is a minor gap at this 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?

Schema coverage is 89%, so the baseline is 3, and the description earns above it by explaining that `query` accepts nicknames, model names, references, multiple years and spoken budgets in the customer's own words. It does not elaborate on `exact_filters`, `our_stock_only` or `sort`, but the schema already documents those with good behavioral notes.

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 ('Searches current watch listings') and adds the output shape ('shows them as photo cards'), so the agent knows exactly what comes back. It differentiates itself from web search but not from overlapping siblings such as compare_watches, price_check or suggest_watches, which the description implicitly claims territory over ('comparing or pricing').

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 default rule: use this first for any finding, choosing, comparing or pricing question, including vague ones like 'which watch should I get for 10k?', and only then fall back to the web. The rationale for doing so (live dealer listings, real prices, last 14 days) makes the guidance actionable, though no MCP sibling is named as the alternative.

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, destructiveHint false, openWorldHint true), and the description adds the important behavioral boundary that the tool produces no offer and no valuation. It does not say whether the comparison listings are live/refreshed or how stale they might be, which would round out the picture.

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 short sentences, front-loaded with the audience and the payload, and closed with the negative boundary and the redirect. No filler or repetition of the 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 6 optional parameters, no output schema, and full schema coverage, the description covers intent, content, and the handoff to a specialist. It could say more about what the returned comparison looks like (count of comparables, price ranges), but nothing essential for correct 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?

Schema description coverage is 100% and the descriptions are rich (query handles nicknames, references, years, budgets; dial notes that unnamed dials are excluded). The tool description mentions no parameters at all, so it adds nothing beyond the schema — baseline 3.

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 audience (someone thinking of selling a watch), the specific output (what similar watches are listed at today, plus published guidance on quick sale to a dealer and consignment), and explicitly distinguishes itself from get_sourcing_link. An agent can tell what this returns 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?

It gives a clear trigger (a seller considering a sale) and an explicit exclusion plus redirect: it makes no offer and works out no estimate, because a specialist does that via get_sourcing_link with purpose sell. That is a precise when-to-use/when-to-use-something-else boundary.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered and the description need not restate it. What it adds is provenance (content authored by the store, not the platform) and a handling instruction to quote verbatim rather than generalize. It says nothing about what the response actually looks like (raw policy text vs. structured fields) or what happens when a requested topic is thin, which matters since there is no output schema.

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 purpose and the usage guidance are front-loaded and there is no filler sentence. But the first sentence is a single run-on that re-lists roughly fifteen topics largely mirroring the enum, which reads as bulk even though some of it doubles as parameter gloss. It could be split and trimmed without losing routing value.

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 one required enum parameter at full schema coverage and no output schema, the description supplies enough for an agent to call it correctly and to know the content is first-party store text. The only shortfall is the absence of any hint about response shape or coverage limits per topic.

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 enum is self-explanatory in most cases, so the baseline is 3. The description earns above baseline by glossing several non-obvious enum values in plain language: 'where listings come from' for data_source, 'how customer details are used' for your_information, 'how prices are set and the commission in them' for pricing. It leaves what_makes_it_different, price_differences, country_pricing and dealer_privacy unmapped.

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 clearly: what the store has published about itself and its buying terms, then enumerates the domains (deposit, authenticity, pricing, shipping, returns, payment). It distinguishes itself from the watch-level siblings by saying it is for 'questions about the business rather than a particular watch'. It does not, however, differentiate itself from selling_guide, which overlaps with the 'selling' and 'consignment' topics it claims.

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 explicit when-to-use conditions with concrete examples: legitimacy, who the customer would pay, whether a watch can be held and how to pay. It also says to quote the store's own words rather than general trade practice, which shapes how to use the output. The one gap is that it never names an alternative for pricing/selling questions that could go to price_check or selling_guide.

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, destructiveHint=false, openWorldHint=true), so the description only needs to add behavior. It adds genuinely useful value by naming the returned content (nicknames, references, models, photos), which substitutes for the missing output schema, but says nothing about partial-query matching semantics or result 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?

One compact sentence with the returned content front-loaded and no filler. Nothing could be removed without losing 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?

For a single-parameter read-only suggestion tool with full schema coverage and annotations, this is close to sufficient, and the return-content mention compensates for the absent output schema. It falls short on how the tool relates to search_watches and on any guidance about call frequency or empty/partial results.

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

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

With a single parameter at 100% schema description coverage, the schema already explains 'text' as what the customer has typed so far. The description's 'while typing' reinforces partial-input intent but adds no format, length, or matching-mode detail beyond the schema, 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 uses a specific verb ('suggests') and enumerates what is suggested: nicknames, references, models, with photos, plus the target surface ('the store search box'). That is far more informative than the name alone, though it never explicitly distinguishes itself from the sibling search_watches, which an agent might reasonably pick instead.

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 phrase 'for the store search box' hints at a typeahead context, but there is no explicit statement of when to call this versus search_watches, get_watch, or identify_watch, and no note that this is a partial-input/keystroke-driven tool. The agent must infer the routing decision entirely.

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