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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond that: entity resolution to the firm group, exclusion of the firm's own funds/group members/aliases, and a precise account of what a free-tier response withholds (locked.count, locked.by_type, contact values never returned) and where that is disclosed (entitlement, locked).

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-loads the returned content before the access caveats, and each clause is informative. The closing promotional line ('Full access: DFX Intelligence, 7 days free at ...') is partly justified as entitlement disclosure but is wordier than the functional content requires.

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?

There is no output schema, so the description carries the return-value burden and does so: shared portfolio companies, shared rounds, first/last shared dates, stages, leadership, sample companies, plus the locked/entitlement shape. An agent has enough to call it and interpret the response.

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 75%, so the schema already documents firm, dfx_id and since. The description's 'Give the firm's name or its dfx:vc: id' largely restates the schema descriptions and adds only the resolution-to-firm-group nuance; limit and since semantics are left 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 resource and relationship ('firms that invest most often beside a named venture firm') plus the exact basis (rounds both were named on) and the fields returned. This is clearly distinct from siblings like search_vc_investments or find_vc_investors, which cover investments or investors rather than the co-investment pair relationship.

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?

Gives concrete invocation examples ('who co-invests with Bessemer', 'frequent co-investors of a16z') and input guidance ('Give the firm's name or its dfx:vc: id'). It does not say when NOT to use it or name a specific alternative sibling, so it stops short of a 5.

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