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

Annotations only cover read-only/idempotent/non-destructive, which is the low bar; the description goes well past that by disclosing entitlement gating in detail: 5-row lists with locked.count/by_type, record-level truncation to 3 related names, permanent suppression of contact values and decision-maker names, and the presence of `entitlement`/`locked` in every answer. It also explicitly states what addresses. This is exactly the off-schema behaviour an agent needs to avoid misreading partial 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?

The card-contents and access paragraphs are dense and front-loaded, but the closing sales line ('Full access: DFX Intelligence, 7 days free at...') is promotional padding that does not help tool selection. The middle section is a run-on list that takes effort to parse.

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 and 12 parameters, the description compensates well on the response side by describing card fields, exclusions and entitlement truncation. It is thinner on the request side, never explaining sort, limit, min_investments or recent_activity_days, so it is strong but not fully complete.

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 33% (city, sort, limit, query, min_investments, recent_activity_days and emerging_manager are undocumented). The description does map several filters (sector, stage, state, active/raising, emerging manager) and echoes the observed-vs-stated sector matching, but leaves sort, limit and min_investments semantics entirely to the schema. Baseline 3 is appropriate.

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 verb+resource (search venture capital firms) and precisely enumerates what a result card carries: stated sector/stage/geography/check size, observed behaviour over 6/12 months, funds with vintage and Form D, people counts. It also draws a boundary ('Funds, people and individual deals are not on these cards'), which helps separate it from get_vc_firm and search_vc_funds. It stops short of naming siblings in the body text, so it lands at 4 rather than 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 only implied through the filter list (sector, stage, state, active/raising, emerging manager) and one routing hint buried in the schema ('For a ranked answer to a raise... use find_vc_investors'). The description body never explicitly states when to choose this over search_vc_funds, search_vc_investments or find_vc_investors.

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