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

With zero annotations, the description carries the full burden and does substantial work: it discloses that the server does not judge the draft, that only [ev:id] existence is validated (verdict=revise + invalid_ids and nothing saved on failure), that the turn is saved and a seal returned which must be appended, and that compact mode is saved-but-not-echoed. Remaining gaps are failure modes outside the [ev:id] check and any concurrency/duplicate-call behavior.

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 imperative cadence, but the body is a dense run-on of arrows, aliases, and undefined jargon (cubes, seal, L2/L1, missed_turns duty). Several clauses pack multiple rules with no structural separation, making it easy to miss a constraint on a single read.

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?

It usefully describes the return shape (facts, cubes, self_check, verdict, seal) despite there being no output schema, and it explains the draft-check loop. But for a 23-parameter mutation tool with no annotations and no output schema, leaving most parameters and several internal concepts unexplained is a real completeness 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 coverage is 0% across 23 parameters, so the description must compensate and largely does not. It gives real meaning to only draft/answer, compact, recap, and user_message; roughly 19 parameters (duty, duty_reason, lines, query, msg_ref, profile, profile_review, verbose, critical, event_id, sensitive, task_done, l1_summary, l2_summary, session_id, second_look, draft_summary, source_event_ids) are never mentioned. It also references cubes/self_check/cubes_version/checklist_version, which do not appear in the schema at all.

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 states a specific action and timing: call turn(user_message, draft) before the user sees the reply, and it explains the return payload (memory facts with [ev:id], relevant cubes, a self_check list). It also distinguishes itself from memory_search/memory_event/memory_dig by naming those as the deeper-dig path. It loses a point only because the opening is a protocol slogan rather than a plain statement of what the tool is for.

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?

Explicit invocation cadence (EVERY TURN, ONE CALL), an explicit no-draft variant (context only), and an explicit routing rule to siblings when memory is missing or the user asks to remember. What is absent is guidance on when the tool must NOT be used or how it interacts with retries/turn boundaries beyond the same-user_message note.

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