公式Notion MCPと比較して、トークン使用量を最小限に抑えた軽量なNotion MCPサーバーです。
Notion APIの生のJSONを返す代わりに、すべてのツールが最も有用な最小限の表現を返します。ページはプレーンなMarkdownとして、検索結果はヒットごとに1行で返されます。実際、これにより読み取り中心のワークフローにおけるトークン消費量が大幅に削減されます。
ツール | 説明 |
| タイトルでページを検索します。結果をTOON形式で1行ずつ返します。 |
| ページをMarkdownとして読み取ります。 |
| 既存のページにMarkdownを追記します。 |
| 親ページの下にサブページを作成します（オプションでコンテンツを含めることも可能）。 |
検索結果とページ作成のレスポンスには、コンパクトな TOON (Title | Object | Optional Notes) 形式を使用します：
Page title | page-id | https://notion.so/... | parent:<parent-id>これにより、検索レスポンスが数百トークンのJSONではなく、結果ごとに1行に収まります。
Related MCP server: Markdown-To-Notion
notion_read)ブロックタイプ | Markdown出力 |
段落 | プレーンテキスト |
見出し 1 / 2 / 3 |
|
箇条書きリスト |
|
番号付きリスト |
|
コードブロック |
|
テーブル | パイプ区切りの行 |
子ページ |
|
インライン書式（太字、斜体、太字斜体、取り消し線、下線、インラインコード、リンク）はMarkdownとして保持されます。
notion_write)書き込み時も同じブロックタイプがサポートされています。Markdownは解析され、Notionのネイティブブロックとしてターゲットページに追記されます。
以下のブロックタイプはNotionでは認識されますが、まだ処理されません。読み取り時には無視され、書き込むこともできません：
区切り線 (---)
引用ブロック
To-do / チェックボックスリスト
コールアウトブロック
トグルリスト
目次
ファイル、画像、動画
異なるリストタイプ間の空の段落ブロックは往復できません。 ページに箇条書きリストと番号付きリストを分ける明示的な空の段落がある場合、その区切りは読み取り→書き込みのサイクルで失われます。Markdownがブロック間に挿入する "\n\n" は視覚的には同等ですが、書き込み時にNotionの空の段落ブロックを生成するわけではありません。これはフラットなMarkdown表現の固有の制限であり、v2形式が設計されるまで維持されます。
テーブルヘッダーフラグは往復できません。 Notionのテーブルは列ヘッダー行なしで作成できます (has_column_header: false)。現在のライターは標準的なMarkdownテーブルがヘッダーを前提としているため、常に has_column_header: true を設定します。書き戻されたテーブルは見た目は同じですが、ヘッダーフラグが設定された状態になります。
Python 3.12以上
使用したいページに対する読み取り/書き込み権限を持つNotionインテグレーション・トークン
# 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呼び出しは行いません。
トークンの効率性を最優先。 すべてのレスポンスは、アクション可能であることを維持しつつ、可能な限り小さくします。
中間ファイルなし。 すべてのコンテンツは文字列としてインラインで返されます。一時ファイルやファイルパスの参照は使用しません。
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.
