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

Annotations already cover the read-only/idempotent safety profile, and the description goes well beyond by disclosing the inference caveat ('The need is inferred, never observed') and detailed entitlement behavior: unentitled lists return only the first 5 rows plus counts, records name a subject and 3 related names per section, contact values are never returned, and withheld data is reported in `entitlement` and `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?

The description is front-loaded with purpose, then a labeled 'ACCESS' block that earns its length given the non-obvious entitlement model. However, the closing marketing line ('Full access: DFX Intelligence, 7 days free at...') is promotional and does not help the 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?

With no output schema, the description carries the return-shape burden and does so reasonably, describing what a locked list returns (counts by type) and that answers self-report withheld data via `entitlement` and `locked`. It is close to complete for the access model, though the undocumented non-enum parameters leave some invocation uncertainty.

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 only 22% across 9 params, so the description must compensate. It does partially: it explains the trigger families via prose ('new advisers, fund Form Ds, next funds, open offerings, harvest...') and ties provider_type and trigger_family to an example. But limit, since, within_days, min_amount_usd, and trigger_kind remain unexplained in both schema and description, leaving meaningful gaps.

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 gives a precise verb and resource: 'Filed or announced triggers on the venture graph mapped to the service providers they create work for,' then enumerates the provider types (admin, audit, law, placement...) and trigger kinds. This is specific enough that an agent can distinguish it from siblings like search_vc_opportunities or search_forward_opportunities on the basis of the trigger-to-provider mapping alone.

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?

It provides concrete when-to-use examples tied to parameter combinations: 'new venture funds likely needing administrators' and 'companies that recently raised where venture debt may be relevant' (provider_type=lending, trigger_family=company_funding). Strong positive guidance, but it names no alternative sibling or when-not-to-use condition, 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.