The SiYuan Note MCP Server lets AI assistants directly control SiYuan Note via 50+ tools across 12 categories:
📓 Notebook management – Create, delete, rename, and configure notebooks
📄 Document operations – Create, delete, move, and rename documents (with hpath auto-resolution)
🧱 Block editing – Insert, update, delete, move, collapse, and expand content blocks
🔍 Search & Query – Full-text search, SQL queries, and transaction refresh
📎 Attributes – Get and set block attributes
📁 File system – Read, write, delete, rename files, and list directories
📋 Templates – Render templates with Sprig support
📤 Export – Export documents as Markdown or resource packages
🔄 Conversion – Pandoc format conversion
🔔 Notifications – Push messages/notifications
🌐 Network – Forward proxy requests
⚙️ System – Query version, startup progress, and current time
Key meta-tools include executeCommand (run any SiYuan command), queryCommands (discover available commands), and help (get detailed command documentation).
Provides a comprehensive set of tools for interacting with SiYuan Note, enabling management of notebooks, documents, and content blocks, as well as full-text search, SQL querying, and template rendering.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SiYuan Note MCP Server search my notes for 'machine learning' and summarize the key points"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
让 AI 助手直接操作思源笔记的 Model Context Protocol 服务器
项目 | 版本 |
思源笔记 | >= 3.0.0（已验证 3.7.1） |
SiYuan API | docs/API.md（50 个非 Database 端点） |
Node.js | >= 18.0.0 |
MCP SDK | @modelcontextprotocol/sdk ^1.8.0 |
Related MCP server: SiYuan MCP Server
# 直接运行
SIYUAN_TOKEN=your-api-token npx @fromsko/siyuan-mcp-server
# 全局安装
npm install -g @fromsko/siyuan-mcp-server
SIYUAN_TOKEN=your-api-token siyuan-mcp-server环境变量 | 必需 | 说明 | 默认值 |
| ✅ | 思源笔记 API Token（设置 → 关于） | — |
| ❌ | 思源 API 地址 |
|
如果你是 AI 助手，请将以下配置添加到你的 MCP 客户端配置中：
{
"mcpServers": {
"siyuan": {
"command": "npx",
"args": ["-y", "@fromsko/siyuan-mcp-server"],
"env": {
"SIYUAN_TOKEN": "<用户提供的 API Token>",
"SIYUAN_API_URL": "http://localhost:6806"
}
}
}
}配置文件位置：
Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json（macOS）或 %APPDATA%\Claude\claude_desktop_config.json（Windows）
Cursor: .cursor/mcp.json
配置完成后重启客户端，即可使用 50 个思源笔记操作工具（笔记本管理、文档操作、块级编辑、全文搜索、SQL 查询等）。
类别 | 命令空间 | 端点数 | 能力 |
📓 笔记本 |
| 8 | 创建/删除/重命名/配置 |
📄 文档 |
| 11 | 创建/删除/移动/重命名（支持 hpath 自动解析） |
🧱 块操作 |
| 11 | 插入/更新/删除/移动/折叠/展开 |
🔍 搜索 |
| 3 | 全文搜索/SQL 查询/事务刷新 |
📎 属性 |
| 2 | 设置/获取块属性 |
📁 文件 |
| 5 | 读写/删除/重命名/列目录 |
📋 模板 |
| 2 | 渲染模板/Sprig |
📤 导出 |
| 2 | 导出 Markdown/导出资源包 |
🔄 转换 |
| 1 | Pandoc 格式转换 |
🔔 通知 |
| 2 | 推送消息 |
🌐 网络 |
| 1 | 正向代理 |
⚙️ 系统 |
| 3 | 版本/启动进度/当前时间 |
git clone https://github.com/Fromsko/siyuan-mcp-server.git
cd siyuan-mcp-server
npm install && npm run build && npm test详细开发文档：
文档 | 说明 |
开发指南、项目结构、添加端点流程 | |
MCP 使用指南 | |
官方 SiYuan API 文档 | |
LLM 导向的项目简介 | |
提交规范和开发约束 |
无法连接思源笔记 → 检查：思源是否运行、Token 是否正确、端口是否正确（默认 6806）
命令执行失败 → 确认笔记本/文档存在、Token 权限足够
连接远程思源 → 设置 SIYUAN_API_URL=http://your-server:6806
ISC — 详见 LICENSE
执行指定的命令
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | 命令类型 | |
| params | No | 命令参数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the full burden of behavioral disclosure. It merely states 'execute the specified command' without mentioning whether it can cause side effects, require permissions, return output, or fail. For a command execution tool, this is a significant transparency gap.
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 a single short sentence, but it is under-specified rather than concise. It lacks essential information and reads like a placeholder, similar to the low-quality 'process' example.
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?
This tool has two parameters including a nested object, no output schema, and no annotations. The description provides no details on supported command types, parameter structure, return values, or safety implications. It is critically incomplete for an operational tool.
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?
The input schema provides descriptions for both parameters (100% coverage), so the baseline is 3. The tool description adds no extra meaning beyond the schema's minimal 'command type' and 'command parameters' labels, but the schema at least names the parameters.
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 '执行指定的命令' (Execute the specified command) is a direct tautology of the tool name 'executeCommand'. It does not specify what types of commands, which resources, or how it differs from siblings like queryCommands or help.
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?
No usage guidance is provided. The description gives no context on when to use executeCommand versus alternatives, nor any prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取命令的帮助信息
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | 命令类型 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full weight. 'Get help information' implies a read-only, harmless operation, but it does not disclose any specific behaviors such as the format of returned help text, potential errors, or whether it depends on command types. This is acceptable for a simple help tool but lacks depth.
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 a single concise sentence that is directly to the point. It has no fluff or redundant information, making it highly efficient.
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 help tool with one parameter and no output schema, the description is minimally viable. However, it lacks details about acceptable values for 'type', the nature of the help output, and any examples. This leaves gaps that could confuse an agent.
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 coverage is 100% with the parameter 'type' described as '命令类型' (command type). The description adds no additional meaning beyond the schema. Since the schema is complete, the baseline score of 3 applies.
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 '获取命令的帮助信息' (Get help information for commands) clearly states the tool's purpose with a specific verb and resource. It differentiates from siblings like executeCommand and queryCommands by focusing on help, though it does not explicitly name alternatives.
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 provides no guidance on when to use this tool versus alternatives like queryCommands or executeCommand. There is no context about prerequisites, expected usage, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询可用的命令列表
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | 命令名称过滤 | |
| namespace | No | 命令命名空间过滤 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The word '查询' implies a read-only operation, but the description does not explicitly state that it makes no changes, nor does it disclose any permissions or return format details. However, for a simple query tool, the implied safety may be sufficient.
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 a single, concise sentence that immediately states the tool's purpose. There is no redundant information or unnecessary elaboration.
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?
Given the tool's simplicity and the schema's full parameter coverage, the description provides the essential function. However, it could be improved by explicitly mentioning that it returns a list or how filters interact, but the phrase '命令列表' implies the return type. Overall, it is adequate.
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?
The input schema covers both parameters (type and namespace) with descriptions, achieving 100% coverage. The tool description adds no additional parameter semantics, so it does not enhance what the schema already provides. Thus, a baseline score of 3 is appropriate.
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 uses a specific verb '查询' (query) and identifies the resource as the list of available commands, clearly distinguishing it from sibling tools like executeCommand and help. It does not just restate the tool name, but elaborates on what is being queried.
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 provides no guidance on when to use this tool versus alternatives like help or executeCommand, nor does it mention any exclusions or prerequisites. It leaves the usage to be inferred from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.8executeCommandhelpqueryCommandsScored across 3 tools
Each tool has a clearly distinct purpose: executeCommand runs a command, help retrieves help information, and queryCommands lists available commands. There is no overlap in functionality.
Tools use camelCase naming, but 'help' is a single word while others follow a verb_noun pattern. This minor inconsistency is acceptable but not perfectly uniform.
With only 3 tools, the server seems underdeveloped for a note-taking application. The tools are limited to command execution and help, lacking any note-specific operations.
The tool set is incomplete for a note server; there are no tools for creating, reading, updating, or deleting notes. The server focuses on generic command execution rather than note management.
AI access to your aNotepad online notes: read, search, write, and organize via 22 tools.
Create, search, and update notes in an xNotepad AI notebook, with semantic search and AI Q&A.
Connect AI to your flomo notes. Search, create, edit notes and manage tags via MCP.
Securely search, create, and organize your Mem notes and collections from AI assistants.
