The Notion MCP Server acts as a bridge, allowing AI assistants like Claude to interact with your Notion workspace. With this server, you can:
List and query databases: View all accessible databases and retrieve entries with optional sorting, filtering, and pagination
Manage pages: Create new pages, update existing ones, retrieve specific pages by ID, or archive them
Work with databases: Create new databases with customizable properties or update existing ones
Manage blocks: Retrieve, append, or update content blocks within pages
Search: Find pages or databases across your Notion workspace with optional filters and sorting
Allows AI assistants to interact with Notion workspace, including viewing/searching databases, creating/updating pages, managing content blocks, and more
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 find my meeting notes from last week and summarize the action items"
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_)
Option A: Download as ZIP (Recommended for beginners)
Go to the GitHub repository: https://github.com/Sjotie/notionMCP/
Click the green "Code" button at the top right
Select "Download ZIP"
Once downloaded, extract the ZIP file to a location on your computer
Windows: Right-click the ZIP file and select "Extract All"
Mac: Double-click the ZIP file to extract
Option B: Clone with Git (For users familiar with Git)
Open a command prompt or terminal
Windows: Press Win+R, type cmd, and press Enter
Mac: Open Terminal from Applications > Utilities
Navigate to where you want to store the repository
cd path/to/desired/locationClone the repository
git clone https://github.com/Sjotie/notionMCP/After downloading or cloning, you need to navigate to the project folder using the cd (change directory) command:
If you downloaded the ZIP (Option A):
Open a command prompt or terminal
Use the cd command to navigate to where you extracted the ZIP file:
cd path/to/extracted/folder/notionMCPFor example:
On Windows: cd C:\Users\YourName\Downloads\notionMCP
On Mac: cd /Users/YourName/Downloads/notionMCP
If you cloned with Git (Option B):
The repository should have been cloned into a folder named "notionMCP"
If you're still in the same terminal window after cloning, simply type:
cd notionMCPHow to know you're in the right directory:
After using the cd command, you can check your current location:
On Windows: Type dir and press Enter - you should see files like server.js
On Mac: Type ls and press Enter - you should see files like server.js
Once you're in the notionMCP directory, install the required dependencies:
npm installThis will install all the necessary Node.js packages. You should see a progress bar and eventually a message indicating the installation is finished. It might say something along the lines of "X Packages are looking for funding" - this is completely normal and means it worked.
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
"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
MIT
Append blocks to a parent block
| Name | Required | Description | Default |
|---|---|---|---|
| block_id | Yes | ID of the parent block (page or block) | |
| children | Yes | List of block objects to append | |
| after | No | Optional ID of an existing block to append after |
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 |
|---|---|---|---|
| parent_id | Yes | ID of the parent page | |
| title | Yes | Database title as rich text array | |
| properties | Yes | Database properties schema | |
| icon | No | Optional icon for the database | |
| cover | No | Optional cover for the database |
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 |
|---|---|---|---|
| parent_id | Yes | ID of the parent database | |
| properties | Yes | Page properties | |
| children | No | Optional content blocks |
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) | |
| start_cursor | No | Cursor for pagination | |
| page_size | No | Number of results per page |
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 | |
| sorts | No | Optional sort criteria | |
| start_cursor | No | Optional cursor for pagination | |
| page_size | No | Number of results per page |
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 |
|---|---|---|---|
| query | No | Search query string | |
| filter | No | Optional filter criteria | |
| sort | No | Optional sort criteria | |
| start_cursor | No | Cursor for pagination | |
| page_size | No | Number of results per page |
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 |
|---|---|---|---|
| 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 | |
| archived | No | Whether to archive (true) or restore (false) the block |
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 | |
| title | No | Optional new title as rich text array | |
| description | No | Optional new description as rich text array | |
| properties | No | Optional updated properties schema |
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 |
|---|---|---|---|
| page_id | Yes | ID of the page to update | |
| properties | Yes | Updated page properties | |
| archived | No | Whether to archive the page |
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 (blocks, databases, pages) and actions (create, get, update, list, query, search, append). There is no overlap or ambiguity between tools, as they cover different resource-action combinations with precise scopes.
All tools follow a consistent verb-noun pattern using kebab-case (e.g., create-database, update-page, get-block). The naming is predictable and uniform across all 12 tools, with verbs like create, get, update, list, query, search, and append consistently applied to appropriate nouns.
With 12 tools, the server is well-scoped for managing Notion's core entities (blocks, databases, pages). Each tool earns its place by covering essential CRUD and query operations without redundancy, making it neither too sparse nor overloaded for the domain.
The tool set provides complete CRUD/lifecycle coverage for Notion's main resources: databases (create, update, list, query), pages (create, get, update), and blocks (get, update, append, get children). It also includes search functionality, leaving no obvious gaps for agent workflows in this domain.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
