Сервер Model Context Protocol (MCP), который подключает Claude и других помощников ИИ к вашему рабочему пространству Notion. Эта интеграция позволяет помощникам ИИ взаимодействовать с вашими базами данных, страницами и блоками Notion.
Этот инструмент действует как мост между помощниками ИИ (например, Клодом) и вашим рабочим пространством Notion. Он позволяет ИИ:
Просмотр и поиск в базах данных Notion
Создание и обновление страниц
Управление блоками контента
И многое другое!
Related MCP server: Notion MCP Server
Node.js (версия 14 или выше)
Счет Notion
Приложение Claude Desktop (при использовании с Claude)
Перейдите по ссылке https://www.notion.so/my-integrations
Нажмите синюю кнопку «+ Новая интеграция».
Заполните данные:
Имя : выберите имя, например «Помощник Клода» или «Помощник ИИ».
Логотип : Необязательно
Связанное рабочее пространство : выберите рабочее пространство Notion
Нажмите «Отправить».
На следующей странице найдите раздел «Внутренний токен интеграции».
Нажмите «Показать» и скопируйте токен (он начинается с secret_ )
Вариант A: Загрузить как ZIP (рекомендуется для новичков)
Перейдите в репозиторий GitHub: https://github.com/Sjotie/notionMCP/
Нажмите зеленую кнопку «Код» в правом верхнем углу.
Выберите «Загрузить ZIP»
После загрузки извлеките ZIP-файл в папку на вашем компьютере.
Windows: щелкните правой кнопкой мыши ZIP-файл и выберите «Извлечь все».
Mac: дважды щелкните ZIP-файл, чтобы извлечь его.
Вариант B: Клонирование с помощью Git (для пользователей, знакомых с Git)
Откройте командную строку или терминал.
Windows: нажмите Win+R , введите cmd и нажмите Enter.
Mac: Откройте Терминал из Приложения > Утилиты.
Перейдите туда, где вы хотите сохранить репозиторий.
cd path/to/desired/locationКлонировать репозиторий
git clone https://github.com/Sjotie/notionMCP/После загрузки или клонирования вам необходимо перейти в папку проекта с помощью команды cd (изменить каталог):
Если вы скачали ZIP-файл (Вариант А):
Откройте командную строку или терминал.
Используйте команду cd , чтобы перейти к месту распаковки ZIP-файла:
cd path/to/extracted/folder/notionMCPНапример:
В Windows: cd C:\Users\YourName\Downloads\notionMCP
На Mac: cd /Users/YourName/Downloads/notionMCP
Если вы клонировали с помощью Git (вариант Б):
Репозиторий должен был быть клонирован в папку с именем «notionMCP».
Если после клонирования вы все еще находитесь в том же окне терминала, просто введите:
cd notionMCPКак узнать, что вы находитесь в правильном каталоге:
После использования команды cd вы можете проверить свое текущее местоположение:
В Windows: введите dir и нажмите Enter — вы должны увидеть файлы типа server.js
На Mac: введите ls и нажмите Enter — вы должны увидеть файлы типа server.js
Оказавшись в каталоге notionMCP, установите необходимые зависимости:
npm installЭто установит все необходимые пакеты Node.js. Вы должны увидеть индикатор выполнения и, в конечном итоге, сообщение о том, что установка завершена. Это может быть что-то вроде «X Packages are looking for funding» — это совершенно нормально и означает, что все сработало.
В целях безопасности Notion требует явного предоставления доступа к каждой странице или базе данных:
Откройте Notion и перейдите на страницу или в базу данных, к которым вы хотите предоставить доступ ИИ.
Нажмите «•••» (три точки) в правом верхнем углу.
Выберите «Добавить соединения».
Найдите и выберите интеграцию, которую вы создали ранее.
Повторите эти действия для любых других страниц или баз данных, которые вы хотите сделать доступными.
Найдите файл конфигурации 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 с вашим ключом API Notion
Сохраните файл и перезапустите Claude Desktop.
Начать новый разговор на языке Клод
Попросите Клода взаимодействовать с вашим рабочим пространством Notion, например:
«Покажите мне список моих баз данных Notion»
«Создать новую страницу в моей базе данных задач с заголовком «Тестовое задание»»
Сервер предоставляет следующие инструменты помощникам ИИ:
list-databases : Просмотреть все доступные базы данных
query-database : Получить записи из базы данных
create-page : Добавить новую страницу в базу данных
update-page : Изменить существующую страницу
create-database : Создать новую базу данных
update-database : Изменить структуру базы данных
get-page : Просмотр определенной страницы
get-block-children : Просмотр блоков контента
append-block-children : Добавить содержимое на страницу
update-block : Редактировать блоки контента
get-block : Просмотр определенного блока
поиск : найдите контент в вашем рабочем пространстве
«Сбой соединения» в Клоде
Убедитесь, что путь к серверу в claude_desktop_config.json указан правильно.
Проверьте, действителен ли ваш ключ API Notion
Убедитесь, что Node.js установлен
«Доступ запрещен» при доступе к контенту Notion
Убедитесь, что вы поделились страницей/базой данных с вашей интеграцией.
Проверьте, что ваш ключ API имеет необходимые разрешения.
Сервер не запускается
Убедитесь, что все зависимости установлены ( npm install )
Проверьте, существует ли файл .env с вашим ключом API.
Если вы столкнулись с проблемами, не описанными здесь, пожалуйста:
Проверьте вывод консоли на наличие сообщений об ошибках.
Убедитесь, что ваш ключ API Notion действителен
Убедитесь, что ваша интеграция имеет доступ к страницам/базам данных
Массачусетский технологический институт
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.
