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

Annotations already cover safety via readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful domain behavior: GAV is reported gross assets with an as-of date, Form D numbers appear only 'where the adviser gave one,' and reporting after 2024-12-31 is roster counts only. These caveats go beyond the structured annotations.

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 long but dense and well organized: source, returned fields, custodial extension, filter options, then the data caveat. Every clause adds information, and the caveat about post-2024 reporting is placed at the end where it reads as an important limitation without detracting from the main purpose.

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?

Given 11 parameters and no output schema, the description covers both the input semantics and the expected return fields, including optional custodian details. It is missing only explicit pagination behavior and what happens with an empty query, but the cursor parameter and page language make these reasonably inferable.

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 55%, and the description partially compensates by mapping filter concepts to parameters: adviser (dfx:ria:UUID or CRD), name/805-id/021-Form D for query, type, status, state, Form D number, and min_gav_usd. It gives useful meaning for several parameters not described in the schema, though sort and limit remain without added explanation.

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 states a specific resource — private funds reported on Form ADV Schedule D 7.B.(1) — and enumerates the fields returned, from SEC fund ID to custodians. It also draws a clear boundary with 'reported gross assets, NOT fund size or commitments,' which distinguishes it from related fund concepts and sibling fund-search tools.

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?

The description gives clear filtering dimensions (adviser, name, type, status, state, Form D number, minimum gross assets) and explains what data is included, so usage is strongly implied. However, it never explicitly says when to prefer this tool over siblings like search_pe_funds, search_vc_funds, or get_ria_firm, nor does it state any exclusions or alternative conditions.

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