better-mcp-notion
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NOTION_API_KEY | Yes | Your Notion API key (ntn_...) |
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 | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| readA | Read a Notion page and return it as Markdown with YAML frontmatter. Returns frontmatter fields:
The body contains the page content as standard Markdown. The output can be edited and passed directly to the "write" tool to update the page. Use "depth" to include child pages in a single call (default: 1 = current page only, 2 = include children, 3 = include grandchildren). Example output:id: abc123-def456 title: Weekly Review database: task-db-id properties: Status: In Progress Tags: - backend Notes
| ||||||||||||||||||||||||||||||||
| writeA | Create or update Notion pages from Markdown with YAML frontmatter. Mode (default "auto"): if frontmatter has "id" → update, otherwise → create. Batch modeSeparate multiple pages with a line containing only "===" to create/update them in one call. Frontmatter fields
Properties are auto-matched to the database schema. Use the exact property name as key. Read-only fields from read output (url, created, last_edited, formula, etc.) are safely ignored. ExamplesCreate a page under a parent page:Create a database entry:Update an existing page (edit output from read):Append to an existing page (add content without rewriting):Use position: "append" to add content to the end, or "prepend" to add to the beginning. Only the new content needs to be provided — existing content is preserved. Batch create (multiple pages in one call): | ||||||||||||||||||||||||||||||||
| searchA | Search the Notion workspace by title keyword. Returns a Markdown list with page/database IDs, titles, and metadata. Use the returned IDs with other tools: read (to get full content), write (to update), list (to query a database), delete, or move. Example output: Search results: "MCP" (2 results)
| ||||||||||||||||||||||||||||||||
| listA | List database records as a Markdown table, or list child pages of a page. For databases: returns a table with properties as columns. For pages: returns a numbered list of child pages. You can pass a database/page name (resolved via search) or an ID/URL. Filter syntax (databases only)Simple expressions matched against DB property names and types:
Sort syntax (databases only)
Example outputTask Board (24 items)
| ||||||||||||||||||||||||||||||||
| deleteA | Archive (soft-delete) a Notion page. The page is moved to Trash and can be restored from Notion's UI. This does NOT permanently delete the page. | ||||||||||||||||||||||||||||||||
| moveA | Move a Notion page to a different parent page or database. The page keeps its content and properties; only the location changes. Example: move a page into an "Archive" page, or move a task into a different database. | ||||||||||||||||||||||||||||||||
| updateA | Quickly update page properties without rewriting content. Much simpler than the write tool for property-only changes. The page content (blocks) is never touched — only properties are updated. Parameters
ExamplesUpdate a single property: update({ page: "abc123", properties: { "Status": "Done" } }) Update multiple properties: update({ page: "My Task", properties: { "Status": "Done", "Priority": "High", "Due Date": "2026-03-01" } }) Supported value types:
| ||||||||||||||||||||||||||||||||
| schemaA | View or modify database schema (columns/properties). Actions"list" (default) — View current schemaschema({ database: "Task Board" }) Returns: property names, types, and select/multi_select options. "add" — Add a new propertyschema({ database: "Task Board", action: "add", property: "Priority", type: "select", options: ["Low", "Medium", "High"] }) "remove" — Remove a propertyschema({ database: "Task Board", action: "remove", property: "Old Column" }) "rename" — Rename a propertyschema({ database: "Task Board", action: "rename", property: "Due", name: "Due Date" }) Supported types for addtitle, rich_text, number, select, multi_select, date, checkbox, url, email, phone_number, status, people, files For select/multi_select, you can provide initial options. | ||||||||||||||||||||||||||||||||
| commentA | Add or read comments on a Notion page. Read commentscomment({ page: "abc123" }) Returns all comments on the page as a Markdown list. Add a commentcomment({ page: "abc123", body: "Looks good! Ready to ship." }) Adds a comment to the page. You can use the page name, ID, or URL. |
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 9 tools
Most tools have clearly distinct roles: read, delete, search, list, move, schema, and comment are well-separated. The main ambiguity is between write and update, since write can also update properties and content, while update is explicitly scoped to property-only changes. The descriptions help clarify the boundary, but an agent could still hesitate when deciding which to use for a property update.
All tool names are single lowercase words used as imperative commands, which creates a strong, predictable pattern. Write, read, search, list, delete, move, update, schema, and comment are all short and consistent in style. Minor semantic quibbles like 'schema' being a noun do not break the overall consistency.
Nine tools is a well-scoped size for a Notion MCP server. Each tool covers a meaningful area of Notion interaction without excessive fragmentation or redundancy. The set feels appropriately balanced for both simple and moderately complex workflows.
The server covers the core page lifecycle well: create/update via write, property-only updates, read, search, list, move, delete, schema management, and comments. Minor gaps exist, such as no way to create a brand-new database from scratch, no unarchive/restore operation, and no granular block-level editing. These are workable limitations rather than critical dead ends.