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

The annotations already mark the tool read-only and idempotent, but the description adds critical interpretive caveats beyond that: GAV is defined precisely as assets on a filing date and not fund size/commitments/dry powder, quarantined readings are excluded, the data tape is 2011-2024 so no 2025 facts exist, and holdings/properties/loans appear only after blind-label validation. These materially shape how an agent should interpret results.

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?

Five dense sentences with no filler; every clause adds a needed constraint, definition, or caveat. It is appropriately sized for a complex tool, though the first sentence is overloaded and would benefit from structured formatting or splitting into clearer sub-clauses.

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 16-parameter, zero-required, no-output-schema search tool, this is unusually complete: it defines the entity, enumerates returned fields, lists all filter categories, and flags date and validation semantics. Combined with schema descriptions for cursor/limit/state, an agent can select and call this tool with high confidence.

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 only 38%, so the description must compensate, and it does: it groups the filter surface (state, strategy class, size band, operator model, GAV, vehicles, property type, holdings, public LPs) and defines the core numeric concept behind min/max_gav_usd. Some parameters like sort, crd, and limit are left to the schema/enums, but the semantically loaded metrics are clarified.

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 the exact population (advisers swearing a Real Estate Fund vehicle on Form ADV Schedule D 7.B.(1)), enumerates the returned data fields, and lists the filter dimensions. This clearly distinguishes it from sibling tools like search_re_fund_vehicles and get_re_fund_manager without needing schema inspection.

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?

No explicit guidance is given about when to use this tool versus sibling search/get tools. It states what data is included and which filters exist, but never says when this tool is preferable to search_re_fund_vehicles, get_re_fund_manager, or when it should not be used. Usage context is only implied by the title and field list.

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