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

Annotations already say readOnly/idempotent/non-destructive, and the description adds substantial behavior on top: at most one widening step at 8/16/32/50 km, deduplicated and separately labeled wider results in neutral order, owner-approved offerings ordered first, unconfirmed public website results carrying no price or availability, and the version 1 envelope shape. It also warns that empty results describe only this query and never city-wide coverage, which prevents a serious misinterpretation.

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?

Nearly every sentence carries real operational information, but they are delivered as one undifferentiated block where widening rules, output envelope, ordering, citation policy and parameter notes are interleaved. Front-loading is weak: the crucial city-parameter semantics arrive at the very end. Structured bullets would have preserved the content with far less parsing cost.

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 documenting the envelope fields, data_coverage, reach values and the null-distance virtual case. A complex read tool with a nested parameter is mostly covered, but the unexplained `attributes` object and the absence of any radius_m definition leave a gap an agent would notice when filling the schema.

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 0%, so the description must carry all parameter meaning. It explains `city` well (name, slug or neighborhood, with examples, plus the matched/none_in_city/unrecognized outcomes) and implies the radius step behavior, but never defines `radius_m` units, default or cap, and never mentions `q` or the nested `attributes` object at all. With 6 parameters and a nested object, this compensates for only about half.

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?

Opens with a specific verb and resource: 'Searches items and services near a point.' The scope (radius around a point, optional city narrowing) and the differentiation from directory-oriented siblings (discover_local includes directory businesses; find_nearby_businesses searches when nothing matches) let an agent place this tool precisely.

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 routing rules: use find_nearby_businesses when nothing matches, discover_local when directory businesses are wanted, and that city searches do not widen. It also warns never to treat directory alternatives as confirmed matches. It lacks an explicit 'when not to use this at all' statement, and the guidance is scattered rather than organized as a decision list.

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