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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: no authentication or cost barrier, and the shape of the result (matching providers with an id that is the NPI). It doesn't mention result limits or pagination.

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 tight sentences: query capability first, then cost/auth and return shape. No redundant restatement of the title, and every clause carries information the agent needs.

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 one-parameter read tool with full schema coverage and no output schema, the description supplies the essentials plus a brief description of the return payload. Only missing piece is whether results are truncated or ranked, which matters for open-world search.

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 single parameter is already documented. The description still adds value beyond the schema by giving a concrete query example ('Jane Smith UT') and reinforcing the 10-digit NPI format, which clarifies the state-suffix convention the schema only alludes to.

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 the CMS NPI registry') and enumerates the accepted query forms: provider name, business name, or 10-digit NPI. It distinguishes itself from fetch by noting fetch expands the returned id, but says nothing about how it differs from lookup_npi or verify_npi.

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 clear operating context – free, no login – and explicitly names the follow-up path (fetch expands the returned NPI id). It stops short of stating when to prefer lookup_npi or verify_npi over a free-text search, leaving that inference to the agent.

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