Click on "Install 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 list all notes tagged 'urgent'"
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.
An MCP server that wraps the official Obsidian CLI (obsidian, see
https://obsidian.md/help/cli) and exposes your vault as a set of tools that any
MCP client (Claude Desktop, Claude Code, etc.) can use.
Each tool translates its parameters into a call to the obsidian binary and
returns the result to the model. Because every operation goes through Obsidian's
internal API, wikilinks and the index stay up to date automatically — the
underlying filesystem is never touched directly.
Obsidian running on the same machine as this server.
Obsidian CLI enabled: Settings → General → enable CLI support and follow
the instructions to register it (this installs the obsidian command on your
PATH).
Node.js 18+.
Check everything is ready with:
obsidian files totalIf that fails, make sure Obsidian is open and the CLI is enabled before continuing.
Related MCP server: obsidian-local-mcp
npm install
npm run buildThis compiles src/ into dist/. For development with automatic rebuilds:
npm run devnode scripts/smoke-test.mjsIt lists the registered tools and makes one real test call (obsidian_read) to
confirm the server talks to the CLI correctly.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json
(on Windows: %APPDATA%\Claude\claude_desktop_config.json) and add the block
below, replacing /absolute/path/to/obsidian-mcp with the path where you cloned
this repo (pwd from inside the folder gives it to you):
{
"mcpServers": {
"obsidian": {
"command": "node",
"args": ["/absolute/path/to/obsidian-mcp/dist/index.js"]
}
}
}If
nodeisn't on the PATH your MCP client uses (this can happen on macOS), setcommandto the absolute path of your Node binary (find it withwhich node) instead of"node".
Restart Claude Desktop and the obsidian_* tools should appear.
Register the server with the CLI (user scope makes it available in every
project; drop -s user to scope it to the current repo):
claude mcp add obsidian -s user "$(which node)" /absolute/path/to/obsidian-mcp/dist/index.jsCheck what
which nodereturns before using it: on some setups it resolves to an ephemeral/cached Node (e.g. under~/.cache/…) that may disappear. Prefer a stable absolute path (your nvm/Homebrew Node) as thecommand.
Verify it connected with claude mcp list (look for obsidian … ✔ Connected).
Because the tool list is loaded at startup, restart Claude Code once after
registering so the obsidian_* tools appear.
Variable | What it does | Default |
| Path/name of the binary if |
|
| Which vault to use when you have several open | (none) |
| Timeout per CLI call |
|
| If | (empty) |
Escape hatch: obsidian_exec runs any CLI subcommand directly (files,
folders, links, orphans, unresolved, tags:rename, plugin:enable,
publish:list, sync:status, history, eval, dev:*, etc.) — it covers
everything without a dedicated tool.
Notes: obsidian_read, obsidian_create, obsidian_append,
obsidian_prepend, obsidian_move, obsidian_delete, obsidian_list_files,
obsidian_list_folders.
Search: obsidian_search (supports filters such as [tag:project],
[status:active], [priority:>3] inside the query).
Daily notes: obsidian_daily_read, obsidian_daily_append,
obsidian_daily_prepend.
Properties (frontmatter): obsidian_properties_get,
obsidian_properties_set, obsidian_properties_remove.
Tags and links: obsidian_tags, obsidian_backlinks, obsidian_links,
obsidian_orphans, obsidian_unresolved_links.
Tasks: obsidian_tasks_list, obsidian_task_create,
obsidian_task_complete.
obsidian_exec (and, within it, commands like eval or dev:*) can run
arbitrary JavaScript inside your Obsidian instance or inspect its UI. If you'd
rather expose only the curated set of tools above, start the server with
OBSIDIAN_MCP_DISABLE_EXEC=1.
Obsidian Sync applies cross-platform (Windows/iOS) naming rules. Never put
: * ? " < > | / \ in a note's **filename** — a single one can send Obsidian
Sync into a loop. These characters are fine in the note **title** (frontmatter /
# H1), just not in the .md filename. When creating or renaming notes through
this server, sanitize filenames accordingly.
src/
cli.ts -> helper that invokes the `obsidian` binary and parses its output
index.ts -> MCP server definition and all the tools
scripts/
smoke-test.mjs -> quick manual test without needing an MCP clientThis is an independent, community-built project. It is not affiliated with,
endorsed by, sponsored by, or associated with Obsidian, Obsidian.md, or Dynalist
Inc. in any way. "Obsidian" is a trademark of its respective owner; it is used
here only to describe interoperability. This software wraps the official Obsidian
CLI and is provided "as is", without warranty of any kind (see the license). You
are responsible for any changes it makes to your vault — back up your data and
review the security note above before enabling obsidian_exec.
MIT © fodaveg
Appends content to the end of an existing note.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Note name / wikilink. | |
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'appends' and 'existing note,' implying mutation but lacks details like idempotency, permissions, or effects on non-existent notes.
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?
Single sentence is concise but overly minimal. Could be improved with brief additional context without becoming verbose.
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?
No output schema and no annotations. For a simple tool, description omits error conditions, note existence behavior, and return value. Incomplete guidance for selection and invocation.
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 50% (content parameter has no description). Description adds no extra meaning beyond schema, such as clarifying file path format or content encoding requirements.
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?
Description clearly states the tool appends content to the end of an existing note, using a specific verb and resource. It distinguishes from sibling tools like obsidian_prepend and obsidian_read.
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 tool versus alternatives, such as obsidian_prepend for prepending or obsidian_read for just reading. Does not specify prerequisites like note existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a note. By default it goes to Obsidian's trash unless permanent is set.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Note name / wikilink to delete. | |
| permanent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the trash behavior and the permanent bypass, but does not discuss side effects like reversibility, error handling, or impact on linked notes. More context would be beneficial for a mutation tool.
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 that conveys the essential information without any superfluous words. Every part earns its place.
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 (2 parameters, no output schema), the description addresses the core function and the special permanent parameter. It could be improved by noting error behavior when the file doesn't exist, but overall it is sufficiently complete for typical use.
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 schema provides descriptions for both parameters: 'file' is described as 'Note name / wikilink to delete.' and 'permanent' is a boolean with default false. The description adds no extra value beyond what the schema already states. Schema coverage is 50% (one param described), so the baseline is adequate.
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 clearly states the action (deletes), resource (note), and a key behavioral detail (trash vs permanent). It is easily distinguishable from sibling tools like obsidian_read or obsidian_move.
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 specifies default trash behavior and the permanent option, which guides usage. However, it does not explicitly mention when not to use the tool or suggest alternatives like obsidian_move for relocating, which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists notes/files in the vault, optionally filtered by folder or extension.
| Name | Required | Description | Default |
|---|---|---|---|
| ext | No | File extension filter, e.g. "md" | |
| json | No | Return machine-readable JSON output. | |
| folder | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It implies read-only behavior but does not disclose any permissions, limitations, side effects, or output format. Lacks details like pagination or error handling.
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?
Single sentence with no wasted words. All essential information is front-loaded. Efficient and clear.
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 listing tool with no output schema, the description is minimally adequate but lacks details about return format (e.g., list of file names, paths) and any default behavior. The three parameters are partially explained, but overall the description does not fully equip an agent to invoke the tool correctly without guessing.
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 67% (folder param lacks schema description). The description adds meaning by mentioning filtering by folder or extension, reinforcing ext and folder. However, the 'json' parameter's purpose is not explained in the description, and the description does not compensate fully for the undocumented folder parameter.
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 the specific verb 'Lists' and resource 'notes/files in the vault', clearly indicating what the tool does. It implicitly distinguishes from siblings like obsidian_read (reads content) and obsidian_search (searches) by focusing on listing/filtering.
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 tool versus alternatives like obsidian_search or obsidian_read. The description does not mention any prerequisites or contextual hints for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Moves a note to a different folder (or renames it). Wikilinks pointing to it are updated automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Destination folder or path, e.g. "Archive/2026/". | |
| file | Yes | Note name / wikilink to move. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behavior (automatic wikilink update) but omits error handling, permissions, or side effects like moving or renaming across vaults.
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?
Two concise sentences, no redundancy, front-loaded with core action, efficient and clear.
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?
Description adequately covers purpose and key behavior for a simple move operation. Missing return value or error handling, but no output schema expected. Slightly incomplete given no annotations.
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 clear parameter descriptions. The description adds no additional semantic meaning to parameters beyond what schema already provides, meriting baseline score.
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?
Description uses specific verb 'Moves' and 'renames' with resource 'note', clearly distinguishing from siblings like obsidian_delete or obsidian_append. It explicitly states automatic wikilink updates.
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 implied but not explicit. The description says what it does but does not provide when-to-use or when-not-to-use guidelines, nor alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inserts content at the start of an existing note.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Note name / wikilink. | |
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It does not state whether the note must already exist, if content is added with a newline, or any effects on existing content. This is inadequate for a mutation tool.
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 sentence, which is concise but overly terse. It front-loads the core action but omits necessary details, sacrificing structure for brevity.
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 no output schema and no annotations, the description is incomplete. It does not cover whether the tool creates missing notes, handles wikilinks, or returns confirmation. A minimal mutation tool requires more context.
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 50% (only 'file' has description). The tool description adds no additional meaning for 'content', which lacks schema description. The agent gets no guidance on content format or constraints beyond the schema.
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 'Inserts' and resource 'content at the start of an existing note', clearly distinguishing it from sibling tools like obsidian_append (which appends) and obsidian_read (which reads).
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 is provided on when to use this tool versus siblings, such as obsidian_append for appending. There is no mention of prerequisites or when not to use it, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the contents of a note, by wikilink name or by vault-relative path.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | Note name / wikilink, e.g. "My Note" | |
| path | No | Vault-relative path, e.g. "Projects/Note.md" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation with no side effects, which is transparent. However, it does not specify behavior for non-existent notes or permissions. With no annotations, the description carries the full burden, and while it is honest, it could be more explicit about safety.
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 sentence that is front-loaded with the main action and resource. Every word is meaningful with no redundancy or wasted text.
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 description states that it reads contents but does not describe the return format (e.g., plain text, markdown) or whether metadata is included. Without an output schema, more detail would improve completeness for a read operation.
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 description adds value by explaining the two identification methods and providing examples ('My Note', 'Projects/Note.md'), which clarifies parameter usage beyond the schema descriptions.
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 clearly states the action ('reads'), the resource ('contents of a note'), and identifies two identification methods (wikilink name or vault-relative path). It effectively distinguishes from sibling tools like obsidian_list_files or obsidian_search.
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 implies use when you want to retrieve note content, but lacks explicit guidance on when not to use or which sibling tool to prefer. The context of sibling tools with different actions provides some differentiation, but the description itself does not offer usage directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across the vault. Supports structured filters inside the query string, e.g. "[tag:project]", "[status:active]", "[priority:>3]".
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | Return machine-readable JSON output. | |
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only side effects, permissions, or rate limits. The description carries the full burden but fails to add this context.
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 concise with two sentences and front-loaded, but could efficiently include more guidance without increasing length significantly.
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 description does not explain return format, pagination, or other behavioral details. With no output schema, the description should provide more context to be complete for a search 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 description adds meaning to the 'query' parameter with examples of structured filters, but the 'limit' parameter lacks description in both schema and description, and schema coverage is low (33%).
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 clearly states the tool's purpose as 'Full-text search across the vault' with a specific verb and resource, and distinguishes it from sibling tools like obsidian_read or obsidian_list_files.
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 tool versus alternatives; no explicit context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new task, optionally tagged.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Comma-separated tags, e.g. "work,urgent". | |
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only mentions creation and optional tagging. It omits critical details like where the task is created (e.g., active note, default file), side effects, or conflict behavior.
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 sentence, which is concise, but it sacrifices necessary detail. It earns its place but is too brief to be fully effective.
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 (two parameters, no output schema, no annotations), the description is incomplete. It does not explain the target note, required permissions, or how optional tags affect creation, leaving significant gaps for an AI 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 50% (only 'tags' has a description). The description adds no value for the 'content' parameter, and 'optionally tagged' merely echoes the schema. The agent lacks understanding of the 'content' field's format or purpose.
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 clearly states the action (creates) and resource (task), and the tool name includes 'obsidian_task_create', distinguishing it from sibling file manipulation tools like 'obsidian_append' or 'obsidian_delete'.
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 is provided on when to use this tool versus alternatives like 'obsidian_append' for manually formatting a task. There is no mention of prerequisites or contextual triggers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists tasks (checkboxes) found across the vault.
| Name | Required | Description | Default |
|---|---|---|---|
| json | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It states the tool lists tasks but does not disclose whether the operation is read-only, what the output format is, or if any side effects exist. This is insufficient for an agent to understand behavioral implications.
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 sentence, concise and front-loaded. However, it lacks necessary detail, making it slightly over-terse for effective use.
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 tool with one parameter and no annotations, the description should at least explain the parameter and expected output. It fails to do so, leaving significant gaps in understanding.
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 only parameter 'json' has no description in the schema (0% coverage). The tool description does not explain its purpose (e.g., returning results in JSON format). The agent cannot infer how to use the parameter.
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 clearly states the tool's action (lists), resource (tasks/checkboxes), and scope (across the vault). It differentiates from sibling tools like obsidian_task_create by focusing on listing existing tasks rather than creating them.
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 is provided on when to use this tool versus alternatives like obsidian_search (which might find tasks via text search) or obsidian_task_create (to create new tasks). The description lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists links in the vault that don't resolve to an existing note.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states basic functionality. It does not disclose whether the operation reads the entire vault, if it's passive, or any side effects.
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 focused sentence that directly conveys the tool's purpose without unnecessary words.
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 tool with no parameters, the description is minimally adequate. However, it lacks details about scope or return format that could enhance completeness.
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 tool has zero parameters and the schema coverage is 100%. The description adds no parameter information but is not required to do so since there are none.
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 clearly states the tool lists unresolved links, distinguishing it from sibling tools like obsidian_read and obsidian_search which serve different purposes.
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 tool versus alternatives. The description does not mention use cases or exclusions, leaving the agent without context for decision-making.
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. Dates show when Glama detected each change.
v0.1.0obsidian_appendobsidian_deleteobsidian_list_filesobsidian_moveobsidian_prependobsidian_readobsidian_searchobsidian_task_createobsidian_tasks_listobsidian_unresolved_linksEach tool has a clear and distinct purpose. There is no overlap or ambiguity; even append/prepend are differentiated by position.
All tools follow the same obsidian_verb_noun pattern in snake_case, making it predictable and easy to understand.
10 tools is appropriate for an Obsidian vault MCP server, covering file operations, search, and task management without being bloated.
Covers most core operations (read, write, move, delete, search, tasks) but lacks an explicit create note tool and content update beyond append/prepend.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Search, read, and write your Apple Notes from ChatGPT/Claude via a local Mac agent + MCP relay.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/fodaveg/obsidian-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
