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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered; the description still adds real behavioral context, including the qualification thresholds (1 round for fintech funds, 2 for generalist or unknown focus), the exact per-fund payload, the data-quality caveat that size/target is 'never converted', and the fact that unknown arguments are rejected. One flaw: it states 'limit ≤ 50' while the schema permits up to 200, which is a behavioral statement inconsistent with the structured contract.

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?

Information density is high and little is truly wasted, but the opening is a long criteria run-on rather than a front-loaded statement of what the tool returns, and the eligibility logic, payload, and filter semantics are jammed into prose that would read far better as a short lead sentence plus bullets. It is dense but poorly structured for scanning.

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 read-only list tool with no output schema, the description supplies the qualifying conditions, the per-fund fields, filter semantics, and error behavior, which is close to what an agent needs to call it correctly. Two gaps remain: no result ordering is stated (which funds appear first matters for a top-N list), and the limit ceiling is contradictory between description and schema.

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 description genuinely adds meaning beyond the schema: filters apply to the qualifying rounds rather than to the fund, topic routes through news linked to the round, country is the portfolio company's country slug, and stage is derived from round_type. The only negative is the limit ≤ 50 claim conflicting with the schema's maximum of 200, which muddies an otherwise well-explained parameter.

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 defines a precise population: approved, not other-sector funds whose latest close is within 24 months and whose manager invested in public equity rounds in the last 12 months, backing fintech rounds. That is far more specific than the name alone and an agent can tell it apart from search_funds or list_fund_closes on criteria. It stops short of naming a sibling as the alternative, so it is clear but not differentiated to the level of a 5.

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?

Usage is implied by the eligibility criteria (a fund must have raised within 24 months and deployed into fintech rounds within 12 months), which tells an agent the intended scenario. However, there is no explicit when-to-use statement, no when-not-to-use, and no mention of search_funds, most_active_investors, or list_raising as alternatives for overlapping questions.

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