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

Annotations already declare readOnlyHint=true and destructiveHint=false, so 'Read-only' is somewhat redundant. But the description adds genuine behavioral context absent from the schema: the source-precedence chain, the from_pool true mark, the absence of a company part on pool results, and the empty-result case.

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?

Three tight clauses, front-loaded with the resource and its fallback logic, no filler. The telegraphic noun-phrase style is compact, though the leading fragment ('A relationship's partner profile:') lacks an explicit verb.

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 needn't be explained, and with only one parameter the schema stands alone. The description completes the picture with source precedence and empty-state behavior; only the sibling-differentiation gap keeps it below a 5.

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% with a single required relationshipId, so the schema carries parameter meaning. The description adds nothing about the parameter itself; 'from_pool true' describes an output field, not the input. 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?

Names the specific resource (a relationship's partner profile) and defines it precisely via a fallback: own research if stored, else the public pool profile, else empty. However it does not distinguish itself from the very similar sibling fundraising_get_relationship_pool_profile, so the agent must infer which profile getter to call.

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 fallback chain (own research -> pool profile -> empty) implies when this getter is appropriate, but there is no explicit 'use this when X, otherwise use pool_profile instead' guidance. For a tool that overlaps heavily with a named sibling, this omission matters.

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