模型上下文协议 (MCP) 服务器，用于将 Claude 和其他 AI 助手连接到您的 Notion 工作区。此集成允许 AI 助手与您的 Notion 数据库、页面和块进行交互。
此工具充当 AI 助手（如 Claude）和 Notion 工作区之间的桥梁。它允许 AI 执行以下操作：
查看和搜索您的 Notion 数据库
创建和更新页面
管理内容块
还有更多！
Related MCP server: Notion MCP Server
Node.js （版本 14 或更高版本）
Notion 帐户
Claude 桌面应用程序（如果与 Claude 一起使用）
点击蓝色的**“+ 新集成”**按钮
填写详细信息：
名称：选择一个名称，例如“Claude Assistant”或“AI Helper”
徽标：可选
关联工作区：选择您的 Notion 工作区
点击**“提交”**
在下一页上，找到**“内部集成令牌”**部分
单击**“显示”**并复制令牌（以secret_开头）
将此存储库下载到您的计算机
如果你有 Git： git clone [repository-url]
或者下载并解压 ZIP 文件
打开命令提示符或终端
Windows：按Win+R ，键入cmd ，然后按 Enter 键
Mac：从“应用程序”>“实用程序”打开终端
导航到下载此存储库的文件夹：
cd path/to/notion-mcp-server安装所需的依赖项：
npm install创建配置文件：
复制.env.example并将其命名为.env
在文本编辑器中打开.env文件
将your_notion_api_key_here替换为您之前复制的令牌
保存文件
为了安全起见，Notion 要求您明确授予对每个页面或数据库的访问权限：
打开 Notion 并导航到您希望 AI 访问的页面或数据库
点击右上角的**“•••”** （三个点）
选择**“添加连接”**
查找并选择您之前创建的集成
对您想要访问的任何其他页面或数据库重复此操作
找到您的 Claude Desktop 配置文件：
Windows： %APPDATA%\Claude\claude_desktop_config.json （在文件资源管理器地址栏中输入此路径）
Mac： ~/Library/Application Support/Claude/claude_desktop_config.json （在 Finder 中，按 Cmd+Shift+G 并粘贴此路径）
在文本编辑器中打开该文件。如果该文件不存在，请使用以下内容创建它：
{
"mcpServers": {
"notion": {
"command": "node",
"args": [
"C:\\path\\to\\notion-mcp-server\\server.js"
],
"env": {
"NOTION_API_KEY": "your_notion_api_key_here"
}
}
}
}代替：
C:\\path\\to\\notion-mcp-server\\server.js替换为 server.js 文件的实际路径
Windows：在路径中使用双反斜杠 (\\)
Mac：使用正斜杠 (/)
your_notion_api_key_here为您的 Notion API 密钥
保存文件并重新启动Claude Desktop
在 Claude 中开始新对话
让 Claude 与您的 Notion 工作区进行交互，例如：
“显示我的 Notion 数据库列表”
“在我的任务数据库中创建一个标题为‘测试任务’的新页面”
服务器为AI助手提供以下工具：
list-databases ：查看所有可访问的数据库
查询数据库：从数据库中获取条目
create-page ：向数据库添加新页面
update-page ：修改现有页面
create-database ：创建一个新的数据库
update-database ：修改数据库结构
get-page ：查看特定页面
get-block-children ：查看内容块
append-block-children ：向页面添加内容
update-block ：编辑内容块
get-block ：查看特定块
搜索：在整个工作区中查找内容
克劳德的“连接失败”
确保 claude_desktop_config.json 中的服务器路径正确
检查您的 Notion API 密钥是否有效
确保 Node.js 正确安装
访问 Notion 内容时出现“访问被拒绝”
确保您已与集成共享页面/数据库
检查您的 API 密钥是否具有必要的权限
服务器无法启动
确保所有依赖项都已安装（ npm install ）
检查 .env 文件是否存在以及您的 API 密钥
如果您遇到此处未涵盖的问题，请：
检查控制台输出的错误消息
确保您的 Notion API 密钥有效
验证您的集成是否可以访问页面/数据库
麻省理工学院
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
