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

With annotations only declaring readOnlyHint=false and openWorldHint=true, the description carries real behavioral load: the server runs hybrid search over the description, short descriptions trigger a recency fallback, references are resolved by UUID or best-effort phrase search, and the response exposes resolution status for retries. That is exactly the kind of side-effect and fallback detail an agent needs before writing.

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?

Front-loaded with the core purpose and broken into scannable blocks for reference syntax, the pointer to checkpoint_protocol, and args. Slight redundancy: the references_resolved/unresolved_references behavior is stated twice (in the reference paragraph and again under Returns), which costs it a point.

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 two-parameter write tool, the description covers purpose, fallback behavior, reference syntax, failure/retry path, and where to find deeper protocol guidance. The output schema exists, so the short Returns block is a bonus rather than a gap.

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 0%, so the description must compensate, and it does: 'name' is identified as the unique key consumed by restore_context, and 'description' is explained as the primary payload with its own micro-syntax for memory references. The ctx parameter is noted as automatically provided.

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?

States a specific verb+resource ('Save a cognitive checkpoint') and defines the concept as handoff material for another agent or a future self, which separates it from store/update_memory in spirit. It does not explicitly contrast itself with close siblings like save_artifact, so it stops short of a 5.

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 concrete conditional guidance: use a substantive description because it is the search query, and a description under 3 words falls back to the 20 most recent memories; prefer UUID references over phrases; retry via references_resolved/unresolved_references. It also routes the agent to the checkpoint_protocol prompt for the hygiene guide and when-to-checkpoint rules, though it never states when to prefer this over save_artifact.

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