Obsidian 볼트를 VS Code + GitHub Copilot에 노출하기 위한 Node.js + TypeScript 기반의 MCP 로컬 서버입니다.
이 프로젝트는 볼트 내의 Markdown 노트를 읽고 쓰는 데 중점을 두고 stdio를 통한 로컬 사용을 위해 설계되었습니다.
npm install -g obsidian-mcp-local
Related MCP server: Obsidian MCP Server
search_notes(query)
노트의 경로, 프런트매터 및 콘텐츠 내에서 텍스트 검색
짧은 발췌문과 함께 순위가 매겨진 결과 반환
get_note(path)
볼트에서 노트 열기
path, frontmatter, content 반환
create_note(path, content, overwrite?)
새 노트 생성
선택적으로 기존 노트 덮어쓰기 가능
append_to_note(path, content)
기존 노트 끝에 콘텐츠 추가
find_by_tag(tag)
태그별로 노트 찾기
프런트매터의 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.
