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

Annotations already cover read-safety (readOnlyHint) and open-world data, and the description adds genuinely non-inferable context: data provenance (official Census bulk state file), vintage ('latest year published'), legal-form scope ('all legal forms'), the hard limitation of no company-level records, and the exact billing model ($0.002 USDC per successful call via x402 on Base/Solana/Arc, failed calls free). The paid-call and non-refund semantics are the kind of thing an agent must know before invoking.

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?

What the tool returns is front-loaded, followed by the scope caveat and then pricing, so an agent can stop reading early if the aggregate-only constraint disqualifies it. The single long sentence-chain is dense but each clause (vintage, legal forms, no names, price) carries distinct decision-relevant information; only the payment-rail enumeration (Base/Solana/Arc) is marginal detail.

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?

An output schema exists, so return-value shape need not be described, and with only two fully documented parameters the description covers everything else an agent needs: dataset identity, aggregation grain, data vintage, the 'no company names' limitation, and cost/settlement mechanics. Nothing material is left to inference before a call.

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 real meaning: it clarifies that omitting the NAICS code returns all industries and that the code ranges from 2 to 6 digits, and it reinforces that `state` is a FIPS code rather than a name or abbreviation. It does not add format validation or example values beyond what the schema already supplies.

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 names a specific dataset (US Census County Business Patterns), the geographic grain (by state FIPS), the metrics returned (establishments, paid employees, Q1 and annual payroll), and the industry grain (all industries or one 2-6 digit NAICS). It also explicitly differentiates from company-level siblings with 'Aggregate counts only, no company names,' which is exactly the axis an agent needs to pick between this and the many company-profile tools listed.

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 'aggregate counts only, no company names' clause effectively states when this tool is the wrong choice (any request for named companies), and the NAICS/state framing makes the intended query shape clear. It stops short of naming a specific alternative sibling (e.g. a company registry tool) for the named-company case, so the routing is implied rather than explicit.

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