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

Annotations already declare read-only, idempotent, closed-world and non-destructive, and the description goes well beyond them: cost is free and keyless, it consumes a 10/day keyless allowance but never agent credits or quota, and counts under 5 are bucketed as "<5" with zero reported as "none". These are exactly the operational facts an agent needs before deciding to spend a call.

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?

Strongly front-loaded with "START HERE" and the output contract established early. The cost information is duplicated nearly verbatim at the end (free / never billed / 10-call keyless allowance), which is the one clearly redundant block — that repetition earns a small deduction rather than a 5.

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 output schema, the description nonetheless pins down the return contract (counts only, "<5" threshold, "none" for zero) and the cost/rate-limit profile. For a two-optional-parameter coverage-check tool this leaves nothing material unspecified.

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 country (full name or ISO code, undisclosed HQ excluded and surfaced as undisclosed_hq_count) and lp_type (enum with spelling normalisation) are already fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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 specific question it answers ("does Fund Momentum cover my geography and LP type") and the exact shape of the answer (counts only, with a count of emerging-manager-backed LPs). It explicitly negates what it does not return (names, slugs, websites, commitments), which separates it cleanly from search_lps.

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?

"START HERE for any question about limited partners" plus "Call this before search_lps to find out whether LP Radar covers what you need" gives an explicit ordering rule and names the alternative it gates. An agent knows both when to call it and what to do next.

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