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

With no annotations, the description carries the behavioral burden. It discloses the output ordering (oldest-first), the fact that it returns a new opaque cursor, and the limitation that it is not a full checkpoint. It implies a read operation (returns delta), but does not explicitly state read-only or describe side effects. It adds useful context beyond the schema (e.g., resume-handoff, current-truth), so it is strong but not perfect.

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 description is three sentences, front-loaded with the core purpose. It packs a clear purpose, return behavior, usage guidance, and a limitation without any fluff. Every sentence contributes to orientation or selection.

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?

The presence of an output schema covers return format. The description covers why and when to use the tool, plus a key limitation. It does not explain the effect of filters (kind, repo, pillar) but those are fully documented in the schema. For a tool of this complexity, this is adequately complete, though it could mention that only memory_items are returned for pillar filtering, which is in the schema but not the description.

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%, so the baseline is 3. The description does not add semantic detail about individual parameters beyond what the schema already provides. It mentions 'opaque cursor' and 'current-truth' conceptually, but these are also covered in the schema descriptions. No extra value added.

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 clearly states a specific action: providing a resume-handoff delta of durable org memory since an opaque cursor, returning current-truth rows newer than the cursor. It explicitly distinguishes itself from memory_recall for keyword search, making its purpose unambiguous to an agent.

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 direct usage instruction: 'Use this to continue another session's work' and contrasts with 'use memory_recall for keyword search.' It also flags a limitation ('Not a full checkpoint/context pack'), telling the agent when not to use it. This is explicit and actionable.

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