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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds the frequency contract (once per session, not per message) which is genuine behavioral guidance not encoded anywhere structured. It stops short of noting edge cases such as an empty/partial briefing for new users or approximate result size.

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 return contents are front-loaded before any usage instructions, and each of the four sentences carries distinct information: what it returns, its arity, its timing contract, and its sibling fallback. No filler or repetition of the title.

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 no output schema, the description compensates by enumerating the shape of the returned summary, and with no parameters there is nothing else to document. An agent has everything needed to decide when to call it and what to expect back.

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?

Zero parameters, so the baseline applies; 'Takes no arguments' explicitly confirms the empty schema, preventing an agent from hunting for optional filters. Little more could be said given there is nothing to parameterize.

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?

Uses a specific verb (returns) plus a precise resource (the user's standing background summary) and enumerates its contents: identity, preferences, relationships, recent work. This is clearly distinguishable from 'recall', which the description positions as the detail-level sibling.

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?

Gives explicit invocation timing ('call it once when a conversation opens, before answering'), an explicit exclusion ('not a per-message one'), secondary trigger conditions ('where things stand', 'what is next', 'continue earlier work'), and names the alternative for other cases. Timing, frequency, and sibling routing are all covered.

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