Skip to main content
Glama
Miles1994

siyuan-note-mcp

by Miles1994

Insert block

insert_block

Append Markdown content as new blocks inside a parent block or document, or directly after a specified block, to add notes in SiYuan via MCP.

Instructions

Append Markdown as new blocks. With parent_id the content is appended inside that block (use a document ID to append to a document); with previous_id it is inserted directly after that block. Provide exactly one of them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesMarkdown content to insert.
parent_idNoParent block/document ID to append into.
previous_idNoInsert immediately after this block ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden: it discloses the two insertion modes and the exactly-one constraint, which is useful. However it says nothing about write permissions, behavior on invalid/missing IDs, or the response, leaving meaningful behavioral gaps for a mutation tool.

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?

Two tight sentences; the core action is front-loaded and each clause (parent_id, previous_id, exclusivity) earns its place with no filler.

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

Completeness4/5

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

For a simple 3-param tool with no annotations and no output schema, the description covers the essential operation and placement semantics. Only secondary details (permissions, error/response behavior) are absent, which is a minor gap.

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 coverage is 100%, so the baseline is 3, but the description adds value beyond the schema by explaining the semantic relationship between parent_id and previous_id and the 'exactly one' exclusivity rule, which the per-field schema descriptions do not express.

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

Purpose4/5

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

States a specific verb+resource (append Markdown as new blocks) and disambiguates the two placement modes. It clearly differs from update_block/delete_block/get_block by operation type, but names no sibling explicitly, so it falls just short of 5.

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

Usage Guidelines4/5

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

Gives concrete invocation guidance: parent_id appends inside a block (document ID for documents), previous_id inserts after a block, and 'provide exactly one of them' states the mutual-exclusion rule. It covers how to use the tool but offers no comparison to alternative insertion/edit siblings.

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