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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the closing 'Read-only' is redundant, but the description adds genuinely new behavior: the result is empty when the investor is not yet in the pool. That empty-state contract is the kind of context annotations cannot express and helps an agent interpret a null response.

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?

A single tight sentence: resource first, then the empty-state caveat, then the safety cue. No filler, no repetition of the title, and the most decision-relevant detail (empty when not in the pool) is not buried.

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 and annotations covering the read-only safety profile, the description only needs to explain the non-obvious empty case, which it does. What is missing is any hint of how to obtain the pool profile when empty (add_pool_investor_to_raise / search_investor_pool) or any relationship to the partner-profile sibling.

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?

Only one parameter (relationshipId, a UUID wrapper) and schema description coverage is 100%, so the schema already does the work. The description adds no meaning about which relationship identifier is expected or whether it must reference an existing fundraising relationship; baseline 3 applies.

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 the specific resource returned (the shared public profile a relationship's investor is linked to) plus the research timestamp. It is clear about what is fetched but never distinguishes itself from the near-identical sibling fundraising_get_relationship_partner_profile, so sibling differentiation is only implicit via the 'pool' framing.

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?

'empty when the investor is not in the pool yet' implies the precondition (investor must exist in the pool) and the empty-result case. However, no explicit when-to-use guidance and no naming of alternatives such as fundraising_get_pool_investor, fundraising_search_investor_pool, or fundraising_get_relationship_partner_profile.

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