release_quarantineReleases quarantined imported session content into the local memory store after user confirmation, making reviewed conversations retrievable.
把隔离导入的会话正文放行入库（用户确认后使用）
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | 项目根绝对路径。仅当服务端提示 unresolved_project（多项目/未自动识别）时选择传此参；传一次后本连接记住 | |
| session_id_prefix | Yes |
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 things that are not in the schema. First, it is a mutation that writes content into the store (入库). Second, it requires prior user confirmation. However, it says nothing about whether release is reversible, what happens to the quarantine entry afterward, or what happens if no session matches the prefix.
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 definition is a single compact sentence with the action front-loaded and the key constraint attached in parentheses. It wastes no words, though it is on the thin side for a mutation tool.
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 write tool with no annotations and no output schema, the description is too sparse. It omits the ambiguous-match behavior, which the prefix parameter makes likely; the failure modes; and the effect on the quarantine state. The schema hints that resolved project context may be required, but the description does not explain this.
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 only 50%, and the description does not mention either parameter. The 'project' parameter is documented in the schema. But 'session_id_prefix' has no description anywhere, so the agent must guess whether the tool accepts a prefix, a match rule for multiple matches, and whether it is exact. The description does not compensate for this gap.
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 action on a specific resource: it releases the body text of quarantined imported sessions into the library (放行入库). This is distinguishable from its siblings (import_handoff, export_handoff, list_sessions), which neither quarantine nor release content. However, it does not explicitly connect the tool to the 'quarantine' concept it shares with the import flow, beyond the words 隔离导入.
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 parenthetical '(用户确认后使用)' gives a concrete usage hint: call only after the user has confirmed. It does not say when not to use it, what the state before release must be, or how it relates to import_handoff. Therefore, usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.