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

Goes well beyond the readOnly/openWorld annotations by disclosing pagination (20 per page), that calls route via a residential proxy, and the exact billing model: $0.01 USDC per successful call via x402 on Base/Solana/Arc, with failed calls uncharged. What's missing is whether the payment handshake happens automatically or requires agent action, and any rate-limit or retry 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?

Dense but front-loaded: the operation modes and return fields come first, with cost and transport details trailing. Every clause carries information an agent needs (pagination, proxy, per-call price, non-charging on failure), though the pricing sentence is long enough to slightly blunt scanability.

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 an output schema present, the description needn't explain return values, and it still summarizes them plus cost, pagination, and proxy behavior. The remaining gap is the zero-required-parameter case — the agent isn't told whether an empty call is valid or what it returns.

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 baseline is 3, but the description adds real meaning: it clarifies that 'name' produces a paginated (20-per-page) alphabetical listing of summary records, while 'detail' takes a search-result URL and returns the full entity record with officers, agent, and annual reports. That semantic split is not obvious from the two one-line schema descriptions alone.

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?

Names a specific resource (Florida business entities from the Division of Corporations / Sunbiz) and distinguishes its two operations: a paged name search versus a single full record fetched from a result URL. It also enumerates the returned fields, so an agent can tell it apart from the other registry tools (Delaware, Texas, NY) by jurisdiction and by output content.

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 'name search ... or one record via a result URL' construction routes the agent between the two supported modes explicitly. It stops short of stating edge conditions — what happens when neither parameter is supplied (required count is 0) or when both are given — and names no alternative sibling tool.

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