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

With no annotations at all, the description carries the full burden, and it usefully discloses the cost model ("cost: 1 credit"), which is real behavioral information not available elsewhere. However, it says nothing about matching semantics (partial vs. exact, postcode length/format), default result count, or the shape of returned results, which matters for an unannotated tool.

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?

One sentence plus a parenthetical cost note; the resource and lookup keys are front-loaded and there is no filler. Nothing in it could be removed without losing information.

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 search tool with no output schema and no annotations, the description should at least hint at what comes back (e.g., location IDs usable with cqc_location) and how limit affects credit cost. It covers the search intent adequately but leaves the agent guessing about result contents and follow-up calls.

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 baseline is 3, but the schema's parameter descriptions are only type placeholders ("string", "number"), meaning the description is doing most of the real work by labeling name and postcode as the search keys. It adds nothing about the limit parameter (default, max, or interaction with credits), leaving the most ambiguous parameter unexplained.

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 names a specific verb ("Find") and a concrete resource set ("CQC-registered care homes, GP practices, hospitals and clinics") plus the lookup keys (name or postcode), so an agent immediately knows what the tool returns. It does not distinguish itself from the sibling cqc_location, which likely retrieves details for a single provider, leaving that routing inference to the agent.

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?

"by name or postcode" implicitly tells the agent this is the entry point when searching for a provider, but there is no explicit when-to-use vs. the cqc_location sibling, no stated prerequisites, and no guidance for what to do when neither key is supplied (0 required parameters).

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