WRDO

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

The annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, yet the description still adds meaningful behavior beyond them: prices_confirmed is false with a price_note when prices are scraped from the business website rather than confirmed. That provenance/confidence semantics, plus the empty-list interpretation, is exactly the kind of context an agent cannot derive 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?

It is front-loaded with what the tool returns, then layers scope and field semantics in a short three-sentence block with no filler. There is mild redundancy, since 'Use an id from search_local_businesses' duplicates the schema's parameter description verbatim, and the parenthetical business types are a touch listy.

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 an output schema present, the description needn't spell out return values, yet it usefully previews the item shape and the prices_confirmed flag. Combined with the id prerequisite and empty-list interpretation, an agent has enough to call it correctly; only the explicit alternative to get_business 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% for the single id parameter, and the schema already documents the 'lbiz_…' format and its source in search_local_businesses. The description restates the same sourcing guidance without adding new syntax, constraints, or examples, so it meets but does not exceed the baseline.

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 concrete resource (a business's price list or menu) and enumerates its contents — sections of items with name, description, price_zar and duration_min — so an agent knows exactly what it returns. It also delineates scope against siblings with 'Never a phone number or email,' implicitly pointing contact data at get_business. The verb itself is carried by the name/title rather than the description text.

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 prerequisite channel ('Use an id from search_local_businesses') and tells the agent how to read a degenerate result ('An empty list means WRDO has none yet'). What it lacks is an explicit routing statement — it never says when to prefer get_business over this tool, leaving the alternative only implicitly implied by the phone/email exclusion.

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, closed-world), so the bar is lower. The description adds genuinely useful behavioral context beyond that: the exact result fields, the deliberate absence of contact details, and the start_url handoff path. It does not discuss limits or empty-result behavior, which keeps it short of 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?

Three tight sentences: what it searches, what comes back, and the critical caveat about contact details. The most decision-relevant constraint is front-loaded and nothing is padded.

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?

An output schema exists, so return-field enumeration in the description is partly redundant, but the description still supplies the geographic scope and the no-contact-details rule that an agent needs to answer correctly. Minor gaps (result-count behavior, no-match handling) remain but are not blocking.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters, including that 'what' may be a category or a business name and that 'where' may be omitted. The description's 'by what they do (or their name)' and 'optionally in a town or suburb' largely restate the schema, so the 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 (find) and resource (local businesses) with an explicit scope: WRDO, Western Cape, matched by activity or name, optionally narrowed by town/suburb. This is clearly distinguishable from the singular get_business sibling without opening either 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 the search semantics, and it does tell the agent what to do after a hit ('to reach a business, give the person its start_url'). However, it never names the alternative (get_business, start_request) or states when a lookup rather than a search is appropriate, so routing between siblings 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?

Goes well beyond annotations by disclosing critical behavioral facts: 'This tool never books, charges or creates an account' and 'Never tell the person they are booked: this only starts a request.' These negative guarantees are exactly the kind of context annotations (readOnlyHint, idempotentHint) cannot convey and materially change how an agent should phrase its response.

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 primary action, followed by the completion location and the critical constraint. Every sentence carries distinct, non-redundant 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 an output schema present and annotations covering the read-only/idempotent profile, the description fills the remaining gaps: what the returned link is for, where the transaction completes, and the explicit non-booking guarantee. Nothing an agent needs to call it or set expectations 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 100%, so per-parameter meaning is already documented. The description still adds value by tying 'optionally from one business' to business_id and clarifying that what/when accept the person's own words, slightly enriching the schema view.

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 ('Get a link the person opens to ask WRDO for a quote, booking or order') and scopes it with the 'optionally from one business' qualifier. Clearly distinct from search_local_businesses, get_business and get_price_list, which retrieve data rather than initiate a request.

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

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

The description establishes the usage context: a person wants a quote, booking or order, optionally scoped to one business (matching business_id). It does not explicitly name exclusions against the sibling tools, but the intent-based framing gives clear when-to-use guidance.

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