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

Annotations already declare readOnlyHint, idempotentHint, and non-destructiveHint. The description adds meaningful behavioral detail: ambiguous operator names return candidates instead of a guess, sources are published, the tool is provided free without a key, and dates trigger deadline computation. No contradiction exists.

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?

The description is dense but focused and front-loads the tool's purpose. It covers the three main output categories plus important caveats in about 200 words. It is a single long paragraph, though; bulleted or segmented structure would make it even easier to scan.

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?

For a 3-parameter read-only, non-destructive tool, this is a near-complete description: it enumerates the output content (body, three deadlines, POPLA history, dispute rate) and notes the candidate-instead-of-guess behavior. No output format is specified, but the context and annotations supply enough for an agent to invoke or supply.

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% because each property already has a clear explanation. The description adds semantic links beyond the schema: issuer maps to the appeals body, rejection_date drives the independent-appeal clock, and no notice_date means no deadlines are computed. This gives the agent reasoning guidance, not just type information.

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 clearly specifies the tool's scope: a single call that returns the correct appeals body, three deadlines, and the POPLA record for a UK private parking charge. It is a specific verb-and-resource bundle, but it does not explicitly differentiate itself from the sibling popla_outcomes, which overlaps on the POPLA-record portion.

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 gives clear context for when the tool would be used — for a UK private parking charge with the notice date and rejection date — and warns that the wrong appeal body wastes the free appeal. It does not state when to prefer siblings such as popla_outcomes or denial_clock for more restricted runs, nor does it name alternatives in those cases.

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