Obsidian MCP Server Comparison

Multiple community MCP servers expose an Obsidian vault to AI clients. They differ
mainly in whether they treat the vault as a flat file store or as a structured,
resource-first knowledge graph — a meaningful distinction once an agent is expected to
navigate a large vault rather than fetch one named file.

The three servers

ServerDesign centerBest for
Piotr1215/mcp-obsidianResource-first, HATEOAS-style navigationSearch results that become resource links and graph traversal
Vasallo94/obsidian-mcp-serverVault profiles: skills, standards, local docs, integrationsStructured agent context (profiles/skills/standards), not just files
cyanheads/obsidian-mcp-serverProduction engineering: 14 tools, 3 resourcesScoped paths, read-only mode, safe/destructive-action controls

Piotr1215/mcp-obsidian — resource-first navigation

Exposes notes as obsidian-note://… resources, and its search/list/tag/metadata/
title-search tools return resource_link objects rather than inline text dumps — a
HATEOAS-style pattern: discovery tools return links to canonical note resources, and
the client then reads the selected resource.

search-vault("MCP")  

returns note hits + resource links  

obsidian-note://guides/MCP-Guide.md  

resources/read on the chosen note  

This makes the resource link functional rather than cosmetic: a search hit identifies
a durable knowledge object the agent can retrieve precisely, instead of re-searching
or guessing a path. See MCP Resources for why this pattern (discovery
tool → resource link → resource read) generalizes well beyond Obsidian.

Vasallo94/obsidian-mcp-server — profiles, skills, and standards

Organizes resources around profiles, skills, standards, local documentation, and
integrations
, rather than treating the vault as a flat file collection:

.agents/  
  vault.yaml  
  skills/  
  standards/  
  local-docs/  
obsidian://profiles/current  
obsidian://skills/{skill}  
obsidian://standards/{standard}  
obsidian://docs/{document}  
obsidian://integrations/{integration}/setup  

The relevant lesson for any AI-OS-style vault: make agent context explicit and
separable (what’s a skill vs. a standard vs. raw documentation) rather than a single
undifferentiated search_vault surface. This closely parallels the Skills Over MCP
skill:// convention and this vault’s own ABOUT/templates + .claude/skills
separation.

cyanheads/obsidian-mcp-server — production safety

Strongest production-oriented option: 14 tools, 3 resources (a vault path, a tags
snapshot, a status snapshot). Less resource-centric than Piotr1215’s navigation model,
but the reference to use for scoped file-path access, a read-only mode, frontmatter/tag
operations, section-aware Markdown editing, and safeguards around destructive
deletion.

Earlier survey (superseded)

An earlier, pre-schema research note (2025-06-26) surveyed a different set —
natestrong/obsidian-mcp (TypeScript, v2.0: 5x faster search, image support, regex/
property search, one-command Claude Desktop setup), MarkusPfundstein/mcp-obsidian
(Python, via Obsidian’s Local REST API), and a generic npm obsidian-mcp-server
package — recommending natestrong’s for feature completeness and MarkusPfundstein’s
for Python/REST-API integration. None of the three overlap with the resource-centric
servers above; if evaluating today, compare feature completeness (natestrong-style)
against the resource/profile architecture (Piotr1215/Vasallo94/cyanheads) based on
whether the use case is “fetch/edit notes” or “structured agent context navigation.”

Choosing between them

  • Want search results the agent can precisely reread as canonical objects: Piotr1215
  • Want explicit skill/standard/profile separation for an AI-OS-style vault: Vasallo94
  • Want the safest, most feature-complete production server: cyanheads
  • Want fastest raw search + image support, simplest setup: natestrong (2025 pick, unverified against 2026 competition)

See also