Notion MCP server for your AI

A Notion integration starts with access to nothing at all. Open each top-level page or database you want it to use, click the ••• menu at the top right, choose Connections, and add the integration — access then cascades to every child page underneath. Until you do that, search and query_database come back empty even though the credential is perfectly valid.

In Notion, go to Settings → Connections → Develop or manage integrations, or open notion.so/my-integrations directly. Create a new integration, pick the workspace it belongs to, and copy the Internal Integration Secret. That one value is all the connect form asks for — there is no OAuth popup to click through and no token to refresh later.

The secret is issued against a single workspace, and inside it the agent sees only the pages and databases you added the integration to, plus everything nested below them. Search matches on title across that shared set rather than the body text of a page, so the reliable pattern is to find a page by name and then read its blocks. Workspace members and bots come from their own user tools, which is how the agent resolves the person behind a comment or an owner property.

Under Notion's 2025-09-03 API a database is a container holding one or more data sources, and the column schema lives on the data source rather than the database. retrieve_database_data_sources returns the database with its data_sources array, and retrieve_data_source gives you the full properties schema for one of them. If you would rather not walk both levels, query_database still runs a filtered, sorted row query in a single step; query_data_source targets one specific source.

No — the destructive operations here are trash operations. delete_block moves a block to the trash as a soft delete, update_page trashes or restores a page through its archived flag, and update_data_source can set a trash state, so items go to the trash rather than disappearing. The edits worth holding for write approval are schema changes through update_database and update_data_source, because changing a column definition affects every row at once.

Change detection covers pages created, updated, trashed or archived, and page content changing when blocks are added, edited or removed. On the database side it watches databases being created, rows added or updated, a row's status or select property moving to a different value, and rows added to a data source inside a database. It also fires on new comments and on a new person appearing in the workspace. Page created only fires where the integration has access, so the sharing step decides your trigger coverage as well.

No. PopMCP hosts it and gives you a Streamable HTTP MCP URL. There is nothing to deploy, no callback URL to register, and no infrastructure to keep running or patch.

Any client that supports a remote Streamable HTTP MCP server — Claude Desktop, Claude Web, ChatGPT custom connectors, Codex and the Codex CLI, OpenCode and Z.ai's ZCode, as well as editors such as Cursor, Windsurf and Zed. Your client signs in to PopMCP with OAuth; the provider credential never leaves the server.

Loading 30 tool definitions into every conversation burns context before the work starts. PopMCP loads a curated 22-tool set covering the everyday workflows and keeps the rest searchable, so your AI pulls a specialist tool only when a task needs it. You can switch a connection to the full catalog at any time.

A tool is something your AI calls — there are 30 here. A trigger is something PopMCP watches for you: 11 Notion events that can start work on the PopMCP side. Triggers never enter your AI client's context, and none of them ask you to paste a callback URL into Notion.