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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and openness need no restatement. The description adds genuine behavioral context beyond that: result ranking (full profiles above placeholders) and id stability across get_profile/ask_business. It still says nothing about return shape, pagination, or count behavior for a browse tool whose results may be truncated by 'limit'.

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 sentences, front-loaded with the capability, then the trigger, then the behavioral caveats and limits. Every clause carries information: example inputs, ranking rule, id reuse, and the geo/neighborhood exclusion.

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 6-parameter, no-output-schema discovery tool, the description covers purpose, trigger, ranking, id reuse, and unsupported filters, which is most of what an agent needs. Missing are downstream-usable details such as what a result entry contains and how 'limit' affects ranking/truncation.

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 83%, so the baseline is 3 and the per-parameter descriptions already cover city/country/category formats and the min_quality enum. The description corroborates category semantics with an example and hints that quality affects ranking rather than only filtering, but never touches 'limit' or 'language', so it adds little beyond the 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?

States a specific verb and resource ('Browse businesses') plus the scoping axes (CATEGORY and place), and the example ('italian restaurant' + 'amsterdam' + 'netherlands') makes the three-way key concrete. The negation 'does NOT know a specific business name' implicitly separates it from the name-oriented sibling search_business, so an agent can route without opening schemas.

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 an explicit trigger condition ('Use when the caller does NOT know a specific business name') and a worked example, and rules out unsupported narrowing with 'Neighborhood and geo filtering are not supported yet.' It does not name search_business as the alternative for the known-name case, leaving that routing inference rather than stated.

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