Provides tools for interacting with Notion workspaces, including viewing and searching databases, creating and updating pages, managing content blocks, creating and modifying database structures, and searching content across workspaces.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Notion MCP Server show me my tasks due this week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that connects Claude and other AI assistants to your Notion workspace. This integration allows AI assistants to interact with your Notion databases, pages, and blocks.
This tool acts as a bridge between AI assistants (like Claude) and your Notion workspace. It allows the AI to:
View and search your Notion databases
Create and update pages
Manage content blocks
And much more!
Related MCP server: Notion MCP Server
Node.js (version 14 or higher)
A Notion account
Claude Desktop app (if using with Claude)
Click the blue "+ New integration" button
Fill in the details:
Name: Choose a name like "Claude Assistant" or "AI Helper"
Logo: Optional
Associated workspace: Select your Notion workspace
Click "Submit"
On the next page, find the "Internal Integration Token" section
Click "Show" and copy the token (it starts with secret_)
Download this repository to your computer
If you have Git: git clone [repository-url]
Or download and extract the ZIP file
Open a command prompt or terminal
Windows: Press Win+R, type cmd, and press Enter
Mac: Open Terminal from Applications > Utilities
Navigate to the folder where you downloaded this repository:
cd path/to/notion-mcp-serverInstall the required dependencies:
npm installCreate a configuration file:
Make a copy of .env.example and name it .env
Open the .env file in a text editor
Replace your_notion_api_key_here with the token you copied earlier
Save the file
For security, Notion requires you to explicitly grant access to each page or database:
Open Notion and navigate to a page or database you want the AI to access
Click the "•••" (three dots) in the top-right corner
Select "Add connections"
Find and select the integration you created earlier
Repeat for any other pages or databases you want to make accessible
Locate your Claude Desktop configuration file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
(Type this path in File Explorer address bar)
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
(In Finder, press Cmd+Shift+G and paste this path)
Open the file in a text editor. If it doesn't exist, create it with the following content:
{
"mcpServers": {
"notion": {
"command": "node",
"args": [
"C:\\path\\to\\notion-mcp-server\\server.js"
],
"env": {
"NOTION_API_KEY": "your_notion_api_key_here"
}
}
}
}Replace:
C:\\path\\to\\notion-mcp-server\\server.js with the actual path to the server.js file
Windows: Use double backslashes (\\) in the path
Mac: Use forward slashes (/)
your_notion_api_key_here with your Notion API key
Save the file and restart Claude Desktop
Start a new conversation in Claude
Ask Claude to interact with your Notion workspace, for example:
"Show me a list of my Notion databases"
"Create a new page in my Tasks database with title 'Test Task'"
The server provides these tools to AI assistants:
list-databases: View all accessible databases
query-database: Get entries from a database
create-page: Add a new page to a database
update-page: Modify an existing page
create-database: Create a new database
update-database: Modify a database structure
get-page: View a specific page
get-block-children: View content blocks
append-block-children: Add content to a page
update-block: Edit content blocks
get-block: View a specific block
search: Find content across your workspace
"Connection failed" in Claude
Make sure the server path in claude_desktop_config.json is correct
Check that your Notion API key is valid
Ensure Node.js is installed correctly
"Access denied" when accessing Notion content
Make sure you've shared the page/database with your integration
Check that your API key has the necessary permissions
Server won't start
Ensure all dependencies are installed (npm install)
Check that the .env file exists with your API key
If you encounter issues not covered here, please:
Check the console output for error messages
Ensure your Notion API key is valid
Verify that your integration has access to the pages/databases
Copy .env.example to .env
Fill in all required tokens such as NOTION_API_KEY, NOTION_DATABASE_ID,
SLACK_BOT_TOKEN, and SLACK_APP_TOKEN
Run each test file directly with Python:
python test_notion.py
python test_database.py
python test_create_entry.py
python test_add_content.py
python test_read_content.py
python test_update_entry.pyExecute individual Node test scripts using Node. For example:
node slack-mcp/test_mcp_server.jsMIT
Append blocks to a parent block
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Optional ID of an existing block to append after | |
| block_id | Yes | ID of the parent block (page or block) | |
| children | Yes | List of block objects to append |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Append') but lacks details on permissions needed, whether this is a destructive operation, rate limits, error handling, or what happens if 'after' is specified incorrectly. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and wastes no words, making it easy for an agent to parse quickly. Every word earns its place in conveying the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return values, error conditions, or behavioral nuances like how 'after' affects ordering. For a tool that modifies data, more context is needed to ensure correct usage by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the three parameters (block_id, children, after). The description adds no additional meaning beyond what the schema provides, such as examples of block objects or formatting details. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append') and target ('blocks to a parent block'), which is specific and unambiguous. However, it doesn't differentiate this tool from sibling tools like 'update-block' or 'get-block-children', which might also involve block manipulation or retrieval, leaving room for confusion about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'update-block' and 'get-block-children', it's unclear if this is for adding new content, modifying existing blocks, or other scenarios. No context, exclusions, or prerequisites are mentioned, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new database
| Name | Required | Description | Default |
|---|---|---|---|
| cover | No | Optional cover for the database | |
| icon | No | Optional icon for the database | |
| parent_id | Yes | ID of the parent page | |
| properties | Yes | Database properties schema | |
| title | Yes | Database title as rich text array |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new database' implies a write/mutation operation but provides no information about permissions required, whether the operation is idempotent, what happens on failure, or what the response contains. For a creation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single four-word sentence that communicates the essential purpose. There's zero wasted language, and the structure is front-loaded with the core action. Every word earns its place in this minimal but complete statement of function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a database creation tool with 5 parameters (3 required), no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a successful creation, what gets returned, error conditions, or how this differs from page creation. The agent lacks critical context needed to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all 5 parameters thoroughly. The description adds no parameter information beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify usage patterns. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new database'), making the purpose immediately understandable. It distinguishes from siblings like 'list-databases' or 'update-database' by specifying creation rather than listing or modifying. However, it doesn't explicitly differentiate from 'create-page' which creates a different resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when to choose this over 'create-page', or any context about database creation requirements. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new page in a database
| Name | Required | Description | Default |
|---|---|---|---|
| children | No | Optional content blocks | |
| parent_id | Yes | ID of the parent database | |
| properties | Yes | Page properties |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a page, implying a write operation, but does not address permissions, side effects, error conditions, or response format. This is a significant gap for a mutation tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized and front-loaded, efficiently conveying the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., what happens on success/failure) and does not compensate for the absence of structured output information, making it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (children, parent_id, properties). The description adds no additional meaning beyond the schema, such as examples or constraints, but since the schema is comprehensive, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('new page in a database'), making the purpose evident. However, it does not differentiate this tool from potential siblings like 'create-database' or 'update-page', which would require specifying that this creates a page within an existing database rather than a database itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a parent database ID), exclusions, or comparisons to siblings like 'append-block-children' or 'update-page', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a block by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| block_id | Yes | ID of the block to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'retrieve' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what happens with invalid IDs. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at just four words. It's front-loaded with the essential action and resource, with zero wasted words. Every element of the description earns its place by communicating the core function efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'block' represents in this context, what format the retrieved data will be in, or any limitations of the retrieval. Given the complexity implied by sibling tools (databases, pages, blocks), more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'block_id' clearly documented in the schema. The description doesn't add any meaningful parameter information beyond what the schema already provides, so it meets the baseline for high schema coverage without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('a block'), making the purpose understandable. It distinguishes this as a read operation rather than a creation or update tool. However, it doesn't explicitly differentiate from similar siblings like 'get-block-children' or 'get-page', which also retrieve content by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get-block-children' (retrieves child blocks), 'get-page' (retrieves pages), and 'search' (finds content), there's no indication of when this specific block retrieval is appropriate versus other lookup methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the children blocks of a block
| Name | Required | Description | Default |
|---|---|---|---|
| block_id | Yes | ID of the block (page or block) | |
| page_size | No | Number of results per page | |
| start_cursor | No | Cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Retrieve' implies a read operation, it doesn't specify authentication requirements, rate limits, error conditions, or what happens with invalid block IDs. The description lacks crucial behavioral context for a tool that interacts with a content system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a straightforward retrieval operation and gets directly to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'children blocks' means in this system's context, what format the results take, or provide any behavioral context. The description should do more to compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain what constitutes 'children blocks' in this context or provide examples of valid block IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('children blocks of a block'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get-block' or 'get-page', but the focus on children blocks provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get-block' (retrieves a single block), 'get-page' (retrieves a page), and 'search' (finds content), there's no indication of when this specific children-retrieval operation is appropriate versus other retrieval methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a page by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | ID of the page to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves a page but doesn't mention whether this is a read-only operation, what permissions are required, how errors are handled, or what the return format looks like. This leaves significant gaps for a tool that likely interacts with a data source.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that retrieves data with no annotations and no output schema, the description is insufficient. It doesn't explain what 'retrieve' entails (e.g., returns page content, metadata, or both), error conditions, or how it differs from similar tools, leaving the agent with incomplete context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the input schema, which has 100% coverage and clearly documents the 'page_id' parameter. The description implies the parameter is used to identify the page but doesn't provide additional context like format examples or constraints, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and resource ('a page by its ID'), making the tool's purpose immediately understandable. It doesn't differentiate from siblings like 'get-block' or 'get-block-children' which also retrieve content, but the specificity about retrieving a page is adequate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get-block' or 'search'. The description implies it's for retrieving a specific page when you have its ID, but it doesn't explicitly state this or mention prerequisites, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all databases the integration has access to
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires specific permissions, how results are formatted, or if there are rate limits. The description is minimal and lacks essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand quickly with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimal but adequate for basic understanding. However, without annotations or output schema, it lacks details on behavior, result format, or usage context relative to siblings, making it incomplete for optimal agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required, earning a baseline score of 4 for this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('databases'), specifying the scope as 'all databases the integration has access to'. However, it doesn't explicitly differentiate from sibling tools like 'query-database' or 'search', which might also retrieve database information but with different approaches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'query-database' or 'search' from the sibling list. It doesn't mention prerequisites, exclusions, or specific contexts where this tool is preferred over others for listing databases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query a database
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | ID of the database to query | |
| filter | No | Optional filter criteria | |
| page_size | No | Number of results per page | |
| sorts | No | Optional sort criteria | |
| start_cursor | No | Optional cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is read-only, has side effects, requires permissions, involves rate limits, or describes output format. For a query tool with 5 parameters, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, though it lacks detail. Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, nested objects, no output schema, and no annotations, the description is incomplete. It doesn't explain what the tool returns, how queries are structured, or behavioral traits. For a complex query tool, this leaves critical gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are documented in the schema. The description adds no meaning beyond the schema—it doesn't explain query semantics, filter/sort formats, or pagination behavior. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Query a database' states the basic action (query) and resource (database), which is clear but vague. It doesn't specify what type of query (e.g., SQL, NoSQL, filtered retrieval) or distinguish from siblings like 'search' or 'list-databases'. This provides minimal viable information without differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search' or 'list-databases'. The description implies general querying but doesn't specify contexts, prerequisites, or exclusions. This leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Notion for pages or databases
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional filter criteria | |
| page_size | No | Number of results per page | |
| query | No | Search query string | |
| sort | No | Optional sort criteria | |
| start_cursor | No | Cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic action. It doesn't mention whether this is a read-only operation, how results are returned, pagination behavior beyond the schema, rate limits, or authentication needs, leaving significant gaps for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, front-loading the core purpose. It's appropriately sized for a tool with this complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, no output schema) and lack of annotations, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances, failing to provide enough context for effective agent use beyond the basic schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional meaning about parameters beyond implying a general search function, meeting the baseline for high schema coverage without compensating with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and target ('Notion for pages or databases'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'query-database' or 'list-databases' that also retrieve content, missing an opportunity for precise distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'query-database' or 'list-databases'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a block's content or archive status
| Name | Required | Description | Default |
|---|---|---|---|
| archived | No | Whether to archive (true) or restore (false) the block | |
| block_id | Yes | ID of the block to update | |
| block_type | Yes | The type of block (paragraph, heading_1, to_do, etc.) | |
| content | Yes | The content for the block based on its type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update a block's content or archive status', which implies a mutation operation, but doesn't cover critical aspects like permissions required, whether changes are reversible, error handling, or response format. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error conditions, and what the tool returns, which are crucial for safe and effective use. The description should do more to compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions 'content or archive status', which aligns with the 'content' and 'archived' parameters in the schema, but adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'a block's content or archive status', making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'update-page' or 'update-database', which have similar update operations on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing a block ID, nor does it compare with siblings like 'append-block-children' for adding content or 'get-block' for reading. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing database
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | ID of the database to update | |
| description | No | Optional new description as rich text array | |
| properties | No | Optional updated properties schema | |
| title | No | Optional new title as rich text array |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update an existing database' implies a mutation operation, but it doesn't disclose any behavioral traits: no information about permissions required, whether changes are reversible, rate limits, error conditions, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words: 'Update an existing database.' It's front-loaded with the core action and resource. There's zero wasted language or unnecessary elaboration. While it may be too brief for completeness, it earns full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (update operation) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, what side effects occur, or any behavioral context. The description alone is insufficient for an agent to understand how to properly use this tool beyond the basic action implied by the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents all four parameters (database_id, description, properties, title) with their types and descriptions. The tool description adds no additional meaning about parameters beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing database' clearly states the verb (update) and resource (database), but it's vague about what specifically gets updated. It doesn't distinguish this tool from sibling tools like update-block or update-page, which also perform updates on different resources. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like update-block, update-page, and create-database available, there's no indication of when this tool is appropriate versus those other update/create operations. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing page
| Name | Required | Description | Default |
|---|---|---|---|
| archived | No | Whether to archive the page | |
| page_id | Yes | ID of the page to update | |
| properties | Yes | Updated page properties |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update an existing page' which implies a mutation operation, but doesn't specify what permissions are required, whether changes are reversible, or what happens to unspecified properties. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, front-loading the essential information with zero wasted words. Every element ('Update', 'an existing page') earns its place by clearly communicating the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'update' entails operationally, what the response looks like, or potential side effects. Given the complexity of updating a page with properties and archival options, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and target resource ('an existing page'), making the tool's purpose immediately understandable. It distinguishes from sibling tools like 'create-page' by specifying it works on existing pages, though it doesn't differentiate from 'update-block' or 'update-database' which also update resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update-block' or 'update-database', nor does it mention prerequisites such as needing a valid page_id. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0append-block-childrencreate-databasecreate-pageget-blockget-block-childrenget-pagelist-databasesquery-databasesearchupdate-blockupdate-databaseupdate-pageScored across 12 tools
Each tool has a clearly distinct purpose targeting specific Notion resources and actions, with no overlap that would cause confusion. For example, 'get-block' retrieves a single block, 'get-block-children' retrieves child blocks, and 'append-block-children' adds new blocks, making them easily distinguishable.
All tools follow a consistent verb-noun pattern with hyphens separating words, such as 'create-database', 'update-page', and 'query-database'. This predictable naming convention enhances readability and agent usability without any deviations or mixed styles.
With 12 tools, this server is well-scoped for managing Notion's core resources like pages, blocks, and databases. Each tool earns its place by covering essential CRUD operations and specific functionalities like searching and querying, avoiding both bloat and thin coverage.
The tool set provides complete CRUD and lifecycle coverage for Notion's domain, including creation, retrieval, updating, and querying of pages, blocks, and databases. There are no obvious gaps, as it supports all major workflows from basic operations to advanced features like searching and appending blocks.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
MCP-native open-source Notion alternative: read & write pages, databases and kanban boards.
A Model Context Protocol server for Wix AI tools
