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

Annotations already establish readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds what those annotations cannot: the response includes a link to the Raziel guide or calculator, and the special "list" mode returns the full term set. It omits what happens for an unrecognized term.

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 two operational rules. The ~50-item parenthetical is long, but it earns its place by communicating exactly which terms will resolve; trimming it would cost coverage signal.

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?

For a single-param lookup with no output schema, the description covers what is returned (a definition plus a guide/calculator link), the list mode, and where to go for depth. The one real gap is unknown-term behavior, which an agent would want to know before calling.

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 100% and the schema's own description already documents the "list" escape hatch with examples, so the description's restatement adds little. The term enumeration indicates the accepted vocabulary (including abbreviations like 83(b) and 409A), but supplies no matching or normalization rules.

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 verb and resource ('Plain-English definition of a private-market, venture or fund term') and enumerates the exact term space covered, which lets an agent judge coverage without guessing. It also names search_guides as the sibling handle for longer explanations, so it is distinguishable from alternatives.

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 two concrete usage rules: pass "list" to enumerate every term, and use search_guides for longer explanations. It does not address the more likely confusion with the calculator siblings (pro_rata, qsbs, liquidation_preference, tvpi_dpi), which cover the same vocabulary but compute values rather than define them.

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