Sienna, Knobs.co hardware advisor

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that: it discloses the shape of the answer (exact products with title, vendor, finish, size, list price, URL), the one-question-per-call constraint, and the 600-character input cap. It does not describe failure modes or latency, but that is minor given the annotation coverage.

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 is front-loaded in the first sentence, followed by a compact best-for list and a single actionable instruction about what context to include. Every sentence carries information; the enumeration is dense but scannable rather than redundant.

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

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

There is no output schema, and the description compensates by specifying the fields returned in the answer and the input constraints (one question, 600 characters). Combined with the annotations, an agent has enough to invoke it correctly; only explicit sibling routing is missing.

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

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

Schema coverage is 100% and there is a single required string, so the baseline is 3. The description goes further by telling the caller what content to pack into that string: room, drawer widths, existing hole spacing, finish, style, budget per piece, brand likes or dislikes, plus the 600-character limit, which meaningfully improves answer quality beyond the schema's terse 'question, with what is known'.

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: ask the automated cabinet-hardware advisor one plain-language question and receive one answer with named products (title, vendor, finish, size, list price, URL). It is clearly distinct from siblings like search_catalog, get_product, and sizing_guide because it produces a curated advisory answer rather than records or raw data.

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 'Best for' list gives concrete question categories (pull length for drawer width, hole center-to-center fit, knobs vs pulls, finish pairing, samples, returns, trade program), which is strong when-to-use guidance. It does not explicitly say when not to use it or route to a specific sibling alternative (e.g., sizing_guide or search_catalog), 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.

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

Goes well beyond the annotations by disclosing persistence ("saved for 90 days at the returned plan_url"), downstream effects (shopper can add samples or the whole plan to their cart), no auth requirement ("No email or account needed"), and a real cost constraint ("Costs real money on our side, so call it once per shopper"). The once-per-shopper warning also reinforces the non-idempotent behavior the annotations flag.

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 plan's contents, then usage conditions, then the cost caveat. Dense and mostly waste-free, though the cart/sample sentence and the 90-day detail could be slightly tightened 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 nested-object, non-idempotent build tool with no output schema, the description covers what is produced (plan_url, line items, totals, unconfirmed items), how long it lives, and what the agent must gather first. Nothing essential for a correct single 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%, so parameter documentation is already strong and the baseline is 3. The description adds genuine meaning by stating the minimum viable answer set (counts, drilling, finish) and by explaining where candidates come from (search_catalog handles plus variant_id in the right finish), which the schema alone does not convey.

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 ("Build the shopper's whole-kitchen (or bath) Hardware Plan") and enumerates exactly what the output contains: one line per zone, product, finish, size, count, list price, totals, samples, unconfirmed items. This is clearly distinguishable from siblings like search_catalog or sizing_guide.

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 names the preconditions (counts, drilling, finish, style, budget) and how to feed in search results ("include products they liked from search_catalog as candidates"). It also routes alternatives: re-call build_plan to correct answers, and use request_consultation with the plan_url for Kayla's review.

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/idempotent/non-destructive, and the description earns credit beyond them by spelling out the downstream consequence: nothing is ordered by this call, the shopper reviews, adds shipping and pays on knobs.co. It also says what comes back (line items with list prices and subtotal), 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?

Two dense sentences with no filler; the core action and the 'nothing is ordered' caveat are front-loaded, and the return-value sentence follows naturally.

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, mutation-safety, provenance of inputs and the shape of the response, which is enough for a 3-param tool with no output schema. Minor gaps remain, such as link expiry or failure behavior for invalid variant ids.

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 items, variant_id, quantity, note and plan_url. The description only reinforces the provenance of variant ids, adding little meaning beyond the existing field descriptions; 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 concrete transformation (variants + quantities -> a Knobs.co cart link) with a named resource and the end-to-end context (shopper opens, reviews, pays on knobs.co). It also names the upstream siblings (search_catalog, get_product, build_plan) that produce the ids, so an agent can place it precisely in the flow.

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?

