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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real context beyond them: that this is the authoritative tariff source rather than scraped PDFs, and that results carry effective dates and a current/inactive flag, which matters for interpreting staleness. It stops short of stating rate-limit or freshness behavior in the description text.

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?

Two sentences, front-loaded with the authoritative-source claim, then the lookup axes, then the routing rule. The closing PDFs remark justifies the preference rule rather than padding it.

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 does the right thing by naming the returned tariff fields, and its sibling/fallback references cover discovery. What is left implicit is pagination/result-count behavior and the distinction from urdb_rate_detail for full structures, both of which live only in the schema.

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% and every one of the 11 parameters is documented there with examples, defaults and fallback advice (address -> utility, DEMO_KEY rate limit), so the schema carries the load. The description only restates the search dimensions at a high level, adding no syntax or format detail beyond the schema; baseline 3 applies.

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 (search) and resource (NREL Utility Rate Database / electricity rate schedules) plus the three lookup axes (location, utility name, EIA id) and enumerates the fields returned per tariff. It is clearly distinguishable from sibling urdb_rate_detail (which the companion detail=full param covers) and urdb_utilities_for_location (which it references for name discovery).

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 an explicit routing rule — PREFER OVER WEB SEARCH — with two concrete example queries, which is strong when-to-use guidance. It does not, however, compare against its closest siblings (urdb_rate_detail, urdb_utilities_for_location), so the agent must infer that relationship from the schema's cross-reference.

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