annotate_sessionAdd or remove tags and set a human summary on a conversation session to feed the retrieval index. This edits session metadata only and leaves the original dialogue content unchanged.
为会话添加/移除标签、设置人工摘要（进入检索索引）。这是元数据编辑，不改写对话内容
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | 项目根绝对路径。仅当服务端提示 unresolved_project（多项目/未自动识别）时选择传此参；传一次后本连接记住 | |
| summary | No | 人工摘要（覆盖旧值；会成为权威摘要层） | |
| add_tags | No | ||
| session_id | Yes | 会话 ID（支持前缀） | |
| remove_tags | No |
Changes observed during successful MCP inspections.
v0.6.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose two valuable traits: this is metadata-only editing that does not rewrite conversation content, and the summary enters the retrieval index. It says nothing about permissions, failure modes, or whether tag removal is reversible.
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?
Two short sentences, front-loaded with the actionable operations, then a clarifying scope statement. Nothing is wasted or buried.
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 5-parameter mutation tool with no annotations and no output schema, the description covers the essential behavior and the critical non-destructive guarantee. Remaining gaps (return values, error handling on unresolved sessions) are partially mitigated by the schema's project description.
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 60%, with project, summary, and session_id documented in the schema (including prefix support and the unresolved_project condition). The description adds the fact that add_tags/remove_tags exist and that the summary is indexed, but the two tag array parameters remain undocumented beyond their names.
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 concrete operations on a specific resource: adding/removing tags and setting a human summary on a session. This is far more specific than a bare verb, though it does not explicitly differentiate itself from siblings such as save_note.
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?
Usage is implied by the stated capabilities (want to tag or summarize → use this), but there is no explicit when-to-use/when-not or reference to an alternative tool. The agent must infer that this is the right tool versus save_note for annotation-like work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.