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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: the result set includes a flag for whether each firm is already in the user's contacts, a separate cut of Equitest investors who accept introductions, and the explicit limitation that contact details are not included. It stops short of explaining result ordering, deduplication, or what happens when limit caps the match set.

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?

It is a single dense sentence, but the verb and data source lead, and every clause enumerates either a returned field or a scope limit rather than padding. The semicolon-delimited list is efficient, though splitting the return-field inventory from the scope statement would make it easier to scan.

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, the description correctly carries the burden of describing return fields (name, deal count, last deal, median deal size, buyer type, industries, recent deals) and the contact-detail exclusion. The filter surface is covered by the schema, so the remaining gap is only around result ordering and pagination behavior for limit.

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 86%, so the schema already documents naics, query, country, date_from, and the deal-size bounds; the description only echoes 'median deal size (USD millions)' and the industry concept. It adds no guidance on how naics and query combine, how country interacts with the target description, or how limit truncates results. Baseline 3 is appropriate when the schema does the heavy lifting.

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 names a specific verb (finds) and a specific resource (investors and acquirers active in an industry), plus the data source (Equitest's M&A transactions) and the exact fields returned. It implicitly separates itself from list_investor_contacts by noting the 'already in the user's investor contacts' flag and from send_to_investors by noting which investors 'accept introductions'. An agent can tell what this does without opening the schema.

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 implied rather than stated: the phrase 'active in an industry' and 'match the filters' suggests this is the discovery/search entry point, but the description never says when to prefer it over list_investor_contacts, search_ma_comparables, or send_to_investors, and gives no prerequisites or exclusions. The comparisons with siblings are inferable but not explicit.

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