Notion MCP vs an Obsidian Vault for AI Agents

Choose Notion through its MCP server when the notes are a team’s shared workspace, with databases, permissions and people editing in the browser, and the agent should work inside that. Choose an Obsidian vault when the notes are yours, live on your machine and are plain Markdown files, because an agent can read and edit them with ordinary file tools, no server and no sign-in. The difference is not really Notion against Obsidian. It is a hosted service that the agent reaches through a curated set of tools and your account, against a folder that the agent reaches the same way it reaches your code. Almost every trade-off below follows from that.

What the Notion server can and cannot do, tool by tool, is in what Notion MCP can do, and Notion’s built-in assistant is compared in Notion MCP vs Notion AI. This post sets Notion beside the local alternative.

How the agent gets in

Notion MCP is a remote server Notion hosts at https://mcp.notion.com/mcp. Notion’s getting-started guide↗ (opens in a new tab) says it currently requires the OAuth sign-in in a browser, and lists non-interactive authorisation for automated workflows as something still in development. Notion’s earlier open-source server, which took a bearer token, is no longer actively maintained. So Notion MCP is built for a person sitting at a client such as Claude, ChatGPT or Cursor, not for a job that runs at night.

An Obsidian vault needs none of that. Obsidian’s help on data storage↗ (opens in a new tab) describes a vault as a folder on your local file system, with notes stored as Markdown plain text, and says other editors can change the files while Obsidian refreshes to keep up. An agent with file access, such as Claude Code started in the vault folder, reads notes with its read tool, searches them with grep, and edits them like any text file, under its own approval prompts.

# Notion: add the hosted server, then sign in with /mcp
claude mcp add --transport http notion https://mcp.notion.com/mcp

# Obsidian: no server; start the agent in the vault folder
cd ~/Notes/MyVault && claude

There are two more doors into a vault. Obsidian now ships an official command-line interface; Obsidian’s CLI documentation↗ (opens in a new tab) says anything you can do in the app can be done from the command line, and that the app must be running. And community plugins expose a vault over a local MCP server or HTTP API, so any MCP client can use it. Those are community projects, not Obsidian’s, which matters for the next section.

Whose permissions, and how much of them

Notion MCP works as you. Notion’s help page on MCP↗ (opens in a new tab) says its tools act with your full Notion permissions and can reach everything you can. On the Enterprise plan, workspace owners can approve which AI apps and MCP clients may connect, block the rest and disconnect everyone at once. Below that, the controls are your own account’s access and which client you trust.

A vault has no permission model of its own. Whatever can read the folder can read every note, and the limits are the ones your agent sets: which folders it may open, and whether it asks before an edit. A plugin that serves the vault to agents is more exposed. Obsidian’s plugin security page↗ (opens in a new tab) says Obsidian cannot reliably restrict plugins, so they can read files on your computer, connect to the internet and install other programs, and it recommends an independent audit before using one with sensitive data. Community plugins are off by default in Restricted Mode.

Privacy: local is not the same as private

A vault keeps your notes on your disk rather than on a company’s servers, which is a real difference for the notes the agent never touches. It does not change what happens to the notes it does read. Whatever an agent reads, from a vault or from Notion, goes to the model as part of the conversation, under the terms of whichever model provider runs it. If a note should not reach a model, keep it out of the folder the agent can see, or out of the pages your Notion account can reach while the agent is connected.

Both routes share one risk. A note can contain text written to look like an instruction, whether pasted from a web page, an email or a shared page someone else edits. The agent reads it as content, and a careful setup keeps it that way. The patterns that help are in MCP security best practices.

Sync and sharing

• Notion is already shared. Everyone with access sees the same page the moment the agent changes it, which is the point for a team and the risk for a mistake.
• A vault is only on the machines you sync it to. Obsidian offers Sync as an add-on service with version history, and its help lists Dropbox, iCloud, OneDrive and Git among other options.
• Git is worth a thought for agent work in particular. A vault under Git turns every agent edit into a diff you can read and revert, which is the closest a folder gets to a history of who changed what.
• An agent in the cloud, such as a scheduled job on a server, can reach Notion anywhere once signed in, but can reach a vault only if the files are on that machine.

What agents do well with each

With Notion, the agent is good at structured, shared work: querying a database of meeting notes, filling in properties on a hundred rows, drafting a page in a team space, or searching across a workspace it would take you an afternoon to read. Notion’s tools understand pages, databases and views, so the agent works with the structure rather than around it. The limits are Notion’s: the tools on offer, your plan, and the request limits covered in Notion MCP with Claude Code.

With a vault, the agent is good at the things it already does with code: grep across thousands of notes in a second, rename a tag everywhere, split a long note into three, fix front matter in bulk, or compare a draft with the notes it came from. There is no request limit and nothing to install. The catch is that it is editing raw files. Obsidian can update internal links when you rename a note inside the app; a rename the agent does on disk is just a file move, so ask it to fix the [[links]] that pointed at the old name, and commit before large changes.

A short way to decide

• The notes belong to a team and live in Notion already: Notion MCP, with the agent reading first and writing only after you have seen what it does.
• The notes are yours, in Markdown, and you want the agent to reorganise or mine them: a vault, reached as files, under Git.
• You need a job to run with nobody there: a vault on that machine, or wait for Notion’s non-interactive sign-in. Do not build on the unmaintained Notion server.
• You are tempted by a community plugin for the vault: only if file access is not enough, and after reading its code or trusting its author.

Notes are not a task list

Either tool can hold a to-do list, and agents will happily keep one in a note. What neither gives you is a list the agent works through with a role of its own, where each move is recorded under its name. That is what fenbs is for: a task board where an AI assistant is a member, connects over MCP with a browser sign-in, holds your role narrowed by the scopes you tick, and every change shows in History as, for example, “Claude via Sam”. Standing guidance for assistants lives in AI context on the board, so a new assistant reads it the moment it connects. Notes stay in Notion or the vault; the work to be done lives on the board.