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

Beyond the sparse annotations (openWorldHint=false, destructiveHint=false), the description discloses the hard validation rule (entries without a quote are refused), the quote-versus-interpretation separation requirement and why, the limitations obligation, and that quotes are screened for injected instructions with unscreened recorded as a distinct verdict. These are non-obvious behavioral constraints an agent could not get from the structured fields.

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?

Purpose is front-loaded and each sentence does assert a rule, but the prose is ornate and repetitive in places ('the failure this prevents is a founder repeating your inference...'), and it arrives as one undifferentiated block without grouping of entry rules versus prep-field rules.

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?

An output schema exists, so return values need no explanation, and the evidence/screening rules are well covered. However, for a 17-parameter mutation at 12% schema coverage, the complete silence on the meeting-prep fields (agenda, toAsk, toProve, pitchSummary, nextObjective, openingBridge, avoidRepeating) leaves the agent without enough to populate most of the payload correctly.

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 12% across 17 parameters, so the description carries real weight: it explains the semantics of quote, interpretation, limitations, and the screened flag inside entries. But a large block of top-level fields — agenda, toAsk, toProve, toAnswer, pitchSummary, nextObjective, openingBridge, avoidRepeating, confidence — is never mentioned anywhere, leaving the agent to guess their intent.

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 states a specific verb and resource: proposes a per-investor relationship memory accumulated across all calls, with what was signalled, pushed on, and still owed an answer. The closing line 'This proposes only... when they approve it' distinguishes it from fundraising_approve_relationship_memory, though no sibling is named explicitly.

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 propose-versus-approve boundary is implied by 'This proposes only' and 'when they approve it,' but the description never tells the agent when to call this instead of related siblings such as fundraising_capture_what_was_said or fundraising_get_relationship_memory. Usage is inferable from narrative context rather than stated.

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