Skip to main content
Glama
leolulu

siyuan-mcp-server

by leolulu

move_block

Move existing blocks in SiYuan to reorder them or change parent-child relationships. Specify previous_id for ordering or parent_id for nesting, preserving related content by moving block groups.

Instructions

移动块(previous_id / parent_id 至少提供一个)。

适用场景: - 调整块顺序(基于 previous_id 锚点)。 - 调整父子归属(基于 parent_id)。 - 调整分节或层级结构时,保持相关内容整体移动。

使用方法: - previous_id: 把 block_id 移动到 previous_id 之后。 - parent_id: 把 block_id 移动到 parent_id 之下。 - allow_heading_only_move: 兼容旧参数,已废弃;传 true 会报错。

注意事项: - 若 block_id 是标题块(h1-h6),将按“分节范围”移动: 从该标题开始,直到下一个同级或更高级标题(level <= 当前 level)之前的所有块一起移动。 - 其他块默认按“子树块组”移动:目标块 + 全部后代,避免父块与子块脱离。 - 思源 API 对同传 previous_id 和 parent_id 时会优先 previous_id。 - previous_id / parent_id 不能指向正在移动的子树内部块。

与 insert_block 的区别: - insert_block 是插入一个新块。 - move_block 是移动已有块的位置。

安全建议(重要): - 不做“单块父节点移动”,统一执行整组移动,避免父块与内容脱离。 - 若目标是“稳定挂到某个父块”,优先提供 parent_id。

示例(假设现有结构:父块A -> 子块B -> 子块C -> 子块D): # 调整顺序:移动 C 到 B 之后(不改变层级) move_block(block_id="block_c", previous_id="block_b") # 结果:A -> B -> C -> D(顺序不变,因为 C 原本就在 B 之后)

# 调整层级:移动 C 成为 B 的子块
move_block(block_id="block_c", parent_id="block_b")
# 结果:A -> B -> C(现在 C 是 B 的子块)-> D

# 同时调整顺序和层级
move_block(block_id="block_c", previous_id="block_b", parent_id="block_a")
# 注意:API 会优先处理 previous_id,parent_id 可能被忽略

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
block_idYes
parent_idNo
previous_idNo
allow_heading_only_moveNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.31.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it delivers: it discloses section-range movement for headings, subtree group movement for non-headings, the API priority rule when both previous_id and parent_id are passed, the deprecation error on allow_heading_only_move=true, and the restriction that anchors cannot point inside the moving subtree. No annotation contradiction since no annotations exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-organized with clear sections and the key constraint (previous_id/parent_id at least one) front-loaded. However, it is long and somewhat redundant: the group-move safety advice appears three times (notes, safety suggestions, and parameter guidance), and the worked examples are verbose relative to their illustrative value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 0% schema coverage and no annotations, the description is complete: purpose, scenarios, parameter behavior, edge cases (heading section range, subtree grouping), precedence rules, failure constraints, sibling distinction, and safety guidance are all present. Return values need no explanation because an output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides plain-language semantics for previous_id (move after anchor), parent_id (move under parent), and allow_heading_only_move (deprecated, errors if true), plus worked examples showing block_id usage. The only gap is that block_id is not explicitly defined as 'the block to move' in prose, though the examples make it clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (move an existing block) and resource (block position/hierarchy), and explicitly differentiates from insert_block by contrasting 'insert new block' vs 'move existing block'. It also distinguishes two movement modes (order via previous_id, hierarchy via parent_id), which disambiguates it from sibling tools like prepend_block and append_block.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Has an explicit '适用场景' section listing when to use it (adjust order, adjust parent-child, adjust section/hierarchy), parameter-level guidance for when to supply previous_id vs parent_id, and a dedicated 'difference from insert_block' section naming the alternative and its distinguishing condition. Safety advice even recommends preferring parent_id for stable parent attachment.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.