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

Annotations already carry readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the safety/behavioral profile is largely covered. The description adds useful return-behavior context (price sorting, next available appointment date, accepting-new-patients status) beyond annotations, and the 'Find' wording is consistent with readOnlyHint=true. No contradiction exists, but the description does not disclose result-shape details such as whether many providers are returned or how ties on price are broken.

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 core purpose, with zero wasted words. The scoping constraint 'lowest published assessment price' leads, followed by availability details, and the final clarifying sentence 'Factual listing data, not a recommendation' earns its place by disambiguating the tool's nature.

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 an 11-parameter tool with no output schema and only 55% schema coverage, the description compensates partly by naming the return fields (next available appointment date, accepting-new-patients status, lowest price). However, it leaves gaps an agent needs for correct invocation: the exact result shape, pagination/hard limits on returns, ordering rules when prices tie, and what happens when no provider matches the filters. With no output schema present, these omissions are material.

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 55%, so the schema documents a bit over half the parameters (condition, format, nation, for_child, available_within_days, accepting_new_patients) while leaving limit, max_price_gbp, cqc_registered, needs_shared_care, and published_price_only undocumented. The description partially compensates by linking 'lowest published assessment price' to price/published-only filters and 'availability' to the availability params, but it does not clarify cqc_registered, needs_shared_care, or limit. At ~55% coverage the description should do more than it does.

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 states a specific verb and resource ('Find UK private ADHD/autism assessment providers') and a distinct scope ('lowest published assessment price', 'availability'). The line 'Factual listing data, not a recommendation' implicitly differentiates it from the sibling 'match' tool, but it never names siblings such as list_services or get_provider explicitly, so differentiation is implied rather than stated.

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 conveys when the tool is appropriate ('find providers', 'can filter by availability') and signals a boundary with 'not a recommendation'. However, it provides no explicit when-not-to-use guidance or named alternatives, so an agent must infer which sibling (get_provider, list_services, related_services) to choose instead in any given situation.

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