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

Beyond readOnlyHint/openWorldHint, it discloses the result payload (why-it-fits rationale, hours, live open status including the caveat that "open" means in business, phone, how to act, and a trailing next-step hint), the default of five results, and that max_minutes is a straight-line estimate rather than real routing. No rate limits, auth, or cost behavior are mentioned.

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?

Front-loaded with "Start here." and packs the key input rules and output shape into a few dense sentences. The long middle sentence with nested parentheticals is harder to scan than it needs to be, but no sentence is filler.

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 16-parameter, no-output-schema search tool, the description covers entry-point role, input shaping, defaults, and return contents, which is most of what an agent needs. Gaps are minor: it doesn't explain the refines/search_id linking behavior or how compact vs full detail results differ.

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 the schema already defines all 16 parameters in detail; the description mostly restates the need-vs-sentence distinction and the open_at/limit conventions. It adds only light framing (e.g. max_minutes "to stay close") that the schema does not already say better.

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?

"Start here. Find businesses that fit a need near a place" gives a specific verb, resource, and scope in one breath, and the imperative "Start here" positions it against siblings such as get_business_record and more_results which presuppose an existing search.

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 tells the agent when this is the right entry point and how to shape input (plain-words service, timing routed to open_at, extra requirements to the filters), and notes default result count vs asking for more with limit. It never names an alternative sibling explicitly, so the when-not-to-use side is left implicit.

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