Skip to main content
Glama
awkoy

notion-mcp-server

by awkoy

Notion MCP Server — Connect Claude, Cursor, VS Code & Codex to Notion

npm version npm downloads License: MIT

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_here

add-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 --env flag. Without it the entry is written without a token, and every call fails with an auth error.

Or install in one click:

Install in Cursor Install in VS Code Claude Desktop extension

  • Cursor: replace YOUR_NOTION_TOKEN in the generated entry.

  • VS Code (Copilot agent mode): it asks for the token and stores it as a secret.

  • Claude Desktop: double-click the .mcpb file (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@awkoy

The 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-server

Codex (~/.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:latest

3. 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 (mcp.notion.com)

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

Notion open-source server

—

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_found on 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

NOTION_TOKEN

✅

—

PAT (ntn_…) or Internal Integration secret

NOTION_PAGE_ID

—

—

Default parent for create_page / create_database when no parent is passed (page URL or id)

NOTION_RATE_LIMIT

—

3

Requests per second (Notion's documented limit)

NOTION_READ_ONLY

—

—

true disables every write operation

NOTION_ALLOWED_OPERATIONS / NOTION_BLOCKED_OPERATIONS

—

—

Allowlist / blocklist of operations, see Restricting operations

NOTION_CONFIRM_DESTRUCTIVE

—

—

true asks you before a destructive operation runs

NOTION_UPLOAD_ROOT

—

—

Directory upload_file's local path source is confined to (/ for no limit). Unset: refused over HTTP, dot-named paths and system and app-data folders refused over stdio, see Files

NOTION_UPLOAD_MAX_BYTES

—

1073741824 (1 GiB)

Largest file upload_file accepts from any source

NOTION_UPLOAD_URL_TIMEOUT_MS

—

30000

Time limit for fetching a url source, redirects and body included

NOTION_UPLOAD_ALLOW_PRIVATE_URLS

—

—

true lets a url source reach private, loopback and link-local addresses

NOTION_FILE_URLS

—

full

ref swaps Notion's long signed file URLs for short refs, see Files

HTTPS_PROXY / HTTP_PROXY

—

—

Send all outbound traffic through a proxy

NOTION_DAILY_LOG_PAGE_ID

—

—

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_ROOT to 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, .env and .git included, 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=true lifts that for an intranet. The fetch stops after NOTION_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/mcp

env

default

meaning

MCP_TRANSPORT

stdio

set to http to enable HTTP

PORT

3000

listen port (0 = OS-assigned)

HOST

127.0.0.1

bind address; 0.0.0.0 exposes it externally (only with MCP_AUTH_TOKEN)

MCP_AUTH_TOKEN

—

when set, every /mcp request must send Authorization: Bearer <token>

MCP_ALLOW_UNAUTHENTICATED

off

true lets a non-loopback HOST start without MCP_AUTH_TOKEN, for when an authenticating proxy sits in front

MCP_ALLOWED_HOSTS

localhost + bound host

comma-list for the DNS-rebinding Host allowlist

MCP_ALLOWED_ORIGINS

localhost origins

comma-list for the browser Origin allowlist

⚠️ Whoever reaches /mcp acts as your NOTION_TOKEN. On loopback, the default, that means local processes only. A non-loopback HOST refuses to start without MCP_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

create_page, get_page, set_page_title, set_page_property, set_page_properties, archive_page (alias: trash_page), restore_page, search_pages, move_page, get_page_markdown, update_page_markdown

Blocks

append_blocks, get_block, get_block_children, update_block, delete_block, batch_mixed_blocks

Databases

create_database, query_database, update_database, delete_database

Data sources

list_data_sources, get_data_source, update_data_source, delete_data_source, list_data_source_templates

Views

list_views, get_view, query_view, create_view, update_view, delete_view

Comments

list_comments, add_page_comment, add_discussion_comment, get_comment, update_comment, delete_comment

Users

list_users, get_user, get_bot_user (alias: get_self)

Files

upload_file, list_file_uploads, get_file_upload, get_file_url, get_image

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_TOKEN in your client config, then that the token is still active at app.notion.com/developers/tokens. Installed with add-mcp without --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 parent in the call, or set NOTION_PAGE_ID.

  • multi_source_database: the database has several data sources. Call list_data_sources, then pass a data_source_id instead of the database_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_TOKEN or -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 test

Architecture, 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 tools
notion_describeNotion DescribeA
Read-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.

NameRequiredDescriptionDefault
operationYesOperation name to describe, as listed by notion_read / notion_write.

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 ReadA
Read-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).

NameRequiredDescriptionDefault
payloadYesOperation parameters. Pass either single-op fields directly, or { items: [...], atomic?, idempotency_key?, concurrency? } for batch.
operationYesThe 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

A4.8/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 WriteA
Destructive

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).

NameRequiredDescriptionDefault
payloadYesOperation parameters. Pass either single-op fields directly, or { items: [...], atomic?, idempotency_key?, concurrency? } for batch.
operationYesThe 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

A5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

  1. 2 tool updatesv3.3.0
    • Changednotion_read1 field changed
      • changedInput schema / properties / operation / enum
        Previous 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"
        +]
    • Changednotion_write1 field changed
      • changedInput schema / properties / operation / enum
        Previous 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"
        +]
  2. 4 tool updatesv3.0.1
    • Changednotion_describe2 fields changed
      • changedInput schema / $schema
        Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
      • changedInput schema / properties / operation / description
        Previous value: -"Operation name to describe."New value: +"Operation name to describe, as listed by notion_read / notion_write."
    • Removednotion_execute
    • Addednotion_read
    • Addednotion_write
  3. 15 tool updatesv1.0.1
    • Removedappend_block_children
    • Removedarchive_page
    • Removedbatch_append_block_children
    • Removedbatch_delete_blocks
    • Removedbatch_mixed_operations
    • Removedbatch_update_blocks
    • Removedcreate_page
    • Removeddelete_block
    • Addednotion_describe
    • Addednotion_execute
    • Removedrestore_page
    • Removedretrieve_block
    • Removedretrieve_block_children
    • Removedsearch_pages
    • Removedupdate_block
  4. 13 tool updatesv1.0.0
    • First observedappend_block_children
    • First observedarchive_page
    • First observedbatch_append_block_children
    • First observedbatch_delete_blocks
    • First observedbatch_mixed_operations
    • First observedbatch_update_blocks
    • First observedcreate_page
    • First observeddelete_block
    • First observedrestore_page
    • First observedretrieve_block
    • First observedretrieve_block_children
    • First observedsearch_pages
    • First observedupdate_block

TDQS

A4.7/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityActive
ResponsivenessWithin a week

Related MCP Connectors

Related MCP Servers

  • -
    license
    Not graded
    quality
    Not graded
    maintenance
    An 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.
    322,412 npm
    -
  • A
    license
    A
    quality
    C
    maintenance
    An MCP server for Notion API with optimized token efficiency and full database property filtering, enabling AI assistants to manage pages, databases, and blocks.
    32
    23 npm
    1
    MIT