List what waits for the person's keep

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

Annotations already cover read-only, idempotent, non-destructive, closed-world, so the bar is low; the description still adds real behavior – that the call is non-blocking, that unanswered notes are not lost, and that a Sentinel-held note returns only its alert rather than its body. That last caveat is a genuine edge case an agent could otherwise get wrong.

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?

Purpose is front-loaded and there is little outright filler, but the metaphorical register ('the one line to say about them', 'the person's keep') costs tokens without adding precision. Two of the three sentences do real work; the framing sentence does not.

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 single-param, read-only, no-output-schema tool, the definition covers return shape (note body, provenance, the 'staged · not yet Memory' label) and the Sentinel exception, which is what an agent needs to call and interpret it. Only the sibling boundary is absent.

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 100% and already defines the id/last-8-characters format, so the baseline is 3. The description goes further by explaining what supplying the id actually yields – the full body plus provenance – which is semantic meaning the schema does not convey.

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 core is decipherable – it lists staged notes that nobody has answered yet – but it is wrapped in in-group metaphor ('the person's keep', 'Sentinel', 'staged · not yet Memory') that an agent unfamiliar with this vocabulary must reverse-engineer. It does not name any of the siblings (retrieve, keep, stage) to draw the boundary, so differentiation is inferred rather than stated.

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?

Timing is unusually explicit: 'at a pause, at the end of your own turn, never mid-work', plus the reassurance that 'later, or no answer, is fine: nothing blocks and nothing is lost.' What's missing is routing against alternatives such as retrieve, but the when-to-call guidance itself is concrete.

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