# Connecting Claude to Notion hands it every page you can open

> Yes, through Notion's hosted MCP server. What the setup guides skip is that the connector acts with your full Notion permissions, which on a team is a lot.

Source: https://baalda.com/blog/can-claude-connect-to-notion
Site: Baalda, https://baalda.com
Published: 2026-10-12

**Short answer.** Yes. Notion hosts an MCP server at mcp.notion.com/mcp, and one OAuth grant lets Claude search, read and write your pages. Notion's help page states that MCP tools act with your full Notion permissions and can access everything you can access, so what Claude reaches is your whole workspace scope, not a page you picked.

Yes, and it takes one command. The interesting part is not the setup, it is the sentence on Notion's own help page that the setup guides stop just short of.

Notion hosts an MCP server at `https://mcp.notion.com/mcp`. You authorise it once with OAuth and Claude can search, read, create and update your pages. Anthropic's Claude Code documentation uses Notion as its worked example for a remote server:

```bash
claude mcp add --transport http notion https://mcp.notion.com/mcp
```

In Claude Desktop or on claude.ai it is a connector you click instead. Either way the grant is the same one, and Notion describes it plainly: MCP tools "act with your full Notion permissions" and "can access everything you can access." That is a single sentence and it decides everything else in this post. It is also the thing Baalda answers differently, by making the list of pages the assistant can see be the permission check rather than a thing you check afterwards.

## What can Claude actually do inside Notion?

More than most people expect. Notion's supported-tools page lists `notion-search` and `notion-fetch` on the read side, and `notion-create-pages`, `notion-update-page`, `notion-move-pages`, `notion-duplicate-page`, `notion-create-database` and `notion-create-comment` on the write side. There is also `notion-get-users`, which returns workspace members with their IDs, names and emails, and `notion-query-data-sources`, which queries data sources with SQL.

So this is not a read-only research connection. Once connected, Claude can create pages, edit existing ones, move them to a different parent, and comment on them, as you.

The good news first, because it is real: Notion's help page states that "MCP does not bypass Notion permissions." A page you cannot open does not become readable because an assistant asked for it. The connector cannot escalate.

What it also cannot do is go the other way. There is no documented way to hand the connector a scope smaller than yourself. Notion's developer docs say the client can "read and update content that you can access in the selected Notion workspace," and the workspace is the unit. I could not find a statement in either the help page or the developer guide describing a per-page or per-teamspace selection during the OAuth flow, so treat the absence as unconfirmed rather than as a documented "no".

## Why does this land differently on a team?

Because on your own, "everything you can access" is your own notes, and the grant is honest. On a team of twenty, your access is twenty people's work, and you are granting all of it in one click to a client running on your laptop.

Notion is straight about this. The same help page says that "MCP works best for individual workflows where you're connecting your personal AI apps to your Notion workspace." That is a product telling you the honest shape of the feature, and it is worth taking at face value rather than reading past.

The admin controls follow the same grain. Notion's documentation says admins on the Enterprise plan can "Approve specific AI apps and MCP clients that can connect to Notion MCP" and "Block any tool that is not explicitly approved." Those are decisions about **which client** may connect, not about **which pages** it may reach once it has. There is one blunt instrument, a Disconnect All Users button that "disconnects every external AI tool and MCP client that is connected to the workspace through Notion MCP", and even that comes with a caveat Notion publishes itself: "If a tool was connected before it was removed from the approved list, it may still appear under Connected tools because we cannot revoke existing tokens for previously connected tools."

Put those together and the team-level question is not "can Claude connect to Notion". It is: after it connects, what is the smallest thing it can see, and how would anyone find out?

## What does a narrower grant look like?

Baalda is a team second brain built on plain markdown files on your own disk. Several people edit the same note at once over a CRDT, access is set per file and per folder, it is open source under Apache-2.0 and self-hostable, free to run locally with an optional managed Team plan. It serves MCP at `POST /api/mcp` over Streamable HTTP, authenticated with a per-person token you mint in Vault Settings → MCP.

The mechanism that answers the question above is the listing itself. When an assistant calls `list_notes`, the server does not hand back the folder and leave filtering to the client. It resolves each note against the caller's effective permission, drops every note that comes back as `none`, and returns the permission alongside the title:

```json
{
  "docId": "0f1c…",
  "folderId": "9a22…",
  "title": "Pricing decision, Q3",
  "relPath": "decisions/pricing-q3.md",
  "permission": "edit",
  "updatedAt": "2026-10-11T09:14:22.108Z"
}
```

Two things follow from that shape. The assistant's map of the vault is already cut to its grants, so there is no row it can see the title of but not the body, which is the leak that usually survives a permission layer bolted on at the end. And `permission` arrives with the title, so the assistant knows a note is `view` before it tries to write to it rather than after.

