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 does substantial work: it discloses the exact data returned, the OGL v3 license, and a per-call price of $0.25 USDC, which lets an agent cost-gate before calling. What it omits is failure-mode behavior (what happens when no charity matches, or whether name lookups are fuzzy) and any rate/limits context.

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 a single dense front-loaded sentence listing the payload, followed by three short high-value fragments (license, usage example, price). Nothing is redundant and the most decision-relevant information appears first.

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 lookup tool with no annotations and no output schema, the field enumeration does much of the return-value work and the price/license notes are valuable. The gap is parameter disambiguation: an agent cannot confidently decide between passing 'name', 'number', or 'suffix', and there is no indication that zero required parameters still implies at least one identifier must be supplied.

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 description coverage is 0%, so the description must explain all three parameters. It only partially does so through the example {number:"1089464"}, which conveys that 'number' is a numeric-string registered charity ID. The 'name' parameter's matching behavior and the purpose of 'suffix' (likely a charity-name suffix like 'Trust' or 'Foundation') are left entirely 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 resource (a UK charity) and an enumerated payload (trustees, 5-year finances, assets/liabilities, governance, flags, linked charities), which is far more informative than the tool name alone. The 'full' qualifier implies a depth distinction from the sibling uk_charity, but the sibling is never named explicitly, so the differentiation relies on inference.

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?

'Use this for full UK charity due diligence' gives a clear positive trigger, and the enumerated fields implicitly define the depth threshold. However, there is no when-not guidance and no pointer to uk_charity or uk_area_profile for lighter or adjacent needs, leaving the agent to guess at the boundary.

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