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

Goes well beyond the annotations by disclosing the exact entitlement behavior: without a paid plan a list returns only its first 5 rows plus locked.count/locked.by_type, a record exposes its subject and first 3 related names per section, contact values and decision-maker names are never returned, and every answer reports what it withheld via `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?

Front-loaded with the purpose, then the precondition, then the entitlement mechanics — a sensible order for a dense, high-complexity tool. It is long but mostly load-bearing, with the trailing paid-plan promo link being the one sentence that does not help an agent invoke the tool.

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 does the work of explaining return shape (list vs record, per-section truncation, locked counts, entitlement reporting) and input requirements. It is close to complete, missing only guidance on the `limit` parameter.

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 only 33%; the description reinforces that an entity or event id is required and maps entity types to id families, though much of that already lives in the dfx_id schema description. The `limit` parameter and its default/max are never mentioned in the description, leaving a real 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?

States a specific capability — given an entity or event id, return the economic counterparties likely to care and why — with per-entity-type examples (company → sponsors/capital providers/family offices; family office → co-investors; property → owner/lender). This operationally distinguishes it from siblings like relationship_path, who_to_contact, and who_should_provider_call.

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 a hard precondition ('Needs an entity or event id; a description of a situation without an id is not accepted') and shows expected inputs and outputs per entity type. It does not, however, name sibling alternatives or state when a different tool would be the better choice.

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