Enables GitHub Copilot to access and manipulate Obsidian vault contents through MCP tools, allowing AI-assisted note retrieval, creation, and append operations within VS Code.
Provides tools for reading, writing, searching, and managing Markdown notes within an Obsidian vault, including support for frontmatter, tags, and path-normalized file operations directly on the vault filesystem.
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., "@Obsidian MCP Local search my vault for notes about API design"
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.
MCP local in Node.js + TypeScript to expose your Obsidian vault to VS Code + GitHub Copilot.
It is designed for local use via stdio, focusing on reading and writing Markdown notes within your vault.
npm install -g obsidian-mcp-local
Related MCP server: Obsidian MCP Server
search_notes(query)
searches for text in the path, frontmatter, and note content
returns ranked results with a short excerpt
get_note(path)
opens a note from the vault
returns path, frontmatter, and content
create_note(path, content, overwrite?)
creates a new note
optionally overwrites an existing note
append_to_note(path, content)
appends content to the end of an existing note
find_by_tag(tag)
finds notes by tag
supports tags in frontmatter and inline tags in the content
only accesses files within the configured vault
ignores directories such as:
.obsidian
.git
node_modules
works only with .md files
normalizes paths to prevent access outside the base directory
obsidian-mcp-local/
package.json
tsconfig.json
README.md
.vscode/
mcp.example.json
src/
index.tsNode.js 20+
npm
VS Code with GitHub Copilot
a local Obsidian vault
In the project directory:
npm install
npm run buildFor development:
npm run devTo run the compiled version:
npm startnpm install
npm run buildCopy the content of .vscode/mcp.example.json to your .vscode/mcp.json in the workspace where you will use Copilot.
Example: using locally:
{
"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"
}
}
}
}using via npx (no local build required):
{
"servers": {
"obsidian-local-vault": {
"command": "npx",
"args": ["-y", "obsidian-mcp-local"],
"env": {
"OBSIDIAN_VAULT_PATH": "D:/Obsidian/Vault"
}
}
}
}Replace:
C:/path/to/obsidian-mcp-local/dist/index.js
D:/Obsidian/Vault
with the actual paths on your machine.
After this, Copilot should discover the MCP server.
“Search my vault for notes about .NET”
“Open the note knowledge/backend/dotnet.md”
“Create a note in inbox/ideias-mcp.md with a summary of what we discussed”
“Append to the end of the note daily/2026-04-06.md the text - test local MCP”
“Find notes with the tag #architecture”
append_under_heading
[[wikilinks]] parsing
get_backlinks(note)
SQLite index for fast search
folder whitelist for writing (inbox/, daily/, scratch/)
configurable write blocking for specific folders
This project does not depend on Obsidian being open.
It operates directly on the vault files.
If you enable writing in both Obsidian and VS Code, concurrency control is up to you.
The project currently assumes the vault is a local Markdown folder.
The implementation is in:
src/index.ts
Personal use / initial base for customization.
| 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.
