Notion-Desktop-MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| notion_launchA | Start (or restart) Notion in debug mode so the other tools can connect, or back to normal mode. It RESTARTS Notion (nothing is lost, Notion saves continuously); ask the user first. Windows tested; macOS untested. |
| notion_statusA | Check the connection: debug port, workspace, open tabs, active page and access level. Call first. |
| notion_openB | Open a Notion page by URL or id in the active tab. |
| notion_outlineA | List the page blocks as [depth, type, id, first 80 chars]. Use the ids for insert/delete. |
| notion_readB | Read the page (or some blocks) as Markdown. |
| notion_insertA | Insert Markdown as new blocks (headings, lists, to-dos, quotes, code incl. ```mermaid, tables, links). Never edits existing blocks; rolls back if any existing block disappears. |
| notion_create_databaseA | Create a full database in ONE step from a Markdown table (header row = property names, other rows = entries). Much faster than adding rows/cells one by one: pastes the table, turns it into a database and names it. Columns start as text; change types afterwards with notion_run_code (n.db.headerMenu) if needed. |
| notion_delete_blocksA | Delete blocks by id. Without confirm:true it only previews. Text blocks are saved as Markdown to the local deletion log (restore with notion_restore_blocks); child pages and databases go to Notion Trash (restore with notion_restore_page). Guest/shared workspaces also need allow_shared:true; only after the user said yes. |
| notion_list_deletionsB | List blocks deleted through this server (newest first) with their Markdown backups. |
| notion_restore_blocksA | Put deleted blocks back where they were (as new blocks, from the Markdown backup). Default: the latest unrestored deletion. Child pages/databases are not in the backup; use notion_restore_page for those. |
| notion_trash_pageA | Move the current page to Notion Trash (30 days, restorable). The title must match exactly. Without confirm:true it only previews. Guest workspaces usually disallow this. |
| notion_restore_pageA | Restore a page or database from Notion Trash, by URL (opens it and clicks "Restore page") or by exact title (searches the sidebar Trash of the current workspace). |
| notion_switch_workspaceB | Switch the Notion window to another workspace/account by name. Tell the user, and switch back when done. |
| notion_screenshotB | Screenshot of the active Notion page (to check layout/diagrams). |
| notion_run_codeA | Escape hatch: run |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Most tools have clearly distinct roles (outline vs read, insert vs delete, trash_page vs restore_page). The closest overlaps are notion_delete_blocks vs notion_trash_page and notion_restore_blocks vs notion_restore_page, but descriptions explicitly clarify the block-vs-page distinction. notion_run_code overlaps everything but is explicitly framed as a last-resort escape hatch, which mitigates the ambiguity.
Every tool uses a consistent notion_ prefix with lowercase snake_case, making the set highly predictable. Minor deviations: some names are bare verbs (notion_read, notion_insert, notion_open) while others are verb_noun (notion_create_database, notion_delete_blocks), and a couple are noun-only (notion_status, notion_screenshot).
Fifteen tools sit at the top of the well-scoped range and each maps to a real workflow step: connection/status, navigation, reading, writing, deletion/restore lifecycle, and workspace switching. No obviously redundant tool bloats the set.
Read, insert, delete/restore, trash/restore, and page creation from Markdown tables are covered, but there is no tool to edit existing block content (notion_insert explicitly never edits) and no general page search by title. Database operations beyond one-shot creation (adding rows, changing property types) fall back to notion_run_code rather than a dedicated tool, which is a notable gap for a Notion surface.