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

No annotations are supplied, so the description carries the full burden. It does disclose a genuine behavioral trait the schema cannot: it refuses with a 'do_not_answer' signal when a fact is drifted or unverified instead of guessing. However, 'drifted' is undefined, and there is no information on permissions, freshness checks, or what a successful response contains.

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 short sentences, front-loaded with the action and immediately followed by the refusal behavior. Efficient, though the internal token 'do_not_answer' is dropped without explanation, which costs a small amount of clarity.

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 annotations and no output schema, the description is the only behavioral source, and it covers the core refusal semantics but not the return content, freshness guarantees, or ID provenance. Adequate as a minimum but clearly short of what a lookup tool with an undocumented key needs.

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?

The single parameter fact_id has 0% schema description coverage, so the description must compensate — and it does not. It never says what a fact_id looks like or where to obtain one (presumably from parkinguk_list_facts), leaving the only argument effectively undocumented.

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 concrete verb and resource: 'Get one verified fact from the parkinguk pack.' The domain prefix in the name plus 'parkinguk pack' scopes it against the many other-domain siblings, but the description never distinguishes it from parkinguk_list_facts or parkinguk_changes, which is the differentiation that actually matters here.

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?

'Get one ... fact' implies single-record retrieval by ID, so the usage is inferable, and the refusal clause hints at when a call yields no answer. There is no explicit statement of when to prefer this over parkinguk_list_facts or parkinguk_changes, nor any prerequisite such as obtaining a fact_id first.

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