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

Annotations already cover read-only/idempotent safety, and the description adds substantial context on top: verdict taxonomy and what each means for problem-counting, that queued licenses have no read time yet, that `estimated_seconds` grows when the check is late, and that `next` explains why it is not done. This is exactly the polling/lifecycle behavior an agent needs and cannot get from the annotations.

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?

Purpose is front-loaded and every clause carries information about the response shape or polling behavior. The middle is a dense run-on enumerating verdicts and cell metadata, which is efficient but slightly hard to parse in one pass.

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?

There is no output schema, so the description bears full responsibility for return values — and it delivers: row granularity, verdict values and their meanings, findings, per-cell source links and read time, mismatches, plus the in-progress fields (`next`, `look_again_in_seconds`, `estimated_seconds`). An agent can consume the response correctly without guessing.

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 0%, so the description must carry parameter meaning; it does so only in one closing sentence. It does add a genuine constraint not in the schema (the email must be the one that sent the list, which matters for authorization), but `request_id` is only named, not characterized beyond the schema's uuid format.

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 ("Read your provider check results") and immediately characterizes the shape of what comes back: one row per NPI with a verdict. An agent can distinguish this from provider_check_request/vendor_check_status by the result-oriented framing, though no sibling is named explicitly.

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?

Clear usage context: call it to see results "as they arrive" and while the check runs, use the `next` guidance and `look_again_in_seconds` to decide when to poll again. That is a real when-to-use signal, but no explicit exclusions or named alternatives (e.g., 'call provider_check_request first to obtain the request ID') are given.

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