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

Annotations already declare read-only, idempotent, non-destructive, but the description adds substantial behavioral context beyond them: entitlement/locked gating (5-row lists, names/counts only, contact values never returned), the reasons/failed/gaps output structure, and the default 'family capital only' scope. This is exactly the extra disclosure annotations cannot carry.

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?

Front-loaded with the core purpose and mostly dense with signal; the filter semantics and access rules each earn their sentence. The trailing sales line ('Full access: DFX Intelligence, 7 days free at...') is promotional filler that does not help an agent invoke the tool correctly.

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 highly complex 35-param tool with no output schema, the description supplies the missing return-value contract (reasons/failed/gaps, envelope coverage counts, entitlement/locked) and the filter model. An agent has what it needs to call it and interpret results without a 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?

With 35 params at 54% schema coverage, the description compensates well conceptually: it explains require as hard filters, prefer as making geography soft, geography/class as default hard filters, and gives canonical industry codes. It still leaves a number of individual params (contact_tier, min_identity_confidence, counterparty_min) unexplained in prose, so it does not fully close the coverage gap.

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?

Opens with a specific verb+resource claim ('THE tool for any family office question with criteria') and enumerates the criteria dimensions it ranks on. It is clearly distinguishable from siblings like search_family_offices and get_family_office, which fetch rather than rank against a buyer's weighted criteria.

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?

States the selection condition clearly ('any family office question with criteria') and defines the hard-vs-soft filter model plus the role of require and prefer. It does not explicitly name the alternative sibling tools (search_family_offices, explain_match) or state when NOT to use it, so it falls short of the full when/when-not/alternatives bar.

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