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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld=false, so the safety profile is covered. The description nonetheless adds real behavioral context: entries are never merged or ranked, payload is roughly 3 KB per entry with 50+ entries, results are informational only, and as_of requires a plan with as-of queries.

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?

Front-loaded with the core capability and an inline example, and every sentence carries information. It is dense but not padded; only mild redundancy exists between the as_of note and its schema pattern.

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?

No output schema exists, yet the description tells the agent the entry shape (same as get_rule), the approximate volume and size of results, the default scope, and the auth precondition for as_of — enough to call correctly and anticipate the response.

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 goes beyond it by spelling out the default jurisdiction set and its size, a worked example payload, and the API-key constraint on as_of — details the schema cannot express.

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 (get one rule type across jurisdictions), the batch scope (in one call), and anchors the output shape to the sibling get_rule, so an agent can tell it apart from get_rule/get_rule_as_of without opening any schema.

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?

Explicitly describes what happens when jurisdictions is omitted (every state and province, or the named level) and notes level is the alternative selector to jurisdictions. It stops short of an explicit 'use get_rule for a single jurisdiction' routing sentence, but the relationship is strongly implied.

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