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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine beyond-schema context: which result fields are tier-gated (phone, website, address, hours, photos, coordinates only for paid plans; description only for higher tiers) and what quote_request_url is for. It omits ordering, total-count, and empty-result behavior, but the data-availability disclosure is substantive.

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 front-loaded sentences: what it does, what every result contains, and what is gated. No filler. The final clause ('and the description only for providers on a higher paid plan') is slightly tangled but each sentence earns its place.

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 no output schema, the description usefully enumerates the returned fields and their tier conditions, which is exactly the information an agent needs to interpret results. Gaps remain around result ordering, pagination/total counts, and behavior with zero matches, but the core completeness bar for a read-only search tool is met.

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 100%, so all five parameters are already documented, including the query's coverage of 'business name and description' and the limit range. The description only loosely maps to those parameters ('by name, category, or location') without adding format, matching, or combination semantics. Baseline 3 applies when the schema carries the load.

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: 'Search local business profiles on Bezal by name, category, or location.' An agent immediately knows this is a discovery/search tool over business entities. It does not, however, explicitly distinguish itself from siblings like search_by_city or search_by_service, which cover overlapping lookup modes.

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?

Usage is only implied by the 'by name, category, or location' phrasing; there is no explicit when-to-use or when-to-prefer-a-sibling statement. It never says whether search_by_city or search_by_service should be used instead when the intent is purely geographic or purely categorical.

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