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

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description's remaining side of the bargain is to disclose behavior: whether rates are averages or statutory rates, what an unfiltered call returns, and how results are scoped. None of that is present.

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?

One sentence, front-loaded with the verb and resource, zero filler. It is efficient, though the brevity is partly why usage and behavioral gaps remain.

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 four all-optional filters and no output schema, the description should at minimum clarify default behavior (all locations?) and filter combination semantics so the agent can call it correctly. It covers the output subject matter at a high level but leaves these invocation-critical questions open.

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 100%, including case-sensitivity notes for city and the 2-letter state format, so the schema fully documents the parameters. The description only restates the filter dimensions (state, county, city, ZIP) without adding syntax, precedence, or combination rules, which matches the baseline 3.

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 ("Returns effective property tax rates") and scopes it to United States locations, which cleanly separates it from tax siblings such as getSalesTax and calculateIncomeTax. It never names those siblings explicitly, so an agent must infer the distinction from the resource noun alone.

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 description lists the filter dimensions but gives no when-to-use guidance, no alternatives, and no exclusions. Critically, all four parameters are optional, and the description never says what happens when the agent supplies none of them or how multiple filters interact.

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