export_handoffExport a portable handoff package (.hop with SHA-256 integrity and default redaction) or HANDOFF.md from the current project scope to transfer session context safely between agents.
生成 .hop 交接包（sha256 完整性 + 默认脱敏）或 HANDOFF.md。默认尊重当前 scope
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | 忽略 scope 导出全库 | |
| format | No | hop | |
| output | No | 输出绝对路径（缺省在项目根） | |
| project | No | 项目根绝对路径。仅当服务端提示 unresolved_project（多项目/未自动识别）时选择传此参；传一次后本连接记住 | |
| decisions_only | No |
Changes observed during successful MCP inspections.
v0.6.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but does deliver real behavioral facts: sha256 integrity, default redaction (脱敏), and scope-respecting defaults. It omits what happens on file overwrite, whether the export is a write to disk with permissions implications, and what the caller gets back — meaningful gaps for a file-producing tool.
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?
A single compact sentence that front-loads the two output artifacts and then the behavioral qualifiers. Little waste, though the parenthetical detail is dense and would read better separated.
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, no-annotation, no-output-schema export tool, the description covers format, integrity, redaction and scope default reasonably well. But it leaves `decisions_only` unexplained and, absent an output schema, does not say what path or confirmation the caller receives.
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% and the description only reinforces what the schema already says about scope defaults and the hop/markdown choice. `decisions_only` is undocumented in both schema and description, which is the clearest semantic gap; baseline 3 for mid coverage.
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 the concrete artifacts produced (.hop handoff package vs HANDOFF.md) and their key properties (sha256 integrity, default redaction), so an agent knows exactly what the tool does. It does not explicitly contrast itself with the inverse sibling import_handoff, which keeps it below a 5.
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 phrase '默认尊重当前 scope' implies usage context — use it as-is for the current scope, pass `all` for the whole library — but the tool never states when to choose it over import_handoff or when a handoff is warranted. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.