공식 Notion MCP에 비해 토큰 사용량을 최소화한 경량 Notion MCP 서버입니다.
원시 Notion API JSON을 반환하는 대신, 모든 도구가 가장 유용한 최소한의 표현을 반환합니다. 페이지는 일반 Markdown으로, 검색 결과는 결과당 한 줄로 반환됩니다. 실제로 이는 읽기 중심의 워크플로우에서 토큰 소비량을 크게 줄여줍니다.
도구 | 설명 |
| 제목으로 페이지를 검색합니다. 결과당 한 줄씩 TOON 형식으로 반환합니다. |
| 페이지를 Markdown으로 읽습니다. |
| 기존 페이지에 Markdown을 추가합니다. |
| 상위 페이지 아래에 하위 페이지를 생성하며, 선택적으로 콘텐츠를 포함할 수 있습니다. |
검색 결과 및 페이지 생성 응답은 간결한 TOON(Title | Object | Optional Notes) 형식을 사용합니다:
Page title | page-id | https://notion.so/... | parent:<parent-id>이를 통해 검색 응답이 수백 개의 JSON 토큰 대신 결과당 한 줄로 유지됩니다.
Related MCP server: Markdown-To-Notion
notion_read)블록 유형 | Markdown 출력 | |
단락 | 일반 텍스트 | |
제목 1 / 2 / 3 |
| |
글머리 기호 목록 항목 |
| |
번호 매기기 목록 항목 |
| |
코드 블록 |
| |
표 | 파이프(` | `)로 구분된 행 |
하위 페이지 |
|
인라인 서식(굵게, 기울임꼴, 굵은 기울임꼴, 취소선, 밑줄, 인라인 코드, 링크)은 Markdown으로 유지됩니다.
notion_write)쓰기 시에도 동일한 블록 유형이 지원됩니다. Markdown은 파싱되어 대상 페이지에 네이티브 Notion 블록으로 추가됩니다.
다음 블록 유형은 Notion에서 인식되지만 아직 처리되지 않습니다. 읽기 시 무시되며 쓰기가 불가능합니다:
구분선 (---)
인용구
할 일 / 체크박스 목록
콜아웃 블록
토글 목록
목차
파일, 이미지 및 비디오
서로 다른 목록 유형 사이의 빈 단락 블록은 왕복(round-trip)되지 않습니다. 페이지에 글머리 기호 목록과 번호 매기기 목록을 구분하는 명시적인 빈 단락이 있는 경우, 읽기 → 쓰기 주기를 거치면 해당 구분자가 손실됩니다. 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.
