Notion MCP Server

The official Notion MCP server: give Claude, Cursor, and Copilot typed access to your Notion pages, databases, and comments.

Free· Server is free and MIT-licensed; a paid Notion workspace is only required for features gated behind Notion's own plans. Notion tiers: Free / Plus $10 per user/mo / Business $18 per user/mo / Enterprise (custom).MCP Servers

Visit website →

Best for

Teams already living in Notion who want Claude, Cursor, or Copilot to read specs, query project databases, draft pages, and leave comments through a standard MCP surface without building a custom API client.

Skip if

Users who need OAuth-based per-user login rather than a shared integration token, or workflows that require destructive admin operations (deleting databases, bulk workspace migrations) not exposed by the server.

Notion MCP Server is the official Model Context Protocol server maintained by Notion (makenotion) that lets any MCP-compatible client — Claude Desktop, Claude Code, Cursor, Zed, GitHub Copilot CLI, and other agent hosts — read and write a Notion workspace through a typed tool interface. It wraps the Notion REST API behind roughly two dozen MCP tools covering pages, blocks, data sources (the v2 successor to the old database_id addressing), comments, search, and templates, plus two Markdown-native endpoints (retrieve-page-markdown and update-page-markdown) that dramatically cut token usage compared to walking the block tree JSON-first. Authentication is a Notion internal-integration token (NOTION_TOKEN) with per-page and per-database access explicitly granted from the Notion side, so scope is bounded by what the human shares with the integration rather than by broad OAuth consent. It ships as an npm package (@notionhq/notion-mcp-server, launchable via npx with zero install) and as an official Docker image (mcp/notion), and supports both stdio and streamable HTTP transports — the HTTP mode accepts bearer tokens and per-request token passthrough, which is what you want if you are fronting the server for multiple tenants or from a hosted agent runtime. Typical workflows: an agent that drafts weekly reports into a Notion page, a research assistant that queries a projects database and appends findings, a meeting-notes pipeline that inlines transcripts as Markdown, or a Claude Code session that reads a spec page and files follow-up comments. It is the reference implementation of the MCP contract for Notion, so behaviour tracks the API's own semantics closely and breaking changes (the v2 data_source_id migration, for example) are called out in the README.

Editor's take

This is the MCP server I reach for first when an agent needs to touch Notion — being the official implementation matters because the API's data_source vs database_id churn would be painful to track in a community fork. The Markdown endpoints are the quiet win: they make long-page editing actually tractable for a token-budgeted agent. Just remember that the security model is whatever you granted the integration, not whatever the human user can see.

— The AI Tool Bible editorial team

Pros

✅ Official and actively maintained by Notion, so the tool surface tracks the real API rather than a community reverse-engineering
✅ Markdown read/write endpoints make page editing dramatically more token-efficient than raw block JSON
✅ Runs via npx or Docker with no build step; wiring into Claude Desktop, Cursor, or Copilot CLI is a small JSON snippet
✅ Both stdio and streamable HTTP transports, with bearer-token auth and per-request token passthrough for multi-tenant hosting
✅ Permission scope is bounded by which pages you share with the integration in Notion, giving fine-grained blast-radius control
✅ MIT-licensed and easy to fork if you need custom tool shapes or additional guardrails
✅ Broad coverage: pages, blocks, data sources, comments, search, templates, and content moves

Cons

⚠️ Internal-integration tokens are static secrets; there is no first-party OAuth flow in the local server yet (a remote OAuth version is hinted but not shipped)
⚠️ V2.0 dropped the old database_id tools in favour of data_source_id, so older agent prompts and any scripts that hard-coded the previous tool names need to be updated
⚠️ Intentionally omits destructive operations like deleting databases, which is safe but occasionally frustrating for cleanup workflows
⚠️ README itself flags a non-zero risk of exposing workspace data to an LLM; you need to think about read-only integrations for sensitive spaces
⚠️ Requires a per-page or per-database access grant in Notion for every resource the agent should see — easy to forget and a common cause of empty query results
⚠️ Rate limits, pagination quirks, and schema oddities are inherited from the underlying Notion API and are not smoothed over by the server

Use cases

AI agent drafting weekly status reports into a Notion pageResearch assistant querying a projects database and appending findingsMeeting-notes pipeline inlining transcripts as Markdown blocksClaude Code reading a spec page and filing follow-up commentsCross-workspace search from a chat clientAutomated triage that comments on pages by title matchTemplate-driven page creation under a specified parentKnowledge-base RAG grounding pulled live from Notion pages