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

Beyond the annotations (which already establish read-only/safe), the description adds real behavioral context: the record bundles quoted signals with their meeting and timestamp, separates interpretation from verbatim quotes, and flags that the limitations section states what the record could not see. The proposed-vs-current distinction further warns the agent that some returned data may be unconfirmed. It does not cover freshness, pagination, or volume, keeping it below a 5.

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 core is front-loaded in the first sentence, which is good, but that sentence is an overstuffed list of abstractions and the closing "Read-only." is a fragment that duplicates the annotation. Line length and metaphor cost more than they earn.

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 an output schema present, the description needn't enumerate return fields, and it correctly focuses on the caveats an agent needs: limitation disclosure and the proposed/current version distinction. Only the absence of any sibling routing keeps it from being fully complete.

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 100%, so both required UUID wrappers are documented in the schema and the description need only stay out of the way. It adds no meaning about what a relationshipId versus companyId scopes, which is the baseline-3 outcome when the schema already does the work.

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 conveys the resource (accumulated memory about one investor across calls) but does so in dense, figurative language — "the reading kept apart from the words," "what to walk into the next meeting able to prove" — that obscures the concrete payload. It never names the obvious siblings (fundraising_get_relationship, fundraising_approve_relationship_memory, fundraising_propose_relationship_memory), so an agent cannot cleanly disambiguate from the name 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?

"Read the limitations before you rely on any of it" is a genuine usage instruction, and the proposed-vs-current sentence tells the agent how to interpret stale records. However, there is no explicit when-to-use/when-not-to-use framing and no routing to alternative tools for different views of the same relationship.

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