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

Annotations already declare the read-only/idempotent/open-world safety profile, and the description layers on genuinely non-obvious behavior: the list is one row per sanction ORDER, most orders are fines or corrective action plans rather than exclusions, only SUSPENSION or TERMINATION counts as an exclusion, and the end date is DERIVED because AHCA publishes no reinstatement date. It stops short of describing pagination or how multiple matches of different identifier types are reconciled, so a 4 rather than a 5.

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 core question is front-loaded in the first clause and the dense body is mostly load-bearing domain context (sanction classes, match strength, sourcing). It is a single unbroken paragraph and the quoted 'Answers …' sentence partly restates the opening question, which is the only real waste.

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 fully carries the return-shape burden: it enumerates sanction_class, is_participation_exclusion, Rule 59G-9.070 violation codes with descriptions, fine amount, case numbers, and the derived end date, plus sourcing and keyless access. An agent knows what it will get back and how to interpret it 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 100%, so the baseline is 3, but the description adds the epistemic weighting behind the parameters — NPI/license/Medicaid-number matches are identifications while a name match, even exact, is only a candidate because AHCA publishes no date of birth. The limit parameter's ordering rule (exclusion orders before fines, newest first) is described in the schema, so the description adds rationale rather than new syntax.

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 (screens/checks) against a specific resource (AHCA Florida Medicaid Sanctioned Providers final-order list) and frames it as the state-level counterpart to the federal LEIE. It explicitly names the sibling tools ny_omig_check_exclusion, ca_medical_check_exclusion and tx_medical_check_exclusion, so an agent can route between state screens without opening schemas.

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 concrete use cases (pre-payment/credentialing screening, verifying exclusion status, NPI lookups) and names the alternative resource (the leie pack) plus the conditions that distinguish this Florida-specific tool from it and from the other state siblings. It also warns when NOT to over-trust a hit: name matches are candidate leads only, which is exactly the kind of usage boundary an agent needs.

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