Connect Notion to Claude, ChatGPT and Cursor without handing out the workspace

A Notion workspace is the one system where reading is the sensitive part. Everything ends up in it: the onboarding checklist, the incident write-ups, the comp bands, the half-finished acquisition memo somebody forgot to move. When one person wires Notion into their own AI client, they are the only one who has thought about what that client can now see. When thirty people do it, nobody has.

The instinct is to stop them. The better move is to give them a version that is easier than the shortcut and answers to the access they already have.

Six teams, one wiki, six different reasons

Notion is unusual among the systems a company connects. Engineering, Product, Marketing, People Ops, Support and Legal are not reading different data — they are reading the same pages for different reasons, and the interesting boundary is not which database they touch but which corner of the workspace they belong in.

That shows up in the tool list as an oddity worth noticing. Alongside the ordinary page and database operations sit create_a_notion_legal_hold_user and list_all_notion_legal_holds — a department-of-one capability sitting in the same catalog as the marketing content calendar. Nothing about Notion's own permissions stops a marketing agent from finding those. Nothing about a generic MCP setup does either.

So the question a rollout has to answer is not "should people use AI with Notion" but "when the People Ops lead and a contract designer both ask their agent about the handbook, why do they get different answers?"

Connecting Notion once

In Elaichi this happens in one place, and only once. Open Connections, choose Add connection, pick Notion, optionally set Share with, then Connect. Notion's own authorization window opens, you approve there, and you land back on Connection added.

The part worth slowing down for is that authorization window, because Notion grants are page-scoped by whatever the approver selects. Who clicks Connect decides what this connection can ever see. A grant approved by the People Ops lead reaches a different set of pages than one approved by a platform engineer, and no amount of downstream configuration widens it. If you want the Legal archive out of reach, the cleanest place to arrange that is before the connection exists, not after.

Notion also accepts an API key. Prefer OAuth here anyway: the grant is attributable to a person, it is revocable from Notion's side, and it expires in a way a pasted key does not.

Sharing is where the interesting part starts. A connection can be shared with A member, A team, or Everyone, at View, Use or Edit. Use is the one that matters and the one most people under-appreciate: a colleague granted Use can run tools against your Notion connection without being able to open it, edit it, share it onward, or even see it in their connection list. They exercise a capability they never hold. And because that delegation is re-checked against you every time it resolves, it ends when your own access does.

Ninety-five tools, and why you can actually read them

Notion ships 95 tools, which is small enough to review in an afternoon and large enough that nobody will. It is worth the afternoon once, because the catalog sorts cleanly into four families — users, databases, pages and comments — plus a fifth that belongs to one department.

The read side is the unglamorous majority: list_all_notion_search and list_all_notion_query_database do most of the real work, with get_single_notion_page_by_id and list_all_notion_block_children fetching what a search turned up. An agent holding only those is genuinely useful and cannot change anything.

The write side is smaller and more consequential: create_a_notion_page, update_a_notion_page_by_id, create_a_notion_comment, create_a_notion_block_child. Most teams want these. They are also where an agent misreading an instruction becomes visible to colleagues.

Then there are seven tools that delete things, and two of them — delete_a_notion_legal_hold_user_by_id and its creation counterpart — have no business in any toolbox outside Legal. This is the argument for curating by domain rather than by verb: "no deletes" is a blunt rule that would also strip delete_a_notion_comment_by_id from a support agent cleaning up its own noise, while leaving the legal-hold tools looking like ordinary administration.

A toolbox per team, from one template

Because the six teams want nearly the same tools against different corners of the workspace, Notion is a case where one template does almost all the work.

A template is a reusable definition — a set of tool entries with their overrides and frozen parameters, and deliberately no connections attached. Build one called something like Wiki reader: the search and query tools, page and block reads, comment create. Rename entries to what the people using them would call them. Freeze the arguments that should never be a model's decision — a frozen parameter is stripped out of the schema the model sees and merged over the arguments at execution, so it is neither visible nor negotiable.

Then share it at Use and let each team stamp a toolbox from it, binding their own connection. Engineering's stamp points at a connection whose grant covers the engineering wiki; People Ops' points at theirs. Same tools, different reach, one definition to maintain.

Two things about stamping are worth knowing before you rely on it. It is copy-at-creation, not a live link — editing the template later does not reach into toolboxes already stamped from it. And an entry left without a connection renders as needs connection rather than silently doing nothing, which is the failure you want.

Governing it

Toolbox composition is a design-time decision, and design-time decisions describe what you meant. Restrictions describe what is allowed regardless.

A restriction is an allow-list or a block-list over connectors and individual tools, targeted at a role or at a member. For Notion the useful shape is usually a block-list: name the legal-hold tools, target everyone who is not Legal, and stop thinking about it. Two properties make that hold. It is enforced when tools are listed, so a blocked tool never appears in the agent's options at all — and again when one is called, so there is no path around it. And it is evaluated against the original catalog tool name, so renaming an entry in a toolbox cannot launder it past the rule.

