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

Annotations already declare readonly/openWorld/idempotent/non-destructive, lowering the bar. The description adds meaningful behavioural context beyond that: it explains the ranking is organic and evidence-based via the TATEH Truth Score and distance, that ranks are not for sale with no sponsored results, and that results carry evidence lines, licence records and sources. It stops short of describing pagination or result-count behaviour, but the disclosure of ranking mechanics is a real value-add.

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 core purpose and the sibling routing are front-loaded, and the long trade list and ranking explanation earn their place by setting expectations. It is dense and slightly repetitive (e.g. the "best/official/#1" disclaimer plus the 'no sponsored' clause overlap), keeping it short of a 5.

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, return-value layout need not be described, and annotations cover the safety profile. The description supplies everything else an agent needs: scope, ranking rationale, inclusions, exclusions and sibling alternatives.

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 only 29%, so the description must compensate. It partially does: "up to five" clarifies the limit cap, "open now" clarifies open_now, and the location phrasing clarifies the geospatial params. However it gives no detail on service input format, the lat/lng vs location tradeoff, or radius_m behaviour beyond what the schema already says.

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 service providers) with explicit scope: up to five, in Jewish neighbourhoods of NYC, for a trade or need. It clearly distinguishes itself from siblings by declaring it does NOT check kashrus and routing food/events to search_places, verify_kosher, recommend_food and search_events. An agent can tell exactly what this tool returns and what it does 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?

Provides explicit when-to-use exemplars ("I need a plumber in Boro Park", "a dentist near Crown Heights open now") plus explicit when-NOT-to-use with named alternatives for food, kosher and event queries. Nothing 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.