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

Annotations only cover the safety profile (read-only, idempotent, not open-world); the description adds substantial behavior beyond them: data provenance (addresses read off the brand's own store page, never a homepage or third party), the coordSource corroboration and the fact that three brands publish a wrong schema.org geo, the complete absence of hours and the resulting prohibition on saying open/closed, the phone fallback, and the 'returns up to 8' cap.

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?

Long but dense and front-loaded: purpose and scope first, then routing, then provenance caveats, then the hours prohibition. Nearly every sentence carries a distinct constraint, though the provenance paragraph is slightly discursive for a tool description.

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?

No output schema exists, so the description must carry return expectations — it does ('Returns up to 8') and covers the critical behavioral caveat (no hours data) plus the fallback field. An agent has everything needed to call it and to avoid the one dangerous misstatement.

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 67% schema coverage, the schema already documents town and query, but the description adds real semantics: query matches name, brand, category and the one-line 'what', with concrete examples, and town should be passed in the asker's own words. The category enum is left entirely to the schema, which is fine given it is self-explanatory.

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 with scope ('Verified East End SHOPS. 74 stores across 9 hamlets on the South Fork, North Fork and Shelter Island') and enumerates the categories covered. It explicitly differentiates from sibling search_places, so an agent can route between them 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?

Gives explicit triggers ('any shop, shopping, store, boutique, browse, bookshop, gift or where-can-I-buy question') and the day-plan case, plus a hard exclusion ('shops are not in search_places, which promises an open/closed verdict'). It also states the no-argument behavior, which selects a different mode entirely.

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