Notion MCP Server

The server authenticates every call with the single Notion integration token the operator puts in its environment. How much that token can reach is decided entirely in Notion (the integration's capabilities and which pages are shared with it); the server itself does not narrow it, and read and write tools use the same credential. No tool can change the integration's own permissions or sharing. An opt-in HTTP mode can instead accept a per-connection Notion token from each client, which is off in the scored configuration.

As a tool server it relies on the MCP host to ask the user before acting. What it provides is a label on every tool, derived from the HTTP method: GET tools are marked read-only and everything else is marked destructive, so no write tool is presented as safe, although two read-only search and query tools are also marked destructive. There is no preview or dry-run, and no server-side read-only mode. If a host auto-approves or the user approves the wrong call, page content can be overwritten, blocks and pages moved to trash, and comments posted; most of that can be recovered from Notion's trash and page history.

Each tool maps to one Notion API endpoint with a typed input schema generated from the bundled spec, and every request goes to the fixed api.notion.com server, so there is no general URL fetch, shell or query language. The server does not validate arguments against those schemas itself; it decodes JSON-looking strings and forwards them, relying on Notion's API to reject bad input. With no flags all 24 tools load, including page overwrite, block deletion and schema updates, and there is no option to select a smaller or read-only set. A generic local-file upload helper exists in the HTTP client, but no operation in the shipped spec uses it.

The server never runs model-influenced code: there is no shell, subprocess, eval or template execution anywhere in its source, and tool calls only become HTTPS requests to Notion's API. The one eval in the source is inside a commented-out block. The optional Docker image runs the same Node process and adds no execution path.

Page content, blocks and comments, which other workspace members, guests or imported content may have written, are returned to the model as the raw Notion API JSON, with nothing marking them as third-party text. In the default configuration the same session can read that content, read every page shared with the integration, and write pages or post comments, and nothing in the server separates those. A successful prompt injection can therefore copy private page content into a page or comment the attacker can read, without a human involved unless the host asks. Deletions go to Notion's trash rather than being permanent.

The server keeps no memory, retrieval store or conversation history, and it reads nothing from the user's working directory: the API spec is loaded by an absolute path inside its own install directory and configuration comes only from environment variables set in the MCP host's config. Nothing the model reads can persist into later sessions through the server.

The server loads no plugins, MCP servers, remote tools or model files at runtime; its tools come only from the OpenAPI spec bundled with the package. How the host installs the server itself (for example an unpinned npx command) is the project's own distribution and is out of scope here.

The Notion token is read from the environment and only ever attached to outgoing API requests; it is never returned to the model. The server's logging is deliberately thin: failed API calls log only the HTTP status, tool errors log only the error message, and the optional per-connection token is logged only as a redacted prefix. There is no telemetry, crash reporting or stored transcript. Page content that itself contains secrets is passed to the model unfiltered, and the integration token is long-lived, though limited to the pages shared with it.

The server keeps no record of what it does. A successful tool call writes nothing at all, and a failed one prints only an error message or HTTP status to stderr, without the tool's arguments, the page it touched or a timestamp. After an incident the only trace is whatever the MCP host logged and Notion's own page history.

The server sets no bounds on its own work: Notion API requests have no timeout, response size is not capped, and there are no rate limits on writes or comments. The only limits are caller-chosen page sizes defined by Notion's API (up to 100 items per page) and Notion's own server-side rate limits, plus a small cap on how many times a string argument is JSON-decoded. A runaway host loop can keep editing pages until Notion throttles it.