slowave_commit

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains several behavioral aspects: it closes the session, triggers memory consolidation, filters out lifecycle bookkeeping entries (and reports the count as trajectory_lifecycle_filtered), and handles already-ended sessions (returning already_ended=true). It also specifies constraints on the trajectory (must contain only TASK actions/observations, max 32 entries) and the condition to omit trajectory if no task-level actions. This is comprehensive and goes beyond what a typical description provides, even with annotations.

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 long but well-structured with clear sections for Args, Returns, and usage guidance. It front-loads the core purpose and usage timing ('Call at the end of every task') before detailing parameters. While it is detailed, every sentence adds value, such as the warning about not including lifecycle bookkeeping. It could be slightly more concise by trimming some redundant phrasing, but the structure aids readability.

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?

Given the complexity of the tool (7 params, nested objects, output schema), the description is thorough. It covers all parameters, their requiredness, allowed enums, constraints (max 32 trajectory entries), and the filtering behavior for lifecycle entries. It also provides comprehensive return field descriptions, which is helpful even though an output schema exists. The absence of details on authentication or rate limits is acceptable since no annotations suggest these are needed, and the tool appears to be a session closure operation. Overall, an agent has enough information to correctly construct the arguments and understand the response.

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 for param semantics. The description provides detailed explanations for each parameter: session_id (required active session from activate), final_goal (required confirmed goal), outcome (required success|partial|failure), outcome_summary (required standalone actual result), verification (required {status, summary, evidence_refs?} with status enum), procedure (optional with version 2 and structure), and trajectory (optional with constraints on content and length). It adds meaning beyond the schema by specifying the source of session_id and the 'confirmed' aspect of final_goal, and by clarifying that procedure is only for reusable methods actually attempted. This is strong compensation for the lack of schema descriptions.

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 the tool's function: close the current task and trigger offline memory consolidation. It uses a specific verb ('close') and resource ('task'), and it distinguishes itself from siblings by emphasizing the end-of-task lifecycle action, which is unique among the listed sibling tools (activate, recall, remember, feedback).

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?

The description explicitly states when to use this tool: 'Call at the end of every task.' It also provides a clear alternative consequence if skipped (the idle-session reaper closes the session after a timeout), which implies that this tool should be used to avoid that automatic closure. No sibling tool is suggested as an alternative, but the usage context is unambiguous.

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