The audit half uses the same door. `list_resource_access` takes one folder or file and returns every member's effective access to it, resolved after their vault-level role, Everyone access and any locks. It is owner and admin only, and it runs over the same `POST /api/mcp` endpoint the assistant uses, so "what can this reach" is a question you can ask through the connection rather than about it. `get_access_default` and `set_access_default` do the same for the row that decides what a new member sees on the day they join.

Revocation is the ordinary kind. Every request resolves its token through one gate, which re-checks the person's membership on each call, so a deleted token or a removed member stops working on the next call rather than at the end of a session.

## Where does this not help?

Four places, and they matter.

**A token is still bound to a person, not to a job.** A Baalda MCP token resolves to one user inside one vault, and there is no per-token tool list or path prefix. An assistant holding your token sees what you see, exactly like Notion's connector. If you want it to see less, the answer is a member account with less access that mints its own token, not a cleverer token. That is a real limit, not a rounding error, and it is the same structural shape as the thing this post is critical of. The difference is only that "what you see" in Baalda is already per folder and per file, so a narrow member account is a thing you can actually build.

**There is no workspace-level approval list.** Notion Enterprise lets an admin allow or block MCP clients across the whole workspace. Baalda has nothing equivalent. If your control requirement is "only these three AI clients may connect at all", Notion does that today and Baalda does not.

**The vault is the boundary, so this is scoping inside a vault.** Connecting an assistant to one vault does not reach the others, but that is a coarse line, not a policy engine.

**And Notion is better at being Notion.** If your team's knowledge is relational databases with views, forms and rollups, markdown files are a downgrade and you should not pretend otherwise. Notion's connector exposes `notion-query-data-sources` with SQL because there is structured data underneath worth querying. A folder of `.md` files has no equivalent. The case for moving is about ownership and permissions, not features, and [where Baalda and Notion actually differ](/compare/notion) is worth reading before anyone migrates anything.

## So should you connect Claude to Notion?

If the workspace is yours, yes, with no hesitation. The connector is well built, the setup is one command, and the write tools are genuinely useful.

If the workspace is your team's, connect it knowing what you granted, and ask the two questions the setup guides do not. What is the largest thing this client could read if it were pointed somewhere unhelpful, which on Notion today is everything you can open. And who, other than you, could find out what it touched.

Those questions are not really about Claude. They are about whether the permission model of the place your team keeps its knowledge was designed for one more reader who is not a person. If you want the longer version of that argument, [an MCP server for team notes has to know who is asking](/blog/mcp-server-team-notes) covers the identity half, and [per-file permissions](/blog/obsidian-per-file-permissions) covers what happens when the file layer has no opinion at all.

## FAQ

### Can Claude write to my Notion pages, or only read them?

It can write. Notion's supported-tools list for the hosted MCP server includes `notion-create-pages`, `notion-update-page`, `notion-move-pages`, `notion-duplicate-page`, `notion-create-database` and `notion-create-comment` alongside the read tools `notion-search` and `notion-fetch`. So a connected client can create a page, edit an existing one, move it to a different parent and comment on it, acting as you.

### Does connecting Claude to Notion let it see pages I do not have access to?

No. Notion's help page states that "MCP does not bypass Notion permissions", so a page you cannot open does not become readable because an assistant asked for it. The connector cannot escalate. What it also cannot do is take a scope smaller than you: the documented unit is the workspace you authorise, described as content "that you can access in the selected Notion workspace".

### Can a Notion admin control which AI tools connect to the workspace?

On the Enterprise plan, yes, at the level of the client rather than the content. Notion's documentation says admins can "Approve specific AI apps and MCP clients that can connect to Notion MCP" and "Block any tool that is not explicitly approved". That decides which client may connect, not which pages it reaches once connected, and there is no per-page or per-teamspace scope in that control.

### What happens when I disconnect an AI tool from Notion MCP?

There is a Disconnect All Users button that, in Notion's words, "disconnects every external AI tool and MCP client that is connected to the workspace through Notion MCP". It is all or nothing. Notion also publishes a caveat worth reading before you rely on it: "If a tool was connected before it was removed from the approved list, it may still appear under Connected tools because we cannot revoke existing tokens for previously connected tools."

### Is there a way to give an AI assistant access to only part of a team's notes?

Not through Notion's connector, which grants your whole workspace scope. The approach that does work is to make the permission check part of the listing itself. In Baalda, `list_notes` over `POST /api/mcp` resolves every note against the caller's effective permission, drops anything that comes back as `none`, and returns `edit` or `view` next to each title, so the assistant's map of the vault is already the access-control list. The honest limit is that the token is still bound to one person, so an assistant carrying your token sees what you see.