Loading ToolBench
Model Context Protocol server for SiYuan Note - provides tools for searching, managing documents, snapshots, and tags in SiYuan Note
The SiYuan MCP server has 16 tools with basic naming conventions starting with action verbs (get_, create_, list_, etc.), but critical quality gaps significantly limit production readiness. All tools have descriptions, but many are under 100 characters and lack actionable context. Input schemas are present but vary in completeness, most parameters have types and descriptions, but output schemas are not documented. Error handling and recovery guidance are absent. The server does not implement tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite multiple destructive operations (delete, rollback, update). The composition of tools is reasonable (one concern per tool), but the lack of schema documentation and error guidance prevents confident LLM usage.
Append content to today's daily note
Append content to an existing document
Create a new document in a specified notebook
Create a new notebook
Create a data snapshot for backup and recovery
Get the Markdown content of a document by document ID
Get the document tree structure of a notebook
No output schemas documented. Tools return unstructured JSON/markdown, forcing LLMs to parse variable response formats. Downstream tool chains cannot be reliably composed. Example: get_document_content and get_document_tree return undocumented structures; create_document's return type is unknown, blocking immediate reference chaining.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server has multiple irreversible operations (rollback_snapshot, delete paths in move_documents, replace_tag) but provides no hints to the client. LLMs cannot distinguish safe (read) from dangerous (destructive) tools without explicit annotations. This violates current MCP spec guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | 2025-03-26+ | v1 |
Get recently updated documents across all notebooks
List all tags in the SiYuan Note system
List all available notebooks
List all available snapshots
Move documents to another location
Replace one tag with another tag in documents
Rollback to a specified snapshot to restore previous state
Unified search tool for SiYuan Note documents
Update (overwrite) the content of a document
No error handling or recovery guidance. Tool descriptions do not specify what happens on failure, which errors are retryable, or what the LLM should do next. Example: create_document and move_documents give no guidance on name collisions, permission errors, or missing parent folders. See pattern:recovery-guide.
Generic and incomplete descriptions. Many tool descriptions are under 70 characters and lack actionable context. Examples: 'List all available snapshots' (40 chars) gives no hint about snapshot purpose, date range, or when to call. 'Create a new notebook' (24 chars) lacks guidance on naming, structure, or what comes next. Baseline A+ tools average 194 chars and include dependencies and use-case guidance.
Parameter descriptions are minimal and sometimes ambiguous. Example: move_documents has 'from_ids' (array of document IDs to move) and 'to_id' (target document ID or parent location), but the description does not clarify whether to_id is a parent container, a sibling position, or a flat move target. Parameter names lack suffixes (_id, _name) to disambiguate. Baseline A+ tools have 72 chars per param description.
No documented pagination or result limits. Tools like list_notebooks, list_snapshots, get_recently_updated_documents, and list_all_tags do not specify max results, pagination tokens, or offset/limit params. Unbounded result sets risk exhausting context windows and cause unpredictable behavior. Baseline pattern requires limit/offset and return total_count.
Idempotency is not documented. Tools like create_document, create_notebook, and append_to_document do not specify idempotent behavior. If an LLM retries on perceived failure, will duplicate notebooks or documents be created? No guidance given. Agents rely on idempotency to safely retry on transient failures.
Tool composition gaps. Common SiYuan workflows require multi-step sequences not wrapped into single tools. Example: 'append to my daily note' requires the LLM to first discover the notebook_id via list_notebooks, then call append_to_daily_note. Users say 'append to today's note', not 'find my notebook, then append'. Consider offering append_to_today_daily_note that infers the notebook context.
Missing context-passing fields in responses. If create_document returns only document_id, the LLM cannot immediately append to it (append_to_document needs document_id) or search within it without an extra call. Responses should include parent notebook_id, path, and created timestamp to enable downstream tool chaining. See pattern:include-chaining-ids.