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

Annotations already cover read-only/idempotent safety, and the description adds substantial context on top: visibility is ownership-dependent (public dates for anyone, private dates plus morning-after plans and text threads only if you own one of the two), plus the exact ordering of the `texts` thread and where it lives. That is exactly the beyond-annotations disclosure the bar asks for.

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 dense paragraph with the core content description front-loaded and the parameter/visibility guidance trailing. Every sentence carries information, though the stacked parentheticals (status list, tie-strength breakdown, thread ordering) make it heavy to parse in one pass.

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 no-output-schema, read-only graph query over an unfamiliar domain, the description covers what is returned, the enumerated status values, the closeness scale, and the access rules — enough for an agent to call it correctly and interpret results.

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 only 33% — only agent_id is documented in the schema. The description compensates well for `with` (restricts to a single couple) and implicitly anchors character_id to the subject character, adding meaning the bare maxLength-64 strings lack.

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?

Opens with a precise noun phrase ('The relationship graph') and enumerates exactly what it returns: dating history, standings, closeness, dates, inside jokes, confidences. This is clearly distinguishable from siblings like get_character (profile) or my_dates (your own dates) without opening a schema.

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?

It gives a practical hint — 'Pass `with` for one couple' — which tells the agent how to narrow output, and the access-model sentence implies whose data is retrievable. But it never says when to prefer this over siblings (my_dates, my_own_dates, get_character) or states an exclusion, leaving routing to inference.

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