Provides tools for searching, reading, writing, and creating pages in Notion, returning results in compact formats to minimize token usage.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tiny-notion-mcp search for pages about 'project roadmap'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The official Notion MCP server returns raw Notion API JSON — deeply nested, metadata-heavy payloads that consume thousands of tokens per response. In LLM-powered workflows, token usage directly translates to latency, cost, and context pressure.
tiny-notion-mcp takes a different approach: every tool returns the smallest useful representation.
Official MCP | tiny-notion-mcp | |
Read format | Notion API JSON | Plain Markdown |
Search format | JSON objects | 1 line per result (TOON) |
Database queries | JSON | Markdown table |
Inline formatting | Raw annotations | Rendered Markdown |
Pagination | Manual cursor |
|
In practice this cuts token consumption by ~60-90% on read-heavy workflows, while remaining fully compatible with the MCP protocol.
Related MCP server: Markdown-To-Notion
flowchart LR
subgraph Client["MCP Client (Claude, Cursor, etc.)"]
direction TB
C1["notion_search(query)"]
C2["notion_read(page_id)"]
C3["notion_write(markdown)"]
C4["notion_query_database(db_id)"]
C5["notion_create_page(...)"]
C6["notion_update_page(...)"]
C7["notion_get_blocks(...)"]
C8["notion_delete_block/delete_page(...)"]
end
subgraph Server["tiny-notion-mcp (stdio)"]
SERVER["MCP Server"]
CORE["Core Logic\n• Markdown ↔ Notion blocks\n• Inline formatting\n• Table handling\n• Pagination"]
end
subgraph Notion["Notion API"]
API["notion-client SDK"]
end
C1 & C2 & C3 & C4 & C5 & C6 & C7 & C8 -->|"JSON-RPC"| SERVER
SERVER --> CORE
CORE --> API
API --> NotionAPI["api.notion.com"]The server uses an abstract NotionClient interface, making the core logic fully testable without a Notion account. A production implementation wraps the notion-client SDK; tests use a lightweight mock.
Tool | Description |
| Search pages by title. Returns TOON format — one line per hit. |
| Read a page as Markdown. Supports pagination via |
| List block IDs and types on a page. Used to find insertion points for |
| Append Markdown to a page. Automatically chunked into batches of 50 blocks. |
| Create a sub-page or database entry, optionally with Markdown content. |
| Update Notion properties on a page (status, dates, relations, etc.). |
| Query a database and return results as a Markdown table with an ID column. |
| ⚠️ Delete a single block (trashed, recoverable for 30 days). |
| ⚠️ Move a page to Notion trash (recoverable for 30 days). |
Search results and page creation responses use the compact TOON format:
Page title | page-id | https://notion.so/... | parent:<parent-id>One line per result. No nested JSON. No metadata noise.
Prerequisites: uv and a Notion integration token.
git clone https://github.com/AyanoT1/tiny-notion-mcp
cd tiny-notion-mcp
uv tool install .Claude Desktop (~/.config/claude/claude_desktop_config.json):
{
"mcpServers": {
"tiny-notion-mcp": {
"command": "uvx",
"args": ["tiny-notion-mcp"],
"env": {
"NOTION_TOKEN": "ntn_..."
}
}
}
}Cursor / VS Code with an MCP client:
{
"mcpServers": {
"tiny-notion-mcp": {
"command": "uvx",
"args": ["tiny-notion-mcp"],
"env": {
"NOTION_TOKEN": "ntn_..."
}
}
}
}Note: Before using the tools, connect the integration to any Notion pages or databases you want it to access via the Notion UI (⋮ → Connections → Add integration).
Block type | Markdown output |
Paragraph | Plain text |
Heading 1 / 2 / 3 |
|
Bulleted list |
|
Numbered list |
|
Code block |
|
Divider |
|
To-do item |
|
Block quote |
|
Callout |
|
Table | Pipe-delimited rows with Markdown inline formatting |
Child page |
|
All inline formatting (bold, italic, bold-italic, strikethrough, underline, inline code, links) is preserved in Markdown.
Markdown is parsed and appended to the target page as native Notion blocks. Large content is automatically split into batches of 50 to respect the Notion API limit. Tables are sent with embedded child rows in a single API call.
Tip: Use
notion_get_blocksto find a block ID, then pass it asafter_block_idtonotion_writeto insert content at a specific position rather than the page end.
Toggle blocks, table of contents, files, images, and videos are silently skipped on read and cannot be written.
Empty paragraph blocks are not round-tripped. Spacer paragraphs in Notion are lost on a read → write cycle. This is inherent to a flat Markdown representation.
Table header flag is not round-tripped. The writer always sets has_column_header: true because standard Markdown tables imply a header.
Token efficiency first. Every response is minimal while remaining actionable.
No intermediate files. All content is returned inline as strings — no temp files, no file paths.
Testable without a Notion account. The NotionClient interface is injected; core logic is fully isolated.
Native Notion types. Markdown is converted to real Notion blocks (headings, lists, tables, code blocks, callouts, quotes, to-dos) — not flat text dumps.
git clone https://github.com/AyanoT1/tiny-notion-mcp
cd tiny-notion-mcp
uv sync --dev
uv run pytestTests use a stub NotionClient and make no real API calls — no Notion account or token required.
To update a local Claude Code installation after making changes:
uv tool install . --force --no-cacheThen reconnect the MCP server from Settings → MCP → ⤓ Reconnect.
Toggle block read/write support
Image and file block support
Table of contents block support
Batch write operations
.env file support for token configuration
PyPI distribution
MIT © AyanoT1
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AyanoT1/tiny-notion-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
