update_session

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

The readOnlyHint=false annotation already marks this as a mutation tool. Beyond that, the description states what it mutates (state.json), discloses a non-obvious side effect (setting done also marks the linked TODO as done, todosDone), and explicitly says the conversation is untouched. It does not cover permissions, reversibility, or what a call returns.

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 purpose is front-loaded, and no sentence is padding. But the middle of the description becomes a run-on list joined by ・, mixing field names with behavioral rules about the TODO cascade, which makes it harder to scan. Splitting that list into short labeled clauses would improve it.

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 tool has 12 parameters, no output schema, and low schema coverage, so the description must do a lot. It covers status semantics and the done-to-TODO cascade well. But it remains silent about whether the update is partial or full, what state.json returns, and what the meaning of several parameters is, so the definition is not yet complete for a tool of this size.

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 only 25%, and the description explains 5 of the 12 parameters: status values (pending=保留, paused=手で止めた, paused_usage=利用枠で止めた), note, area, todo, and the via app case. That goes beyond the bare enum values. But cwd, name, model, effort, profile, remove, and the required threadId are left undefined in both the schema and the description, so the 25% coverage gap is not closed.

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 names a specific verb and target: rewrites the supervisor's record (state.json). It enumerates the fields that can be set (status, note, area, todo link) and closes with a sharp scope boundary, 「会話そのものには何もしない」, which distinguishes this tool from send_message and stop_session. It never names a same-purpose sibling such as set_session_name, so the differentiation is partial.

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 usage guidance only for one case: adding a desktop app conversation to management via the record value returned by start_session. It does not say when this tool is chosen instead of set_session_name (which might also set a name), how the tool relates to stop_session, or whether calls can be partial updates. The guidance is implied rather than stated.

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