一个轻量级的 Notion MCP 服务器，与官方 Notion MCP 相比，它能最大限度地减少 Token 使用量。
它不返回原始的 Notion API JSON，而是为每个工具返回最精简的有效表示：页面以纯 Markdown 格式返回，搜索结果则每条记录仅占一行。在实际应用中，这显著降低了读取密集型工作流中的 Token 消耗。
工具 | 描述 |
| 按标题搜索页面。以 TOON 格式返回，每条结果占一行。 |
| 以 Markdown 格式读取页面。 |
| 将 Markdown 追加到现有页面。 |
| 在父页面下创建子页面，可选择性添加内容。 |
搜索结果和页面创建响应使用紧凑的 TOON（Title | Object | Optional Notes，标题 | 对象 | 可选备注）格式：
Page title | page-id | https://notion.so/... | parent:<parent-id>这使得搜索响应每条结果仅占一行，而不是数百个 Token 的 JSON。
Related MCP server: Markdown-To-Notion
notion_read)块类型 | Markdown 输出 |
段落 | 纯文本 |
标题 1 / 2 / 3 |
|
无序列表项 |
|
有序列表项 |
|
代码块 |
|
表格 | 管道符分隔的行 |
子页面 |
|
内联格式（粗体、斜体、粗斜体、删除线、下划线、内联代码、链接）均以 Markdown 格式保留。
notion_write)写入时支持相同的块类型。Markdown 会被解析并作为原生 Notion 块追加到目标页面。
以下块类型可被 Notion 识别但尚未处理。它们在读取时会被静默跳过，且无法写入：
分割线 (---)
引用块
待办事项 / 复选框列表
标注块 (Callout)
折叠列表
目录
文件、图片和视频
不同列表类型之间的空段落块无法往返转换。 当页面中存在明确的空段落来分隔（例如）无序列表和有序列表时，该分隔符在“读取 → 写入”循环中会丢失。Markdown 在块之间自动添加的 "\n\n" 在视觉上是等效的，但在写入时不会生成 Notion 的空段落块。这是扁平化 Markdown 表示法的固有局限，在设计出 v2 格式之前将一直存在。
表格标题标志无法往返转换。 Notion 表格可以在没有列标题行的情况下创建 (has_column_header: false)。当前的写入器总是设置 has_column_header: true，因为标准 Markdown 表格隐含了标题。写回的表格看起来相同，但会设置标题标志。
Python 3.12+
一个拥有您所需页面读/写权限的 Notion 集成令牌 (Integration Token)
# From source
git clone https://github.com/your-username/tiny-notion-mcp
cd tiny-notion-mcp
pip install .或者直接使用 uv 安装：
uv tool install .将您的 Notion 集成令牌设置为环境变量：
export NOTION_TOKEN=secret_...NOTION_API_KEY 也可作为别名使用。
将服务器添加到您的 MCP 配置中：
{
"mcpServers": {
"tiny-notion-mcp": {
"command": "tiny-notion-mcp",
"env": {
"NOTION_TOKEN": "secret_..."
}
}
}
}如果您使用 uv 安装到了隔离环境中，请使用完整路径：
{
"mcpServers": {
"tiny-notion-mcp": {
"command": "uv",
"args": ["run", "--", "tiny-notion-mcp"],
"env": {
"NOTION_TOKEN": "secret_..."
}
}
}
}# Install with dev dependencies
pip install -e ".[dev]"
# Run tests
pytest测试使用存根 NotionClient，不会进行真实的 API 调用。
Token 效率优先。 每个响应在保持可操作性的前提下尽可能小。
无中间文件。 所有内容均作为字符串内联返回 — 无临时文件，无文件路径引用。
无需 Notion 账户即可测试。 NotionClient 接口采用注入方式，以便核心逻辑可以在隔离环境中进行测试。
Create a new page or database entry. Set parent_type='page_id' (default) for a subpage, or 'database_id' to insert a row into a database. For database entries, pass extra properties (Status, Date, etc.) as Notion property objects via the 'properties' field. Returns TOON format with the new page ID.
| Name | Required | Description | Default |
|---|---|---|---|
| parent_id | Yes | Parent page ID or database ID | |
| title | Yes | Title / Name of the new page or entry | |
| parent_type | No | Whether parent_id is a page ('page_id') or database ('database_id') | page_id |
| properties | No | Additional Notion property objects for database entries (e.g. Status, Date, Category) | |
| markdown | No | Optional markdown content to write to the new page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the return format and two modes of operation but does not disclose permissions, idempotency, or side effects. Some behavioral context is present but incomplete.
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?
Three sentences, no wasted words. Front-loaded with the main purpose. Efficient and 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?
Covers key aspects: creation, two modes, property usage, return format. Lacks details on error handling and 'TOON format' explanation, but overall sufficient given the tool's complexity and no output 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 coverage is 100%, so baseline is 3. The description adds value by explaining the parent_type enum role, giving examples of properties (Status, Date, Category), and clarifying that markdown is optional. This goes beyond the schema descriptions.
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?
Description clearly states it creates a new page or database entry, explains the two parent_type options (subpage vs database row), and specifies the return format. This distinguishes it from sibling tools like notion_update_page or notion_delete_page.
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?
Provides clear guidance on when to use page_id vs database_id, and what to pass for database entries. However, it does not explicitly state when not to use this tool or compare it to alternatives like notion_write for pages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ DESTRUCTIVE — deletes a single block (moves to Notion's trash, recoverable within 30 days). Use notion_get_blocks to find the block ID first. Deleting a parent block (table, toggle) also deletes all its children.
| Name | Required | Description | Default |
|---|---|---|---|
| block_id | Yes | ID of the block to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the destructive nature, recovery window (30 days), and the cascading effect on child blocks. This provides thorough behavioral transparency beyond what annotations would typically offer.
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, with two sentences that each carry essential information. Warning and action are front-loaded, and no extraneous text is present.
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 simple tool with one parameter and no output schema, the description is fully complete. It covers the action, prerequisites, consequences, and edge cases (parent deletion).
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 has 100% coverage with a clear description for the only parameter. The description adds value by contextualizing the block_id as something to be obtained via notion_get_blocks, enhancing the parameter's meaning.
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 explicitly states 'deletes a single block' and distinguishes the tool from siblings like notion_delete_page (deletes a page) and notion_get_blocks (used to find the block ID). The action and resource are clear and specific.
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 instructs to use notion_get_blocks to find the block ID first, providing clear guidance on prerequisite steps. It also warns about cascading deletion when deleting parent blocks. However, it does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ DESTRUCTIVE — moves a Notion page to trash. The page is recoverable from Notion's trash within 30 days. Only call this when the user explicitly asks to delete a page.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | ID of the page to trash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses destructive nature, recovery period (30 days), and uses a warning emoji. Lacks details on side effects like children or permissions, but is good for a simple 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?
Two sentences, no redundancy. First sentence states action and recovery, second is usage guidance. Every word earns its place.
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 a simple tool with 1 param and no output schema, the description covers purpose, usage, and behavioral impact. Could mention error conditions, but it's sufficient for the tool's simplicity.
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?
Only one parameter (page_id) with schema description 'ID of the page to trash'. Schema coverage is 100%, so baseline is 3. The description adds no additional semantics beyond what the schema provides.
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 it moves a Notion page to trash, a specific verb-resource pair, and distinguishes it from permanent deletion by noting recoverability. Siblings include notion_delete_block, so it's clear this is for pages.
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?
Explicitly says 'Only call this when the user explicitly asks to delete a page', providing clear when-to-use guidance. No explicit alternatives or when-not, but the condition is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all blocks on a page with their IDs. Returns one line per block: block-id | block_type | text_preview. If the response ends with 'MORE: ', pass that cursor as start_cursor to get the next batch. Use the block-id with notion_write's after_block_id to insert content after a specific block.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | Notion page ID | |
| start_cursor | No | Cursor from a previous 'MORE:' response to get the next batch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes pagination behavior with 'MORE:' indicator and response format. Since no annotations exist, the description carries full burden; it effectively communicates read-only nature and pagination.
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?
Three sentences, no filler, conveys essential information: purpose, output format, pagination, and cross-tool usage.
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?
Covers core functionality and pagination. Could mention expected errors or authorization, but for a simple list tool this is sufficient.
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?
Adds context to both parameters: page_id for listing blocks, start_cursor for pagination. Schema coverage is 100%, so baseline is 3; the description adds value by explaining pagination mechanics.
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 tool lists all blocks on a page with their IDs, specifying the output format and linking to a sibling tool (notion_write) for usage.
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?
Provides clear instructions on pagination via start_cursor and how to use block-id with notion_write, but does not explicitly exclude other use cases or mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query a Notion database and return results as a markdown table. Each row is one entry; columns match the database properties. An ID column is appended for follow-up reads or writes. If the response ends with 'MORE: ', pass that cursor as start_cursor to get the next batch.
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | Notion database ID | |
| limit | No | Max rows to return (default 100, max 100) | |
| start_cursor | No | Cursor from a previous 'MORE:' response to get the next batch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Though annotations are absent, the description discloses return format (markdown table), the appended ID column, and pagination behavior. This covers the main behavioral traits beyond the schema.
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?
Three sentences with no wasted words. Front-loaded with the main purpose, then adds essential details about returned format and pagination.
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 simple query tool with 3 parameters, the description covers return format, added column, and pagination. It does not mention error handling or rate limits, but overall is complete enough given the tool's straightforward nature.
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 coverage is 100%, so baseline is 3. The description adds limited value: explains start_cursor usage from previous responses, but otherwise repeats schema defaults and descriptions.
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 tool queries a Notion database and returns results as a markdown table, with an appended ID column. This provides a specific verb and resource, but does not differentiate from sibling tools like notion_search.
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 gives guidance on pagination (pass cursor from 'MORE:' response), but no explicit when-to-use or when-not-to-use compared to alternatives. Usage is implied but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a Notion page as markdown. Returns markdown string directly. If the response ends with 'MORE: ', pass that cursor as start_cursor to read the next batch of blocks.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | Notion page ID | |
| start_cursor | No | Cursor from a previous 'MORE:' response to get the next batch |
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 discloses that the tool returns a markdown string and handles pagination via a cursor. However, it does not mention rate limits, authentication requirements, or error handling. For a read-only tool, basic transparency is adequate but not thorough.
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 two sentences, concise and front-loaded with the main purpose. It uses clear language. Could be slightly improved by using bullet points for clarity, but overall efficient.
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 simplicity of the tool (reading a markdown page with pagination) and the fact that there is no output schema needed, the description fully covers the tool's behavior. It explains the input parameters and the response format for pagination.
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 input schema provides clear descriptions for both parameters with 100% coverage. The description adds value by explaining how to use the start_cursor parameter in response to a 'MORE:' indicator, which is helpful for pagination.
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 it reads a Notion page as markdown and returns a markdown string, which is a specific verb+resource combination. It distinguishes itself from sibling tools like notion_get_blocks (which returns raw blocks) and notion_query_database (which queries databases).
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 includes pagination handling with the 'MORE:' cursor, but it does not explicitly state when to use this tool versus siblings like notion_get_blocks or notion_query_database. Use cases are implied by the markdown output but not clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Notion pages. Returns TOON format: Title | ID | URL (one per line)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| limit | No | Max results (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It describes the return format (TOON format, one per line), which is helpful. However, it omits details like read-only nature, potential rate limits, or whether the search is full-text. For a simple search, this is adequate but not comprehensive.
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?
Single concise sentence that states the tool's purpose and output format. No unnecessary words. Efficient and front-loaded.
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 simple search tool with two parameters and no output schema, the description provides essential return format information. However, it does not explain what 'TOON' stands for (assumed Title, ID, URL) or clarify search behavior (e.g., whether it searches page content or title). Still, it is largely complete given the tool's simplicity.
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 coverage is 100% with basic descriptions ('Search query', 'Max results (default 10)'). The description adds no further meaning beyond the schema. Given the baseline of 3 for high coverage, this 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 tool searches Notion pages and explains the return format (TOON: Title | ID | URL). This distinguishes it from sibling tools like notion_read (read single page) and notion_query_database (database query).
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 explicit guidance on when to use this tool versus alternatives. While the name and brief description imply it's for general page search, there is no 'when not to use' or references to sibling tools. This leaves the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update properties of a Notion page or database entry. Pass a dict of Notion property objects, e.g. {"Status": {"status": {"name": "Done"}}} or {"Date": {"date": {"start": "2026-04-30"}}}.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | ID of the page or database entry to update | |
| properties | Yes | Notion property objects to update |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits like idempotency, required permissions, or error handling. Only states the action.
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?
Extremely concise: one sentence stating purpose plus a brief example. No redundant information.
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?
Input is well-covered but no output schema or description of return value. For a mutation tool, knowing the response format would be helpful.
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%. The description adds value with concrete JSON examples of property objects, surpassing the schema's generic 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?
Clear verb 'Update' with specific resource 'Notion page or database entry'. Distinguishes from sibling tools like notion_create_page and notion_delete_page.
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?
Provides example usage but no explicit guidance on when to use this tool vs alternatives. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append markdown to a Notion page. Converts markdown to blocks. Pass after_block_id to insert the content after a specific block rather than at the end of the page. Use notion_read to find block IDs (each block object has an 'id' field).
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | Notion page ID | |
| markdown | Yes | Markdown content to append | |
| after_block_id | No | Block ID after which to insert the content. Omit to append at the end. |
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 discloses that markdown is converted to blocks and the positional insert behavior via after_block_id. However, it does not mention error handling, idempotency, or what happens if the page_id is invalid.
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?
Three concise sentences with no wasted words. The purpose is front-loaded, followed by behavioral detail and a reference to a sibling tool for finding block IDs.
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?
The description lacks information about the tool's return value and error scenarios. Since there is no output schema, the description should compensate by explaining what the agent can expect, but it does not.
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%. The description adds marginal value for the markdown parameter by mentioning it is converted to blocks, but repeats the schema text for after_block_id. It does not significantly enhance understanding beyond the schema.
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 it appends markdown to a Notion page, a specific write operation. It distinguishes from sibling tools like notion_create_page (which creates new pages) and notion_update_page (which updates properties).
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 explains when to use the after_block_id parameter and directs the user to notion_read for finding block IDs. It provides clear context but does not explicitly state when not to use this tool, such as for creating pages or updating page properties.
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.
v0.1.0notion_create_pagenotion_delete_blocknotion_delete_pagenotion_get_blocksnotion_query_databasenotion_readnotion_searchnotion_update_pagenotion_writeScored across 9 tools
Each tool targets a distinct Notion operation (create page, delete block, query database, etc.) with no overlapping functionality. The descriptions clearly differentiate between similar-sounding tools like notion_read (page as markdown) and notion_get_blocks (list block IDs).
All tools follow a consistent `notion_<verb>_<noun>` pattern using snake_case. The verbs are descriptive and align with the action (create, delete, get, query, read, search, update, write), making the naming predictable and easy to follow.
With 9 tools, the set is well-scoped for a Notion integration. Each tool serves a necessary core function without being excessive. The count is typical for such an API surface, allowing efficient coverage without overwhelming an agent.
The tools cover essential CRUD operations for pages and databases, plus search, block listing, and content writing. Missing are direct block update and database creation, but the existing set handles most common workflows. Minor gaps, but not critical.
MCP-native open-source Notion alternative: read & write pages, databases and kanban boards.
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
