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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it returns matching listings with verification provenance, and it prescribes a fallback and a hard prohibition on asserting validity without a match. It omits any note on result volume or partial-match behavior.

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?

Two sentences, zero filler, with the lookup scope front-loaded and the guardrail following. Every clause carries actionable information.

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 a rich annotation set and an output schema present, the description needn't explain return values, and it correctly focuses on lookup scope and the no-match policy. The one meaningful hole is that it says nothing about how the four optional identifiers combine, which an agent must guess before calling.

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 75% (only 'phone' lacks a description), so the schema carries most of the load. The description names number, business name and phone, but never mentions 'issuer' at all, nor whether identifiers are ANDed or ORed, nor that despite zero required params at least one identifier is presumably needed to get a match.

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 ('look up a license') plus the three accepted identifiers and, unusually, the output framing ('which listings carry it and how it was checked'). The subject matter cleanly separates it from all siblings (ask, find_businesses, get_business, request_*), none of which deal with licenses.

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 explicit negative-case handling: 'When nothing matches, tell the person to check the issuer's own lookup; never say a license is valid without a match.' That is real routing guidance an agent would otherwise get wrong. It does not, however, say when to prefer this over find_businesses/get_business, or how to choose among the identifier parameters.

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