Skip to main content
Glama
leolulu

siyuan-mcp-server

by leolulu

insert_block

Insert a new block at a precise position in SiYuan: before or after an existing block, or as a child of a parent block. Specify next_id, previous_id, or parent_id to control placement.

Instructions

插入块(next_id / previous_id / parent_id 至少提供一个)。

适用场景: - 需要按相邻块位置插入(前置/后置锚点)。 - 需要按父块插入(指定 parent_id)。

使用方法: - next_id: 插入到 next_id 对应块之前。 - previous_id: 插入到 previous_id 对应块之后。 - parent_id: 插入为 parent_id 的子块。 - 三者可同时提供,但思源 API 优先级为 next_id > previous_id > parent_id。

注意事项: - 如果你要"确保挂到某个标题(如 H3)下面",请显式传 parent_id, 或直接使用 append_block / prepend_block。 - 若 next_id/previous_id 与 parent_id 指向不同层级,最终位置会以 next_id/previous_id 优先,可能出现"看起来没挂到标题下"的情况。

与 prepend_block/append_block 的区别: - prepend_block/append_block 是"父块优先",强制挂到父块下(开头/末尾)。 - insert_block 是"相邻优先",依赖现有块的位置,可能产生层级歧义。

示例(假设现有结构:父块A -> 子块B -> 子块C): # 插入到 B 之后(中间插入) insert_block(data="新块", previous_id="block_b") # 结果:A -> B -> 新块 -> C

# 插入到 B 之前
insert_block(data="新块", next_id="block_b")
# 结果:A -> 新块 -> B -> C

# 作为 A 的子块插入(不推荐,可能被相邻锚点覆盖)
insert_block(data="新块", parent_id="block_a")
# 注意:若同时传了 previous_id/next_id,parent_id 会被忽略

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
next_idNo
data_typeNomarkdown
parent_idNo
previous_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.31.0

TDQS

A4.9/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 the next_id > previous_id > parent_id precedence, warns that parent_id can be silently ignored when adjacent anchors are provided, and flags the 'looks like it is not under the heading' pitfall. It also advises against relying on parent_id alone.

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

Conciseness5/5

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

The description is fully sectioned (scenarios, usage, cautions, sibling comparison, examples) and front-loads the core constraint that at least one anchor is required. The length is justified because every section adds information needed to invoke the tool safely and correctly.

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 nontrivial insertion tool with no annotations, the description covers the required anchor constraint, precedence rules, failure-prone scenarios, alternatives, and concrete examples. An output schema exists, so not describing return values is acceptable, and nothing essential for calling the tool correctly is missing.

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 does so for next_id, previous_id, and parent_id with clear 'insert before/after/child' semantics and examples. However, data_type is left undocumented (only its default 'markdown' appears in the schema), and data itself is only illustrated through examples rather than explicitly defined.

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 operation ('插入块' – insert a block) and immediately specifies the positional anchors (next_id/previous_id/parent_id). It also distinguishes itself from nearby siblings prepend_block/append_block, so an agent can separate it from them without opening any schemas.

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?

It gives explicit selection criteria: use insert_block for neighbor-relative or parent-based placement, and explicitly says to use append_block/prepend_block when the goal is to force a block under a heading. It also explains the API priority between conflicting anchors, leaving no ambiguity about when to choose it.

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