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

Annotations only cover readOnlyHint and openWorldHint, and the description adds substantial operational context: $0.005 per-call pricing, a 3-free-calls/day per-IP tier with a 3-row cap and an opt-out via _meta, 404 behavior for out-of-scope states, the confidence formula (agreement × freshness) with its decay rule, and data-freshness semantics tied to SST posting deadlines. This is exactly the beyond-annotations disclosure the dimension rewards.

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?

Scope and matching precedence are front-loaded, which is good, but the block is dense and run-on, and the closing legal boilerplate ('Not tax advice… verify with the state. See /terms.') plus the full confidence derivation consume space without helping an agent select or invoke the tool.

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 carries the return-value burden and does so: each jurisdiction's rate, the combined rate, the effective period, and how to read the confidence score. Coverage limits, pricing, and out-of-scope behavior are all present, so nothing needed for a correct call is missing.

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 already 100%, so the baseline is 3, but the description adds real semantics the schema lacks: why an address is preferred (address records when published, else ZIP+4, else the 5-digit record at the lowest rate in the ZIP per SSUTA 305) and what the date parameter's lower bound implies. That goes beyond restating the schema.

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 — the sales-tax rate at a ZIP+4, ZIP, or street address — and enumerates the 24 covered states, so the agent knows exactly what domain it answers for. It does not, however, name or contrast itself with the sibling tax_sales_rate_batch, leaving the single-vs-batch distinction to inference.

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 a clear usage boundary: the tool applies to the 24 listed SST states, and locations outside them return 404 and are not charged, which is an explicit exclusion. The address/ZIP+4/5-digit matching precedence further tells the agent how to frame a query, though no alternative tool is named for cases this tool can't serve.

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