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

Annotations only cover the read/safe/idempotent profile; the description goes far beyond them by disclosing entitlement gating (first 5 rows in full plus locked.count and locked.by_type, never the rows), suppression of contact values and decision-maker names, and that every response self-reports in `entitlement` and `locked`. That is exactly the behavioral context an agent needs before promising data to a user.

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 dense but well ordered: chain contents first, then break-reporting, then access constraints, then the commercial pitch. Every sentence carries information except the closing '7 days free at https://...' call-to-action, which reads as promotion rather than tool documentation.

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 describing the return shape (named sections, locked counts by type, entitlement disclosure), which is substantial and sufficient for calling correctly. The only real gap is how `limit` interacts with the 5-row truncation under a locked entitlement.

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 0% for two parameters. The description compensates for `name` by adding real semantics (minimum length, refusal of ambiguous short strings like 'GS'), which the schema does not convey. But `limit` is never mentioned — its 1-50 bounds, default of 15, or its interaction with the 5-row lock are left entirely to the schema.

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 (retrieve by firm name family) and enumerates the exact sections returned — RE fund managers, vehicles by lifecycle, holdings with basis/confidence, fund loans and lender groups, CMBS sponsor/guarantor notes, and owner chains. That enumeration effectively separates it from single-section siblings like get_re_fund_manager, but no sibling is named explicitly, so the differentiation is implicit rather than stated.

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?

The input constraint (minimum 3 letters, 'GS' rejected as ambiguous) is a genuine usage rule, and 'Lists where the chain breaks' hints at the payoff. However, there is no guidance on when to prefer this full-chain view over get_re_property_chain, get_re_fund_manager, or the many search_* siblings — the agent must infer that itself.

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