Restores a knowledge base from a tar.gz backup created by kb_export, overwriting existing files with the same names. Returns the number of files restored.
从 kb_export 生成的 tar.gz 备份恢复知识库（同名文件覆盖）。
入参：backup_path，备份文件的绝对路径或相对项目根目录的路径。 返回：恢复结果文本（含恢复的文件数）。 下一步：kb_list 确认恢复结果，kb_search 抽查具体内容。
| Name | Required | Description | Default |
|---|---|---|---|
| backup_path | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v2.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the load and does disclose the key destructive trait — same-name files are overwritten — plus the expected return (restore result text with file count). It omits error/partial-restore behavior and any auth or path-existence requirements.
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?
Front-loaded statement of purpose followed by clearly labeled sections (入参/返回/下一步). Every line earns its place and nothing is padded.
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 a single required parameter, an output schema that covers the return shape, and no annotations, the description supplies purpose, overwrite semantics, path semantics, and next steps — nothing essential is missing for correct invocation.
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 0%, so the description must compensate, and it does: backup_path is explained as an absolute path or a path relative to the project root. That exceeds the bare 'Backup Path' title, though no format/validation detail is added.
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?
States a specific verb+resource (从备份恢复知识库) and names kb_export as the counterpart that produces the input, so an agent can immediately tell this is the inverse of export rather than a sibling like kb_write.
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?
Clearly frames the use case as restoring from a kb_export tar.gz and names follow-up tools (kb_list to verify, kb_search to spot-check). It does not state explicit exclusions (e.g. when to prefer kb_write instead), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.