Clear about the situation that calls for it: you already have chosen variants and quantities and want a pre-filled cart. It does not name an alternative tool or state an explicit exclusion ('use X instead when...'), 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds value beyond that by naming the exact return shape {id,title,text,url,metadata}, which matters because there is no output schema. It stops short of noting error behavior for a missing or stale id.

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 clauses: the action and scope first, then the return shape. Every word carries information and nothing is buried or repeated.

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-param read tool with no output schema, the definition supplies the key missing piece — the response fields — and annotations carry the safety profile. The remaining gap is ambiguity against the get_product sibling and undefined failure behavior for an invalid id.

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 one parameter and 100% schema coverage, the schema already documents that id is the product handle returned by search. The description's '(the handle from search)' repeats that rather than adding format, validation, or fallback details, 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 — fetch one Knobs.co product document by id — and names the return fields. However, it never distinguishes itself from the sibling get_product, which an agent could reasonably read as doing the same thing; only the '(the handle from search)' parenthetical hints at a distinct retrieval path.

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 parenthetical '(the handle from search)' implies the intended flow: get results from search, then fetch by id. There is no explicit when-to-use or when-not guidance, and no statement about which sibling to prefer (get_product vs fetch vs search_catalog), leaving the choice 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely useful behavior beyond that: it discloses that ALL variants are returned and enumerates the variant fields plus sizes and description, compensating for the missing output schema. It does not cover error handling for a bad handle or payload size.

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 with zero filler, front-loaded with the primary payload (every variant of one product) and using parentheticals only to enumerate returned fields. Nothing could be cut 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 no output schema, the description covers purpose, input sourcing, and return contents thoroughly. The only omission is failure behavior for an invalid or stale handle, which is a minor gap for 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 100% and the schema already documents the handle with an example, so the baseline would be 3. The description adds provenance the schema lacks — handles come from search_catalog or a knobs.co/products/<handle> URL — which is real added meaning for obtaining a valid value.

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 (get one product by handle) and immediately scopes the return to every variant with the concrete fields returned. It names search_catalog as the source of handles and even the URL path, so an agent can distinguish it from the search/list siblings 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 clear context on how to obtain the required handle ('from search_catalog or a knobs.co/products/<handle> URL'), which implicitly routes the agent to search_catalog first. It does not explicitly say when not to use it or how it relates to sizing_guide/store_info, so no exclusion rules.

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 annotations by disclosing the double opt-in flow: one email to the shopper, Kayla only receives the request after the confirmation click within 7 days, and the sender address to watch for. This is exactly the operational detail an agent needs for a non-idempotent, open-world send.

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 tight sentences, front-loaded with who and what, then prerequisites, then the confirmation mechanic. Dense but every clause carries operational information; only minor tightening would improve 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?

