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

The description adds meaningful behavioral context beyond the readOnlyHint annotation: it returns 'dated source context and fail-closed coverage' and notes that 'source_file and snapshot_digest may be null for the multi-source result.' This helps set expectations about output and edge cases. It does not contradict the annotation.

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?

The description is two sentences, front-loaded with the core action and source enumeration, then the return behavior and use cases. Every sentence carries meaningful information and there is no redundancy or 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 tool with a single simple parameter, no output schema, and a readOnlyHint, the description conveys the inputs, coverage, return characteristics, and intended use cases. It is sufficiently complete for an agent to decide when and how to invoke it.

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?

The schema already fully describes the single npi parameter with 100% coverage, including '10-digit NPI' and the source lists. The description adds use-case context but no additional parameter-specific details, so it meets the baseline without going beyond.

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?

The description clearly states the verb ('Check whether') and the resource ('US healthcare provider by NPI appears in available exclusion or integrity sources'), enumerating the specific source lists. It does not explicitly contrast with similar sibling tools like search_sanctions or lookup_npi, so it misses the full 'distinguishes from siblings' bar.

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?

The description provides explicit when-to-use context: 'Use for exclusion screening, provider or vendor due diligence, or any “is this NPI excluded?” question.' This is clear usage guidance, but it does not mention when not to use this tool or suggest alternatives, so it lacks explicit exclusions.

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