The precedence is worth committing to memory, because it is the opposite of what people assume: a restriction targeting an individual replaces the role's rules for that person rather than merging with them. That makes it a genuine override in both directions — it can loosen as well as tighten — which is why writing one needs a permission of its own rather than coming free with restriction management.

There is also a trap in the roles. Of the eight predefined roles, Auditor is the one most Notion rollouts should be using and most are not: read-only visibility across the audit log, restrictions, connections and tokens, on a seat that does not count against your billable seats. A compliance reviewer who should see every call an agent made to the wiki and change nothing costs nothing.

What the log gives them is specific. Every tool call lands in an append-only record — append-only by construction, not by policy; there is no path in the product that edits or deletes one — carrying who ran it, which connection it went through, and the id of the Notion record it created. That last field is the one that answers the question people actually ask, which is never "did an agent run a tool" but "why does this page have a comment nobody remembers writing". What is deliberately not recorded is the arguments and the results: a tool call's payload is your content, and it does not belong in a log. Expect a short delay before a row appears; it is eventually consistent.

One endpoint, and what your client actually sees

There is one endpoint, and everyone in the organization uses the same address. In the web app, open Connect your AI client and copy it.

What each person gets from it is not the same, and this is the sentence the whole arrangement rests on: the endpoint is scoped to the account that signed in, exactly like the web app. Two people connecting to the identical URL do not see the identical tools. Access is not a property of the connection string.

Signing in brings up a consent screen that deserves more attention than most OAuth screens get. Inside Elaichi a write is confirmed in the moment — you are asked, you agree. Over MCP there is no trusted place to ask, because the thing on the other end could claim its own approval. So the consent screen is the standing approval. Only Read is granted by default; for using Notion through an agent you want Read and Run tools, and you should think hard before granting Delete, which reaches into connected apps and cannot be undone.

One behaviour will surprise you whichever client you use. Past 30 advertised tools — counting the platform's own operations together with your connected ones — individual tool names are replaced by two meta-tools, search_tools and execute_tool. With 95 Notion tools you are comfortably over that line, so your agent will find tools by searching rather than browsing. It is automatic and not a setting. The practical consequence: that search ranks lexically, not semantically, so "query database" retrieves what you want and "help me find information about our roadmap" does not.

Setup is manual in every client and takes about a minute. There is no client ID or secret to generate — the endpoint registers clients automatically.

Connect Notion to Claude

In Claude, open Settings → Connectors, choose Add custom connector, and paste the Elaichi endpoint. Leave OAuth Client ID and Client Secret empty under Advanced settings. Sign in, approve the scopes, and Notion's tools arrive without Notion ever being added to Claude directly.

Two things catch teams out. Claude reaches the endpoint from Anthropic's cloud rather than from your laptop, so a local address will not work. And on Team and Enterprise only an Owner can add a connector at all — everyone else enables it for themselves afterwards and signs in as themselves, which is what keeps each person's Notion pages their own.

Connect Notion to ChatGPT

In ChatGPT, open Settings → Apps and turn on developer mode, which sits under Advanced Settings. Choose Create, paste the endpoint, then run Scan tools. Sign in and approve.

The gate here is commercial rather than technical: MCP needs a Business, Enterprise or Edu plan, it is web-only today, and on Business plans only admins and owners can turn developer mode on. Worth knowing before you promise a rollout date. ChatGPT will also prompt for confirmation on write actions — treat that as a convenience, not the boundary. The scopes you granted are the boundary.

Connect Notion to Cursor

Cursor reads a file on your machine, so this one is per-machine rather than per-account. Open ~/.cursor/mcp.json, or .cursor/mcp.json to scope it to a single repository, and add the endpoint as a url entry under mcpServers alongside anything already there. Reload Cursor, then sign in and approve.

There is no type field and no command to run — Cursor detects the transport from the endpoint itself. Use the per-project file when only one codebase should reach your Notion pages, and remember that setting this up on your laptop does not set it up on your desktop.

From there the prompts are ordinary, in any of the three. Summarise comments added to the product spec page this week. List Notion pages in the roadmap database missing an owner. Create a meeting notes page in the team database.

The second week

The first week is connecting things. The second is the part that decides whether this holds.

Notion OAuth grants are revocable from Notion's side, and a workspace admin removing the integration there will break every toolbox stamped against that connection at once. Reconnect exists for exactly this and is worth knowing about before you need it.

Offboarding is the case that catches people out. Removing a member walks each of their personal connections in turn and makes you choose: Transfer to member, Delete connection, or Leave as is. A shared Notion connection that half of Product depends on should be transferred, not deleted, and you want to know that before the leaving date rather than during it.

The last thing worth setting up early is routing. Connection failures and access requests can go to Slack or email, and the audit stream can forward to Datadog. None of it is interesting on day one. All of it is the difference between noticing that an agent has been failing against a reconnected workspace for a week and finding out when somebody complains.