Delete a specified block from SiYuan knowledge base to clean up erroneous or unwanted content. Confirm the block ID before calling, as the action is permanent.
删除指定块。
适用场景: - 清理错误插入或不再需要的块。
注意事项: - 删除操作具破坏性，调用前建议先用查询工具确认 block_id。 - 返回值包含操作记录，可用于审计本次删除结果。
| Name | Required | Description | Default |
|---|---|---|---|
| block_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.31.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose that the delete operation is destructive and that the return value contains an operation record for audit purposes. It omits details like permission requirements or cascade effects, but the essential destructive behavior is clearly communicated.
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 description is concise, front-loads the main action, and uses clear bullets for scenarios and cautions. Each section earns its place: purpose, applicable scenario, and safety/audit notes. There is no filler or repetition.
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 simple one-parameter destructive tool, the description covers the core decision of when to use it, warns about destructiveness, recommends pre-delete verification, and mentions the auditability of results. Since an output schema is present, not detailing the return structure is acceptable. Missing permission details or explicit alternatives would strengthen it further.
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 0%, so the description should compensate for the parameter. It only mentions block_id indirectly by recommending verification before deletion, which adds minimal context. The parameter is self-named and obvious from the delete context, but the description does not add format, constraints, or source guidance beyond the schema's string type.
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 states '删除指定块' (delete the specified block), giving a specific verb and resource. It also provides the intended scenario—cleaning up incorrectly inserted or unneeded blocks—which clearly distinguishes it from sibling tools like update_block, insert_block, or move_block.
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 description explicitly says when to use the tool: for cleaning up incorrectly inserted or unneeded blocks. It also advises confirming block_id with a query tool before deleting, which gives practical usage guidance. It does not name specific alternative tools or state when not to use it, so it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.