notion-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NOTION_TOKEN | Yes | Your Notion API key from Notion Developers | |
| NOTION_PAGE_ID | Yes | The ID of your Notion page where the integration is enabled |
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
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| notion_readA | 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). |
| notion_writeA | 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). |
| notion_describeA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| create_task | Create a new task page in Notion with optional status and due date. |
| weekly_review | Summarize tasks marked Done in the last 7 days from a Notion database. |
| find_pages | Search Notion and show the top 5 matching pages. |
| daily_log | Append a timestamped paragraph to a daily-log page in Notion. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| operations-index | Markdown table of every supported operation, batchability, and one-line description. |
TDQS
Scored across 3 tools
notion_read, notion_describe, and notion_write have clearly separated intents: execute a read, fetch schema guidance, or execute a write. There is no overlap between tool purposes, and the payload-level operations are cleanly scoped by tool.
All tool names follow the same notion_ prefix with a single lowercase verb: read, describe, and write. The naming pattern is uniform, predictable, and easy for an agent to reason about.
Three tools is well-scoped for a dispatcher-style server because each tool covers a broad category of Notion operations. The count is not too thin, and each tool earns its place in the set.
The read/write tools cover core Notion workflows including search, page retrieval, database queries, block children, page creation, block appending, updates, and delete/archive operations. The main gap is that the full set of supported operation names is not explicitly enumerated, relying on describe/errors for discovery.