For a mutating, outward-facing send with no output schema, the description covers consent requirements, the confirmation step, the 7-day window, and expected next actions for the shopper. Nothing essential to calling it correctly is missing.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: where plan_url comes from (build_plan) and what message must contain (the shopper's ask in their own words).

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 actor (Kayla, Knobs.co's Trade Manager), a specific action (review the plan by email or set up a call), and a turnaround (one business day). An agent can tell this apart from general catalog/plan tools 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 explicit preconditions — the shopper's email plus clear agreement to be contacted — and instructs including plan_url from build_plan when a plan exists. It does not explicitly contrast with the sibling ask_sienna, so routing between the two persona tools is left 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the exact return shape `{results:[{id,title,url}]}` and the fact that `id` is a product handle usable downstream — valuable because no output schema exists. It omits result count, ranking/fuzzy-match behavior, and empty-result behavior, keeping it off 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?

Two short sentences, zero filler, with the search scope front-loaded and the return-shape/`fetch` chaining detail immediately after. 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?

For a one-parameter read-only search with no output schema, the description covers purpose, return structure and the key downstream linkage, which is close to sufficient. The remaining gaps — sibling disambiguation from `search_catalog` and result-count/empty-result expectations — are the only things an agent might still need.

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 `query` parameter already carries a rich plain-words description with an example. The description adds no syntax, formatting, or query-construction guidance 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?

"Search Knobs.co products" gives a specific verb and a scoped resource, which is far better than a bare name restatement. It stops short of differentiating from the sibling `search_catalog`, which sounds nearly identical, so an agent still can't tell the two apart 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?

The clause "id is the product handle for fetch" usefully routes the agent to the follow-up tool, which is real usage guidance. However, there is no statement of when to use this versus `search_catalog`, `get_product`, or `ask_sienna`, and no exclusions or prerequisites.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld behavior, so the safety bar is met. The description adds genuinely new context: a hard cap of 10 results, the exact result fields (vendor, center-to-center size, overall length, finishes, list prices, variant ids, URLs), and the matching policy (exact size/finish first, then nearest sizes) — the latter materially affects result interpretation.

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 with the core action and examples front-loaded, followed by return shape and matching semantics in a logical order. The embedded example list is slightly dense but each element carries real information for query construction.

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 search tool with no output schema, the description compensates well by summarizing returned fields, the result limit, and fallback matching. The main remaining gap is disambiguation from the similarly named sibling 'search', which matters for correct tool selection.

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 parameter is already described in the schema, so baseline is a 3. The description earns above baseline by supplying sample query strings and disclosing the exact-then-nearest matching behavior, which tells the agent how permissive it can be when composing the query.

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 ('Search the live Knobs.co catalog') and enumerates the searchable dimensions (item type, size, finish, brand, series) with concrete query examples. It doesn't distinguish itself from the sibling tools 'search' or 'get_product', so an agent must infer which retrieval path to take.

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 shown only implicitly through three sample queries, which convey the expected query shape but not when to prefer this tool over 'search', 'fetch', or 'get_product'. There is no exclusion or alternative-routing guidance, leaving sibling selection 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?

The annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds that the guidance is Knobs.co-specific and rules-based, but it does not clarify whether the content is static, how current it is, or what form the response takes; "No arguments" merely repeats the 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 description is compact and front-loaded, efficiently communicating both the source and the guide's practical scope. Its closing invocation note is brief, and there is no substantial 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?

This is sufficient to select and invoke a simple zero-argument reference tool, especially with its safety profile supplied by annotations. With no output schema, it could be slightly more complete by stating that it returns general guidance rather than personalized calculations or product-specific fit verification.

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

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

There are no parameters, so the baseline is 4 and no further parameter documentation is necessary. The explicit "No arguments" statement confirms simple invocation but adds nothing beyond the empty schema.

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

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

The description clearly identifies the resource as Knobs.co's cabinet-hardware sizing rules and enumerates concrete topics, including pull length, drawer width, knobs versus pulls, and hole measurement. It does not explicitly differentiate the guide from siblings such as ask_sienna or get_product.

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 topic list provides clear usage context for choosing hardware sizes and configurations or measuring existing holes. It does not explicitly say when to use this general guide instead of asking ask_sienna or retrieving product-specific information.

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 mark the tool as read-only, idempotent, open-world, and non-destructive, but the description adds substantial context beyond them. It discloses the eligibility rules, that non-qualifying pieces are returned with reasons, the output shape (cart link plus sample terms), and the downstream purchase/credit process.

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 front-loaded with the core action and return value, followed by qualification rules and sample terms. It is dense but mostly earns its length; the business-policy sentence about emailing order numbers is useful context but slightly expands beyond immediate invocation guidance.

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 two-parameter tool with no output schema and rich annotations, the description is complete: it covers input sources, eligibility logic, return content, handling of non-qualifying pieces, and the sample purchase/credit terms. An agent has enough information to call it correctly and explain the result.

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 plan_url and variant_ids are already well documented in the input schema. The description reinforces the plan/variant alternative and the 'not both' rule but does not add significantly more meaning than the schema already 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 states a specific verb and resource: pick qualifying sample pieces and return a cart link with one of each plus sample terms. It also defines qualification criteria ($20 or under, under 7 inches, not made-to-order), which clearly distinguishes this tool from a general cart or catalog 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?

It explains that samples can come from a plan_url or from given variant_ids, and the schema reinforces that only one should be supplied. However, it does not explicitly say when to use this versus siblings like cart_link or build_plan, nor does it name when-not-to-use conditions.

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 read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds real value by disclosing what information the response will contain (samples, trade program, contact path), which partially substitutes for the missing output schema. It stops short of saying anything about response format or size.

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 listing the covered topics, with no filler. The trailing 'No arguments' is redundant given the empty input schema and slightly dilutes the otherwise tight phrasing.

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-parameter, read-only informational tool with no output schema, enumerating the covered topics is close to sufficient. The main omission is routing guidance against ask_sienna, the most likely ambiguous alternative.

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

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

There are zero parameters, so the baseline is 4. 'No arguments' merely restates the empty schema and adds no new meaning, but no parameter gaps exist to compensate for.

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 enumerates concrete content domains (store identity, product range, purchasing, samples, trade program, human contact, service mechanics), which makes the resource unmistakable. It does not, however, contrast itself with siblings such as ask_sienna, which could plausibly answer overlapping questions.

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: an agent can infer this is the tool for general 'about the store' questions. There is no explicit when-to-use framing and no statement of when to prefer ask_sienna or search_catalog instead.

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