memory_dream

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

With destructiveHint=true and non-idempotent already declared, the description still adds real substance: which action is read-only (status), that deep snapshots graph tables before writing, that rollback reverts facts and events while keeping traces/cursor, and that list results are capped with full counts in 'truncated'. It does not cover auth requirements or concurrency/rate behavior, so it stops short of a 5.

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?

Strong front-loading: the one-line purpose precedes a tidy action-indexed list, and each bullet earns its place by pairing an action with its workflow consequence. Minor deduction for the dense wrapping and for the action list omitting 'commit', which forces the reader to reconstruct it from the pull bullet and the commit_token parameter.

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?

An output schema exists, so the terse 'Returns: per-action dict; {error} on bad input' is sufficient. For a 7-parameter, destructive, multi-mode tool, the per-action map covers most what an agent needs, but the enumerated 'commit' action is never given its own entry, leaving one mode described only indirectly.

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 86%, so the schema already documents apply, limit, run_id, snippets, cursor and commit_token with per-action context. The description largely mirrors that (dry-run apply, pull default of 40), adding only marginal framing such as the pull-then-commit token flow. Baseline 3 is appropriate when the schema carries the load.

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 opening sentence gives a specific verb and resource ('consolidation of recent memories into canonical facts and graph structure'), and the per-action breakdown makes each mode legible. It falls short of a 5 only because it never distinguishes itself from close siblings such as memory_consolidate and memory_consolidation_candidates, which an agent must disambiguate on its own.

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?

Each action carries contextual guidance: 'status' is read-only backlog inspection, 'pull' is for unconsolidated memories with an explicit follow-up chain (memory_fact_set then commit), 'deep' is a dry run unless apply and routes candidates to memory_graph_review. What's missing is any when-not guidance or explicit comparison against the sibling consolidation tools.

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