notion-mcp-server
This server gives MCP clients read/write access to Notion through three tools: notion_read, notion_write, and notion_describe.
Search, read, create, rename, move, archive/restore pages, and edit page properties.
Read and update page content as markdown.
Query, create, update, and delete databases, data sources, and views.
Append, read, update, and delete blocks, including mixed block batches.
List, add, update, and delete comments on pages/discussions.
List users and get user/bot details.
Upload files and retrieve file URLs or images.
Run writes individually or in batches with atomic rollback, idempotency keys, concurrency, and rate-limit retry support.
Inspect operation schemas/examples with
notion_describe.Restrict access with read-only mode, operation allow/block lists, and confirmation for destructive actions.
Run over stdio or Streamable HTTP with optional bearer auth.
Provides tools for reading, creating, and modifying Notion content through natural language interactions, including page operations (creation, archiving, restoration, searching), block operations (retrieval, appending, updating, deleting), and batch operations for efficient content management.
Click on "Deploy 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., "@notion-mcp-servercreate a new page with today's tasks"
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.
Notion MCP Server — Connect Claude, Cursor, VS Code & Codex to Notion
notion-mcp-server is a Model Context Protocol (MCP) server that gives Claude Code, Claude Desktop, Cursor, VS Code, Codex and any other MCP client read/write access to Notion with one token. Your AI can search, create and edit pages, query databases, comment and upload files, in plain language.
Token auth on every Notion plan, Free included. No browser sign-in, so it also runs headless: in CI, cron jobs, background agents and on your own server.
Light on context. Its three tools cost 1,005 tokens at connection, against 17,163 for Notion's open-source server, and page reads come back 82% smaller. Benchmark →
Built for agents. Batched writes with atomic rollback and idempotency keys, retry on rate limits, markdown in and out, and errors that tell the model how to fix the call.
Quick start
1. Get a Notion token. Open app.notion.com/developers/tokens → + New token → name it, pick your workspace → Create token → copy the ntn_… value. A Personal Access Token sees everything you can see, with no per-page sharing. Can't create one? See the other token option.
2. Install it.
npx add-mcp notion-mcp-server --env NOTION_TOKEN=ntn_paste_your_token_hereadd-mcp finds the MCP clients on your machine and writes the config for the ones you pick: Claude Code, Claude Desktop, Cursor, VS Code, Codex, Gemini CLI, Cline, Windsurf, Zed and more. Add -g to install for your user instead of the current project.
Keep the
--envflag. Without it the entry is written without a token, and every call fails with an auth error.
Or install in one click:
Cursor: replace
YOUR_NOTION_TOKENin the generated entry.VS Code (Copilot agent mode): it asks for the token and stores it as a secret.
Claude Desktop: double-click the
.mcpbfile (or drag it into Settings → Extensions) and paste your token. No Node.js needed. New to all this? The step-by-step walkthrough assumes nothing.
Using Claude Code? Install it as a plugin instead. The plugin bundles the server with a Notion workflow skill, which teaches Claude when to search, how to filter a database with where, and how to batch writes. Claude Code asks for the token when you install it (or later with /plugin configure notion-mcp-server@awkoy) and keeps it in your system keychain:
/plugin marketplace add awkoy/notion-mcp-server
/plugin install notion-mcp-server@awkoyThe plugin runs the npm release that matches its own version and needs Node.js 22 or later. It also offers a default parent page and a read-only switch; the plugin's README has the details.
Any client that reads an mcpServers block (Cursor's ~/.cursor/mcp.json, Claude Desktop's claude_desktop_config.json, Cline, Zed, Continue…):
{
"mcpServers": {
"notion": {
"command": "npx",
"args": ["-y", "notion-mcp-server"],
"env": { "NOTION_TOKEN": "ntn_paste_your_token_here" }
}
}
}Claude Code:
claude mcp add notion -s user -e NOTION_TOKEN=ntn_paste_your_token_here -- npx -y notion-mcp-serverCodex (~/.codex/config.toml):
[mcp_servers.notion]
command = "npx"
args = ["-y", "notion-mcp-server"]
env = { NOTION_TOKEN = "ntn_paste_your_token_here" }Gemini CLI: gemini extensions install https://github.com/awkoy/notion-mcp-server asks for the token once and keeps it in your system keychain.
Docker (Podman, OrbStack and colima take the same flags; -i is required for stdio):
claude mcp add notion -s user -e NOTION_TOKEN=ntn_paste_your_token_here \
-- docker run --rm -i -e NOTION_TOKEN ghcr.io/awkoy/notion-mcp-server:latest3. Try it. In a new chat:
"Use Notion to make a page called 'Hello from my agent' and add a checklist of three things to try today."
Your AI calls notion_write and replies with a link to the new page.
Related MCP server: Notion MCP Server
What you can ask
"Find every row in my Tasks database where Status is 'Doing' and tell me which are overdue."
"Rename these 50 pages to the new convention." One batched call, not 50.
"Create a page from my 'Weekly review' template and fill in this summary."
"Rewrite that spec page: fix the headings and add a code sample." The page round-trips as markdown.
"Comment on yesterday's meeting notes with a one-paragraph summary."
"Upload this diagram to the design page."
"Look at the screenshot on that bug report and tell me what's wrong." The model gets the image itself.
Which Notion MCP should you use?
Best for | Auth | Headless / CI | Notes | |
Notion hosted MCP ( | Interactive chat in claude.ai, ChatGPT, Cursor; Notion AI features | OAuth on every plan. MCP tokens on Business and Enterprise, created by workspace owners | Business and Enterprise only | First-party and the largest tool set (meeting notes, SQL across data sources, Custom Agents); several tools need a paid plan or Notion AI |
— | Token | ✅ | Notion calls it deprecated and "no longer actively maintained" | |
This server | Agents, automation, CI, self-hosting, long sessions | Token, every plan | ✅ | Actively maintained; 3 tools, batched and idempotent writes |
To chat with Notion in claude.ai or ChatGPT, Notion's hosted connector is one click. Use this server when an agent runs unattended, when your plan has no MCP tokens, when context cost matters, or when you want it on your own host. Detailed comparison →
Configuration
Token: PAT or internal integration
Both go in the same NOTION_TOKEN env var; only where you get them differs.
Personal Access Token (recommended) | Internal Integration (scoped) | |
Where | app.notion.com/developers/tokens → + New token | app.notion.com/developers/connections → + New connection |
Scope | Everything you can see | Only pages where you clicked • • • → Connect → <integration> |
Use when | Default: personal and team workspaces | You can't create a PAT, or an admin wants explicit per-page scoping |
Who can create a PAT. Workspace owners always can. On Free and Business plans only owners can by default, on Plus every member can, and admins can change the policy on Business and Enterprise. Guests can't.
Expiry and revoking. You pick the lifetime when you create it, a year at most. Revoke it on the same tokens page; it stops working immediately. Details: Notion's PAT guide.
object_not_foundon a page you can see? That's an Internal Integration that was never Connected to the page. Connect it, or switch to a PAT.
Environment variables
Env var | Required | Default | Meaning |
| ✅ | — | PAT ( |
| — | — | Default parent for |
| — |
| Requests per second (Notion's documented limit) |
| — | — |
|
| — | — | Allowlist / blocklist of operations, see Restricting operations |
| — | — |
|
| — | — | Directory |
| — |
| Largest file |
| — |
| Time limit for fetching a |
| — | — |
|
| — |
|
|
| — | — | Send all outbound traffic through a proxy |
| — | — | Only used by the daily-log MCP prompt |
HTTP variables are in Remote / HTTP transport. Upgrading from v1 or v2? Every env var still works; the tool names changed, see MIGRATION.md.
Restricting operations
NOTION_READ_ONLY=true turns off every write. For finer control, NOTION_ALLOWED_OPERATIONS and NOTION_BLOCKED_OPERATIONS take comma-separated operation names or presets: read, write, destructive (archive, trash and delete), or a family (pages, blocks, databases, data_sources, views, comments, users, files). The blocklist wins.
{ "env": { "NOTION_ALLOWED_OPERATIONS": "read" } } // read-only
{ "env": { "NOTION_BLOCKED_OPERATIONS": "destructive" } } // everything except removals
{ "env": { "NOTION_ALLOWED_OPERATIONS": "read,append_blocks,add_page_comment" } }Disabled operations disappear from the tool schemas, so the model never sees them. The server prints what resolved at startup, for example Operation access: 22/48 enabled (allow=read; block=(none)).
To be asked instead of blocked, set NOTION_CONFIRM_DESTRUCTIVE=true: before a destructive operation runs, your client shows a yes/no dialog naming the target. The client has to support MCP elicitation. The full rules, the per-operation list and the limits of per-operation control are in docs/configuration.md.
Files
upload_file accepts base64, a public URL or a local path, up to NOTION_UPLOAD_MAX_BYTES (1 GiB by default). Since the model picks the source, the server guards the two it reads itself:
Local paths. Set
NOTION_UPLOAD_ROOTto the directory uploads may come from; paths outside it are refused, symlinks included. Without it, path sources are off over HTTP, and over stdio a path is refused when it goes through a dot-named file or directory (~/.ssh,~/.aws,.env) or lies under a system or app-data folder (/proc,/dev,~/Library,%APPDATA%), where MCP clients keep your token.NOTION_UPLOAD_ROOT=/turns the limit off. Inside a root every file is readable,.envand.gitincluded, so over HTTP pick a root that holds only files you would hand to whoever can call the server.URLs. http and https only. Every hop, redirects included, must resolve to a public address, so loopback, private networks and cloud metadata endpoints are refused;
NOTION_UPLOAD_ALLOW_PRIVATE_URLS=truelifts that for an intranet. The fetch stops afterNOTION_UPLOAD_URL_TIMEOUT_MS(30 s) or once the body passes the size limit.
Notion's signed file URLs are about 500 tokens each and expire within an hour. NOTION_FILE_URLS=ref replaces them in responses with short notion-file: refs that get_file_url and get_image resolve on demand. How refs work →
Remote / HTTP transport
The server speaks stdio by default. Set MCP_TRANSPORT=http to run it as a Streamable HTTP endpoint for web clients, networked agents and shared deployments:
MCP_TRANSPORT=http PORT=3000 NOTION_TOKEN=ntn_xxx npx -y notion-mcp-server
# -> notion-mcp-server vX.Y.Z running on http://127.0.0.1:3000/mcpenv | default | meaning |
|
| set to |
|
| listen port ( |
|
| bind address; |
| — | when set, every |
| off |
|
| localhost + bound host | comma-list for the DNS-rebinding |
| localhost origins | comma-list for the browser |
⚠️ Whoever reaches
/mcpacts as yourNOTION_TOKEN. On loopback, the default, that means local processes only. A non-loopbackHOSTrefuses to start withoutMCP_AUTH_TOKEN; put TLS in front of it too.
Over HTTP, upload_file takes no local paths unless NOTION_UPLOAD_ROOT is set, since the caller may not be on the server's machine. Base64 and URL sources work as usual, see Files.
claude mcp add --transport http notion https://your-host/mcp \
--header "Authorization: Bearer <MCP_AUTH_TOKEN>"Docker, health checks and protocol versions: docs/http-transport.md.
Tools and operations
Three tools, whichever of the 46 operations you end up calling: notion_read runs reads, notion_write runs writes, and notion_describe returns an operation's JSON Schema with a working example. Every id field also accepts a Notion URL, so paste what Share → Copy link gives you. Call examples, batch options and MCP resources: docs/operations.md.
Per-tool permissions
The read/write split lets you approve reads once and keep writes behind a prompt. In Claude Code's settings.json (where notion is whatever you named the server):
{ "permissions": { "allow": ["mcp__notion__notion_read", "mcp__notion__notion_describe"] } }Operations menu (46 ops, plus two aliases)
Area | Operations |
Pages |
|
Blocks |
|
Databases |
|
Data sources |
|
Views |
|
Comments |
|
Users |
|
Files |
|
FAQ
Does it work on the Notion Free plan? Yes. A workspace owner can create a Personal Access Token on every plan, and the server needs nothing else.
Is there a Notion MCP server without OAuth? This one. It authenticates with a token, so nobody has to click Authorize. Notion's hosted MCP skips OAuth only on Business and Enterprise, with an MCP token a workspace owner creates.
Which clients does it work with? Any MCP client: Claude Code, Claude Desktop, Cursor, VS Code (Copilot agent mode), Codex, Gemini CLI, Cline, Windsurf, Zed, Continue, and local models through any MCP host. More in the FAQ.
Troubleshooting
"Notion auth failed" on every call: the token is missing, revoked or expired. Check
NOTION_TOKENin your client config, then that the token is still active at app.notion.com/developers/tokens. Installed withadd-mcpwithout--env? Re-run it with the flag.object_not_found/ "Could not find …": an Internal Integration only sees pages Connected to it. Connect the page, or switch to a PAT."No parent page configured": pass
parentin the call, or setNOTION_PAGE_ID.multi_source_database: the database has several data sources. Calllist_data_sources, then pass adata_source_idinstead of thedatabase_id.A successful result carries
warnings: the call ran. Each entry names a field that was ignored or a property name that was corrected.Tools don't appear in Claude Desktop: a typo in the token (it must stay inside the quotes), or the app wasn't fully quit (
Cmd+Q) before reopening.Startup logs "Notion auth check failed" but tools work: the startup check is best effort; ignore it if calls succeed.
Docker exits at once or says "NOTION_TOKEN is not set": add
-i, and write-e NOTION_TOKENor-e NOTION_TOKEN=ntn_xxx, not-e NOTION_TOKEN ntn_xxx.
Still stuck? Check the FAQ or open a GitHub issue.
Privacy
The server runs on your machine or your own host and talks only to api.notion.com, over HTTPS, with the token you configure (or through your proxy when HTTPS_PROXY is set). No telemetry, no analytics, no server of ours in the path. The token stays where your MCP client keeps it. get_image fetches only the signed URLs Notion returns for files it hosts. upload_file reads a local file or fetches a URL only when asked to, and refuses URLs that resolve to private or loopback addresses. Notion's own handling of your data is covered by Notion's privacy policy.
Development
git clone https://github.com/awkoy/notion-mcp-server.git && cd notion-mcp-server
npm install && npm run build && npm testArchitecture, running a local build in a client, and the end-to-end test against a real workspace: docs/development.md. PRs are welcome; run npm test before opening one.
License
MIT — see LICENSE.
mcp-name: io.github.awkoy/notion-mcp-server
Available Tools
3 toolsnotion_describeNotion DescribeARead-only
Return the JSON Schema and a working example for one operation, plus which tool runs it (notion_read or notion_write). Use this BEFORE calling the operation when the payload shape is non-trivial (query filters, structured block trees, database property definitions). For simple ops, just call it — errors carry the schema.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Operation name to describe, as listed by notion_read / notion_write. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: the tool returns both a schema and a working example, determines which sibling tool executes the operation, and that errors carry the schema, making the describe call skippable for simple operations. This goes beyond the structured annotations without contradicting them.
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 sentences with no filler. The primary return value is stated first, followed by precise usage conditions and an explicit exclusion case. Every clause 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?
For a lightweight describe tool with one parameter, clear annotations, and no output schema, the description fully covers what the agent needs: what it returns, when to call it, and when to skip it. The mention of notion_read/notion_write links it to its siblings adequately.
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% and the single parameter 'operation' is well-documented in the schema. The description adds only marginal semantic value by clarifying that the operation name is 'as listed by notion_read / notion_write', which is useful but largely redundant with the schema description. Baseline 3 is appropriate.
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 names a specific verb ('Return') and resource ('JSON Schema and a working example for one operation, plus which tool runs it'). It clearly distinguishes this meta-tool from the sibling tools notion_read and notion_write by stating it describes operations rather than performing 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?
Explicitly states when to use it ('BEFORE calling the operation when the payload shape is non-trivial'), gives concrete examples of such cases, and explains when it is unnecessary ('For simple ops, just call it'). This is decisive routing guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
notion_readNotion ReadARead-onlyIdempotent
Run one Notion read operation by name. Nothing is modified.
Call: { operation, payload } — payload carries that operation's fields. Common: search_pages { query }, get_page { page_id }, get_page_markdown { page_id }, query_database { database_id, where? }, get_block_children { block_id }.
Responses are slimmed; pass verbose:true in payload for the raw Notion object. Every id field (page_id, block_id, database_id, view_id, …) also accepts a Notion URL, as copied from Share → Copy link. A block link's #fragment is used for block_id fields and a database link's ?v= for view_id fields.
If the payload is malformed, the error response includes the schema + a working example so you can correct and retry in one round-trip. Call notion_describe(operation) ahead of time only for complex shapes (query_database filters).
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Operation parameters. Pass either single-op fields directly, or { items: [...], atomic?, idempotency_key?, concurrency? } for batch. | |
| operation | Yes | The read operation to run. This list is the complete menu of read operations enabled on this server; notion_describe(operation) returns any operation's full schema. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already declare read-only, idempotent, non-destructive behavior, the description adds substantial operational context: responses are slimmed by default, verbose:true returns raw objects, ids accept Notion URLs, and malformed payloads return schema plus an example for one-round-trip retry. It also discloses URL fragment and ?v= handling, which is beyond the annotations and schema.
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 front-loaded with the core action, then organized into compact paragraphs for call shape, common operations, response behavior, id handling, and error/describe guidance. Every sentence carries operational value, and the dense operation list is appropriate for a multi-operation router.
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 complex multi-operation read tool with no output schema, the description covers the essential call contract, common payload shapes, response slimming, verbose override, id/URL flexibility, malformed-payload recovery, and when to use notion_describe. Nothing critical for correct invocation is missing.
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% for the top-level parameters, but the description adds meaningful semantics beyond the schema by explaining that payload carries operation-specific fields and by listing common operation-field mappings like search_pages { query } and query_database { database_id, where? }. It also explains that every id field accepts Notion URLs and that verbose:true modifies response detail.
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 states a specific verb and resource: 'Run one Notion read operation by name,' and immediately clarifies 'Nothing is modified.' This clearly distinguishes notion_read from notion_write and positions notion_describe as the schema-discovery helper rather than a competing read path.
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?
It gives clear usage context and explicitly tells the agent when to call the alternative notion_describe: only for complex shapes such as query_database filters. It does not explicitly say to use notion_write for mutations, but 'read operation' and 'Nothing is modified' make the boundary clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
notion_writeNotion WriteADestructive
Run one Notion write operation by name. Archive, trash and delete operations remove content — confirm with the user before running them.
Two ways to call: • Single: { operation: "set_page_title", payload: { page_id, title } } • Batch: { operation: "set_page_title", payload: { items: [{page_id, title}, ...], atomic?: false, idempotency_key?: "...", concurrency?: 3 } } create_page, append_blocks, update_block and update_page_markdown also take a markdown string.
Responses are slimmed; pass verbose:true inside payload (single) or per item (batch) for the raw Notion object. Every id field (page_id, block_id, database_id, view_id, …) also accepts a Notion URL, as copied from Share → Copy link.
If the payload is malformed, the error response includes the schema + a working example so you can correct and retry in one round-trip. Call notion_describe(operation) ahead of time only for complex shapes (block trees, database property definitions, batch_mixed_blocks).
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Operation parameters. Pass either single-op fields directly, or { items: [...], atomic?, idempotency_key?, concurrency? } for batch. | |
| operation | Yes | The write operation to run. This list is the complete menu of write operations enabled on this server; notion_describe(operation) returns any operation's full schema. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive and open-world behavior, but the description adds specific operational context: archive/trash/delete remove content, responses are slimmed unless verbose is requested, malformed payloads return schema plus a working example, and ID fields accept Notion URLs. These details materially improve safe invocation beyond what the annotations provide.
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 front-loaded with the core action and the destructive warning, then moves into invocation patterns, response behavior, error recovery, and schema lookup guidance. For a 26-operation dispatcher, every section earns its place and there is no filler.
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 complexity, lack of output schema, nested payload, and destructive annotations, the description covers the important gaps: batch vs single invocation, destructive confirmation, verbose responses, URL-accepting IDs, and error recovery via schema. An agent has enough information to invoke it correctly without opening separate documentation.
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?
Although the schema covers operation and payload at 100%, the payload schema is intentionally generic with additionalProperties, so the description supplies essential semantics: direct single-op fields, batch items with atomic/idempotency_key/concurrency, markdown arguments for selected operations, and verbose placement. It adds substantial meaning beyond the schema's generic shape.
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 opens with a specific verb and resource: 'Run one Notion write operation by name.' It distinguishes this from read and describe siblings by framing it as writes and by pointing to notion_describe only for complex operation shapes.
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?
It gives concrete calling patterns for single vs batch payloads, explicitly warns to confirm archive/trash/delete operations with the user, and routes agents to notion_describe only for complex shapes such as block trees and database property definitions. This is unusually clear about when to use the tool and when to consult the sibling instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v3.3.0- Changed
notion_read1 field changed- changed
Input schema / properties / operation / enumPrevious value: -[ - "query_database", - "list_data_sources", - "get_data_source", - "list_data_source_templates", - "get_view", - "list_views", - "query_view", - "list_comments", - "get_comment", - "list_users", - "get_user", - "get_bot_user", - "get_self", - "list_file_uploads", - "get_file_upload", - "get_file_url", - "get_image", - "search_pages", - "get_page", - "get_page_markdown", - "get_block", - "get_block_children" -]New value: +[ + "query_database", + "get_view", + "list_views", + "query_view", + "list_comments", + "get_comment", + "list_users", + "get_user", + "get_bot_user", + "get_self", + "list_file_uploads", + "get_file_upload", + "get_file_url", + "get_image", + "list_data_sources", + "get_data_source", + "list_data_source_templates", + "search_pages", + "get_page", + "get_page_markdown", + "get_block", + "get_block_children" +]
- Changed
notion_write1 field changed- changed
Input schema / properties / operation / enumPrevious value: -[ - "create_database", - "update_database", - "delete_database", - "update_data_source", - "delete_data_source", - "create_view", - "update_view", - "delete_view", - "add_page_comment", - "add_discussion_comment", - "update_comment", - "delete_comment", - "upload_file", - "create_page", - "set_page_title", - "set_page_property", - "set_page_properties", - "archive_page", - "trash_page", - "restore_page", - "move_page", - "update_page_markdown", - "append_blocks", - "update_block", - "delete_block", - "batch_mixed_blocks" -]New value: +[ + "create_database", + "update_database", + "delete_database", + "create_view", + "update_view", + "delete_view", + "add_page_comment", + "add_discussion_comment", + "update_comment", + "delete_comment", + "upload_file", + "update_data_source", + "delete_data_source", + "create_page", + "set_page_title", + "set_page_property", + "set_page_properties", + "archive_page", + "trash_page", + "restore_page", + "move_page", + "update_page_markdown", + "append_blocks", + "update_block", + "delete_block", + "batch_mixed_blocks" +]
4 tool updates
v3.0.1- Changed
notion_describe2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Input schema / properties / operation / descriptionPrevious value: -"Operation name to describe."New value: +"Operation name to describe, as listed by notion_read / notion_write."
- Removed
notion_execute - Added
notion_read - Added
notion_write
15 tool updates
v1.0.1- Removed
append_block_children - Removed
archive_page - Removed
batch_append_block_children - Removed
batch_delete_blocks - Removed
batch_mixed_operations - Removed
batch_update_blocks - Removed
create_page - Removed
delete_block - Added
notion_describe - Added
notion_execute - Removed
restore_page - Removed
retrieve_block - Removed
retrieve_block_children - Removed
search_pages - Removed
update_block
13 tool updates
v1.0.0- First observed
append_block_children - First observed
archive_page - First observed
batch_append_block_children - First observed
batch_delete_blocks - First observed
batch_mixed_operations - First observed
batch_update_blocks - First observed
create_page - First observed
delete_block - First observed
restore_page - First observed
retrieve_block - First observed
retrieve_block_children - First observed
search_pages - First observed
update_block
TDQS
Scored across 3 tools
The three tools have clearly distinct purposes: notion_read executes non-modifying operations, notion_write executes mutating operations, and notion_describe returns schemas/examples without executing anything. An agent can easily select among them based on intent, and the descriptions reinforce the boundaries.
All tool names follow the same predictable pattern: notion_ + verb (read, write, describe), all in snake_case. There are no naming style deviations or confusing abbreviations.
Three tools is well-scoped for a facade-style server that multiplexes many Notion operations. Each tool earns its place: read, write, and schema discovery cover the necessary interaction modes without unnecessary proliferation.
The surface covers core page, block, and database read/write operations, including search, markdown conversion, batch writes, and lifecycle operations like archive/trash. Minor gaps may exist for peripheral Notion domains such as comments, users, or database schema management, but the main workflows are well supported.
Maintenance
Related MCP Connectors
Hosted Notion MCP server for Claude, ChatGPT and Cursor, with each action switched per account.
An MCP server that integrates with Discord to provide AI-powered features.
- ZapierOAuthcom.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Related MCP Servers
- AlicenseAqualityDmaintenanceA high-performance MCP server that integrates Notion into AI workflows, enabling interaction with Notion pages, databases, and comments through a standardized protocol.833 npm26Apache 2.0

Notion MCP Serverofficial
AlicenseBqualityDmaintenanceAn MCP server that enables AI assistants to interact with the Notion API, allowing them to search, read, comment on, and create content in Notion workspaces through natural language commands.19207,493 npm4,677MIT- -licenseNot gradedqualityNot gradedmaintenanceAn MCP server that enables natural language interaction with the Notion API, allowing users to search, comment, create pages, and access content within their Notion workspace.207,493 npm-
- AlicenseAqualityCmaintenanceAn MCP server for Notion API with optimized token efficiency and full database property filtering, enabling AI assistants to manage pages, databases, and blocks.3210 npm1MIT