基于 Node.js + TypeScript 的 MCP 本地服务器，用于将您的 Obsidian 库 暴露给 VS Code + GitHub Copilot。
它专为通过 stdio 进行本地使用而设计，专注于在您的库中读取和写入 Markdown 笔记。
npm install -g obsidian-mcp-local
Related MCP server: Obsidian MCP Server
search_notes(query)
在笔记的路径、Frontmatter 和内容中搜索文本
返回带有简短摘要的排名结果
get_note(path)
打开库中的笔记
返回 path、frontmatter 和 content
create_note(path, content, overwrite?)
创建新笔记
可选地覆盖现有笔记
append_to_note(path, content)
将内容添加到现有笔记的末尾
find_by_tag(tag)
按标签查找笔记
支持 Frontmatter 中的 tags 和内容中的内联标签
仅访问 配置的库内 的文件
忽略以下目录：
.obsidian
.git
node_modules
仅处理 .md 文件
规范化路径以防止访问基础目录之外的文件
obsidian-mcp-local/
package.json
tsconfig.json
README.md
.vscode/
mcp.example.json
src/
index.tsNode.js 20+
npm
安装了 GitHub Copilot 的 VS Code
本地 Obsidian 库
在项目目录中：
npm install
npm run build用于开发：
npm run dev运行编译后的版本：
npm startnpm install
npm run build将 .vscode/mcp.example.json 的内容复制到您将使用 Copilot 的工作区中的 .vscode/mcp.json。
示例： 本地使用：
{
"servers": {
"obsidian-local-vault": {
"type": "stdio",
"command": "node",
"args": ["C:/caminho/para/obsidian-mcp-local/dist/index.js"],
"env": {
"OBSIDIAN_VAULT_PATH": "D:/Obsidian/Vault"
}
}
}
}通过 npx 使用（无需本地构建）：
{
"servers": {
"obsidian-local-vault": {
"command": "npx",
"args": ["-y", "obsidian-mcp-local"],
"env": {
"OBSIDIAN_VAULT_PATH": "D:/Obsidian/Vault"
}
}
}
}替换：
C:/caminho/para/obsidian-mcp-local/dist/index.js
D:/Obsidian/Vault
为您的机器上的实际路径。
之后，Copilot 应该能发现 MCP 服务器。
“在我的库中搜索关于 .NET 的笔记”
“打开笔记 knowledge/backend/dotnet.md”
“在 inbox/ideias-mcp.md 中创建一个笔记，总结我们讨论的内容”
“在笔记 daily/2026-04-06.md 的末尾添加文本 - testar MCP local”
“查找带有 #arquitetura 标签的笔记”
append_under_heading
[[wikilinks]] 解析
get_backlinks(note)
用于快速搜索的 SQLite 索引
写入文件夹白名单 (inbox/, daily/, scratch/)
可配置的特定文件夹写入锁定
本项目 不依赖于打开 Obsidian。
它直接对库文件进行操作。
如果您同时在 Obsidian 和 VS Code 中启用写入，则需要自行负责并发控制。
目前该项目假设库是一个本地 Markdown 文件夹。
实现位于：
src/index.ts
个人使用 / 自定义初始基础。
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
| path | Yes | ||
| content | Yes | ||
| overwrite | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
| tag | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no 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.0.2append_to_notecreate_notefind_by_tagget_notesearch_notesScored across 5 tools
Each tool name clearly indicates a distinct operation: create, get, append, search, and find by tag. No significant overlap is apparent.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_note, search_notes), making the set predictable.
Five tools cover essential note operations (create, retrieve, modify, search, tag) without unnecessary bloat or deficiency for the domain.
The set includes create, read, update (via append), and search operations but lacks a delete operation, which is a notable gap for a complete CRUD surface.
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
Personal context for every AI: search, read, and write back to your private Markdown library.
