Provides tools for managing notes in an Obsidian vault, including creating, reading, updating, deleting notes, searching, listing, and retrieving metadata with tag extraction.
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-server search for notes about machine learning"
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.
🔗 Model Context Protocol server for Obsidian - Connect your knowledge base to AI
📝 Note Management: Create, read, update, and delete notes
🔍 Search: Full-text search across your vault
📋 Listing: List notes with filtering options
📊 Metadata: Get file size, timestamps, tags, and properties
⏰ Sorting: Sort notes by creation/modification time or size
🏷️ Tag Extraction: Automatically extract tags from frontmatter and content
🔒 Safe: Path validation to prevent directory traversal
⚡ Fast: Efficient file operations
Related MCP server: Obsidian MCP Server
npm install -g @indiegeeker/obsidian-mcp-server
# or
pnpm install -g @indiegeeker/obsidian-mcp-serverAdd to your Claude Desktop config:
{
"mcpServers": {
"obsidian": {
"command": "obsidian-mcp-server",
"env": {
"OBSIDIAN_VAULT_PATH": "/path/to/your/vault"
}
}
}
}Create a new note in your vault.
Parameters:
filename (required): Name of the note
content (required): Markdown content
path (optional): Folder path within vault
Read an existing note's content and frontmatter.
Parameters:
filepath (required): Path to the note
Search notes by content.
Parameters:
query (required): Search string
path (optional): Limit search to folder
List all notes in vault or folder.
Parameters:
path (optional): Folder to list
recursive (optional): Include subfolders
Update an existing note's content.
Parameters:
filepath (required): Path to the note
content (required): New content
append (optional): Append instead of replacing
Delete a note from the vault.
Parameters:
filepath (required): Path to the note to delete
Get detailed metadata for a note.
Parameters:
filepath (required): Path to the note
includeTags (optional): Extract tags from frontmatter and content (default: true)
Returns:
File size (bytes and formatted)
Creation time
Modification time
Frontmatter properties
Extracted tags (from frontmatter and #hashtags)
List notes sorted by various criteria.
Parameters:
path (optional): Folder to list (default: root)
recursive (optional): Include subfolders (default: true)
sortBy (optional): Sort criterion - "created", "modified", "size", or "name" (default: "modified")
order (optional): Sort order - "asc" or "desc" (default: "desc")
includeMetadata (optional): Include size and timestamps (default: true)
limit (optional): Maximum number of notes to return
# Clone the repo
git clone https://github.com/indiegeeker/obsidian-mcp-server.git
# Install dependencies
pnpm install
# Build
pnpm run build
# Watch mode
pnpm run devMIT
Create a new note in the Obsidian vault
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional folder path within the vault (e.g., 'Projects/Work') | |
| content | Yes | Content of the note in Markdown format | |
| filename | Yes | Name of the note file (without .md extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not say what happens if a note with that filename already exists (overwrite vs. error), whether the vault path must pre-exist, or what the tool returns.
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?
A single front-loaded sentence with no filler. It is appropriately sized, though it is so terse that it omits useful context rather than being padded.
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 3-parameter creation tool with a fully documented schema and no output schema, the description covers the basics. It falls short on collision/overwrite behavior and prerequisites, which matter for a tool that writes to a vault.
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 description coverage is 100%, so all three parameters (path, content, filename) are already documented in the schema. The description adds no syntax, defaults, or constraint detail beyond that, so the baseline 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?
States a specific verb and resource ('Create a new note') plus the target system (Obsidian vault). It is distinguishable from destroy/read siblings like delete_note and read_note, though it never names the closest alternative, update_note, explicitly.
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?
There is no guidance on when to use this versus update_note or the various read/list/search tools. The implicit 'use to create, not modify' inference is left entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a note from the vault
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | Path to the note file to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Delete' implies a destructive, likely irreversible operation, but the description does not confirm irreversibility, permission requirements, or whether the note can be recovered. This is a significant gap for a destructive tool with zero annotation coverage.
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?
A single, front-loaded sentence with zero waste. Appropriate for a simple one-parameter tool.
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 destructive, irreversible mutation with no annotations and no output schema, the description is too thin. It should disclose whether deletion is permanent, whether confirmation or specific permissions are required, and what happens on success or failure.
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 description coverage is 100%, with the single filepath parameter fully documented in the schema. The description adds no parameter detail beyond the schema, so baseline 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?
States a specific verb (delete) and resource (a note from the vault). Clear and distinguishable from siblings like create_note or update_note, though it offers no explicit differentiation phrase beyond the obvious verb contrast.
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?
Provides no when-to-use context, no prerequisites, and no mention of alternatives. With destructive siblings like update_note present, guidance on when destruction is appropriate versus updating would be valuable, but none is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed metadata for a specific note including size, timestamps, frontmatter tags and properties
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | Path to the note file relative to vault root (e.g., 'Daily/2024-01-01.md') | |
| includeTags | No | Extract tags from both frontmatter and content (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether this is a read-only operation, whether missing files error or return empty, whether tags are computed or stored, or any performance/caching behavior. It merely lists metadata categories already implied by the name.
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?
A single efficient sentence, front-loaded with the verb and resource. No filler or redundancy, though it is arguably too terse to carry usage or behavioral context.
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?
With no annotations and no output schema, the description should compensate by explaining the return shape, error behavior, and read-only nature. It leaves all of that to inference, making it incomplete for a tool an agent must call correctly.
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 description coverage is 100%, so both parameters are fully documented in the schema (filepath with example, includeTags with default). The description adds no parameter detail beyond 'frontmatter tags', so baseline 3 is correct.
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 states a specific verb ('Get') and resource ('metadata for a specific note') and enumerates what the metadata covers: size, timestamps, frontmatter tags and properties. This is clear. It does not explicitly distinguish itself from sibling read_note, which likely returns content, but the word 'metadata' vs the sibling name does some differentiation.
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 when-to-use guidance. The description never states when to choose get_note_metadata over read_note or how it relates to search_notes/list_notes. An agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all notes in the vault or a specific folder
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Folder path to list (empty for root) | |
| recursive | No | Include subfolders |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: no ordering, no pagination or result-count limits, no note on whether results are truncated for large vaults, and no indication of what fields a listed note contains. Read-only intent is only implied by the word 'list'.
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?
A single short sentence with no filler, and the resource is front-loaded. It is efficiently sized for a simple read tool, though it is arguably so terse that it omits useful detail rather than being a model of economical speech.
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 two-parameter read tool with full schema coverage and no output schema, this is minimally adequate. The notable gap is the existence of the near-duplicate sibling list_notes_sorted, whose relationship to this tool the description never clarifies, leaving the agent to guess which listing endpoint to call.
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 description coverage is 100%, so both parameters (path, recursive) are fully documented in the schema, giving a baseline of 3. The phrase 'vault or a specific folder' loosely mirrors the path parameter but adds no new syntax or semantics, and recursive is not addressed at all.
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 states a specific verb (list) and resource (notes) with the scope of the operation (whole vault or a specific folder). It does not, however, distinguish itself from the closely related sibling list_notes_sorted or search_notes, which an agent could easily confuse it with.
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?
There is no explicit when-to-use guidance and no comparison to alternatives such as search_notes (filtered lookup) or list_notes_sorted (ordered listing). The only hint is the scope phrase 'vault or a specific folder', which is a purpose statement rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List notes sorted by creation time, modification time, or size
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Folder path to list (empty for root) | |
| limit | No | Maximum number of notes to return (default: no limit) | |
| order | No | Sort order: 'asc' (ascending/oldest first) or 'desc' (descending/newest first) | desc |
| sortBy | No | Sort by: 'created' (creation time), 'modified' (modification time), 'size' (file size), or 'name' (alphabetical) | modified |
| recursive | No | Include subfolders | |
| includeMetadata | No | Include metadata (size, timestamps) for each note |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It says nothing about permissions required, pagination, default behavior, or return format. For a list tool with zero behavioral disclosure, this is inadequate.
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?
A single, efficient sentence that is front-loaded and wastes no words. However, it is under-specified rather than richly concise, so it doesn't reach 5.
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 6-parameter list tool with no annotations and no output schema, the description should mention default sort behavior, recursion default, or return shape. It omits all of that, leaving significant gaps.
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%, so all six parameters, their enums, and defaults are fully documented in the schema. The description adds nothing beyond what the schema already provides. Baseline 3 is correct when the schema does all the heavy lifting.
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?
Specific verb and resource ('List notes') with the sorting capability stated. It doesn't explicitly differentiate from the sibling list_notes, though the 'sorted' name and description imply it. Clear but lacks sibling differentiation.
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 guidance on when to use this versus list_notes, search_notes, or get_note_metadata. The agent is left to infer usage from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the content of an existing note
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | Path to the note file relative to vault root (e.g., 'Daily/2024-01-01.md') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it only weakly carries it. 'Read' implies a non-mutating operation, but nothing is said about behavior for missing paths, encoding, size limits, or whether content is returned raw or parsed.
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?
A single tight sentence with the verb front-loaded and no filler. It is efficient, though the brevity comes at the cost of the behavioral and usage detail noted elsewhere.
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 trivial one-parameter read tool this is nearly adequate, especially since the param is fully documented. With no annotations and no output schema, though, the description should at least say what the note content is returned as and how a missing file behaves.
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 description coverage is 100% and the single filepath parameter is documented with a concrete relative-path example, so the schema does the heavy lifting. The description adds nothing beyond that, which is the expected baseline when the schema is complete.
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?
States a specific verb ('Read') and resource ('content of an existing note'), so an agent immediately knows this retrieves note body text. It does not, however, distinguish itself from get_note_metadata, which reads a different facet of the same resource — that distinction is left to the agent to infer.
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?
Usage is only implied: 'existing note' hints the file must already be present and that update/delete are the mutation counterparts. There is no explicit when-to-use statement and no routing guidance against get_note_metadata or search_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search notes by content or filename
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional path to limit search scope | |
| query | Yes | Search query string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that the operation is read-only, how matching works, whether results are paginated, or what the response contains beyond the basic search intent.
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 front-loaded sentence with no wasted words. It states the core action and resource immediately, which is appropriate for a simple search tool.
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?
The tool is simple and the schema fully documents both parameters, so an agent can invoke it. However, with no annotations and no output schema, the description leaves behavioral context such as result format, matching semantics, and pagination unstated.
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 description coverage is 100%, so both query and path are already documented in the input schema. The description adds no extra syntax, format, or behavioral detail for those parameters, making the baseline score of 3 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 states a specific verb and resource: search notes by content or filename. It is clear enough to distinguish from read/list siblings, but it does not explicitly name or differentiate itself from alternatives like list_notes or read_note.
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 phrase 'Search notes by content or filename' implies the use case, but there is no explicit when-to-use guidance, no exclusions, and no named alternatives. An agent can infer that this is for finding notes, but the description does not route it against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing note's content
| Name | Required | Description | Default |
|---|---|---|---|
| append | No | If true, append to existing content instead of replacing | |
| content | Yes | New content for the note | |
| filepath | Yes | Path to the note file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and provides almost nothing: no mention that content is replaced by default (a destructive overwrite partially implied only by the append parameter's schema text), no behavior for a missing file, no permission or error semantics. This is a mutation tool, so the silence on overwrite risk is a real 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?
A single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity borders on under-specification for a mutating tool.
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 3-parameter mutation tool with no annotations and no output schema, the description should disclose overwrite behavior, error cases, and success semantics. Almost none of that is present, leaving the agent to rely solely on the input schema.
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 description coverage is 100%, so all three parameters (filepath, content, append) are already documented in the schema, including the append-vs-replace semantics. The description adds no meaning beyond 'content', so baseline 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?
Specific verb+resource ('Update an existing note's content') makes the operation immediately identifiable. It does not, however, distinguish itself from siblings like create_note or delete_note beyond the obvious verb difference.
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 guidance on when to use this versus create_note (new note) or read_note, nor any prerequisites such as the target file existing. The agent must infer usage entirely from the name.
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.
v0.1.1create_notedelete_noteget_note_metadatalist_noteslist_notes_sortedread_notesearch_notesupdate_noteScored across 8 tools
Most tools have distinct purposes, but list_notes and list_notes_sorted overlap significantly; the sorted version could be a parameter of list_notes. Additionally, get_note_metadata vs read_note might be confused for retrieving note details, though descriptions clarify the distinction.
Most tools follow a verb_noun pattern (update_note, delete_note, search_notes, list_notes, get_note_metadata, create_note, read_note), but list_notes_sorted deviates by adding a modifier, breaking consistency.
Eight tools is reasonable for a note management server, covering core operations. However, list_notes_sorted is arguably redundant, making the set slightly over-specified.
The tools provide full CRUD coverage (create, read, update, delete) plus search, listing, sorting, and metadata retrieval, covering the essential operations for managing notes in an Obsidian vault without obvious gaps.
Personal context for every AI: search, read, and write back to your private Markdown library.
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
