Claude やその他の AI アシスタントを Notion ワークスペースに接続する Model Context Protocol (MCP) サーバー。この統合により、AI アシスタントは Notion のデータベース、ページ、ブロックとやり取りできるようになります。
このツールは、AIアシスタント（Claudeなど）とNotionワークスペースをつなぐ橋渡しとして機能します。AIは以下のことが可能になります。
Notionデータベースの表示と検索
ページの作成と更新
コンテンツブロックを管理する
その他にも多数あります!
Related MCP server: Notion MCP Server
Node.js （バージョン14以上）
Notionアカウント
Claude デスクトップ アプリ (Claude と併用する場合)
https://www.notion.so/my-integrationsにアクセスしてください。
青い**「+新しい統合」**ボタンをクリックします
詳細を入力してください:
名前: 「Claude Assistant」や「AI Helper」などの名前を選択します
ロゴ: オプション
関連ワークスペース: Notionワークスペースを選択してください
**「送信」**をクリック
次のページで、 **「内部統合トークン」**セクションを見つけます
**「表示」**をクリックしてトークンをコピーします（ secret_で始まります）。
オプションA: ZIP形式でダウンロード（初心者に推奨）
GitHub リポジトリに移動します: https://github.com/Sjotie/notionMCP/
右上の緑色の「コード」ボタンをクリックします
「ZIPをダウンロード」を選択
ダウンロードしたら、ZIPファイルをコンピュータ上の場所に解凍します。
Windows: ZIPファイルを右クリックし、「すべて展開」を選択します。
Mac: ZIPファイルをダブルクリックして解凍します
オプション B: Git でクローンする (Git に慣れているユーザー向け)
コマンドプロンプトまたはターミナルを開きます
Windows: Win+Rを押して、 cmdと入力し、Enter を押します。
Mac: アプリケーション > ユーティリティからターミナルを開きます
リポジトリを保存する場所に移動します
cd path/to/desired/locationリポジトリをクローンする
git clone https://github.com/Sjotie/notionMCP/ダウンロードまたはクローン作成後、 cd (ディレクトリ変更) コマンドを使用してプロジェクト フォルダーに移動する必要があります。
ZIP をダウンロードした場合 (オプション A):
コマンドプロンプトまたはターミナルを開きます
cdコマンドを使用して、ZIP ファイルを抽出した場所に移動します。
cd path/to/extracted/folder/notionMCP例えば：
Windowsの場合: cd C:\Users\YourName\Downloads\notionMCP
Macの場合: cd /Users/YourName/Downloads/notionMCP
Git でクローンした場合 (オプション B):
リポジトリは「notionMCP」という名前のフォルダにクローンされているはずです。
クローン作成後も同じターミナル ウィンドウにいる場合は、次のように入力します。
cd notionMCP正しいディレクトリにいるかどうかを確認する方法:
cdコマンドを使用した後、現在の場所を確認できます。
Windowsの場合: dirと入力してEnterキーを押すと、 server.jsのようなファイルが表示されます。
Macの場合: lsと入力してEnterキーを押すと、 server.jsのようなファイルが表示されます。
notionMCP ディレクトリに移動したら、必要な依存関係をインストールします。
npm installこれで必要なNode.jsパッケージがすべてインストールされます。プログレスバーが表示され、インストールが完了したことを示すメッセージが表示されます。「Xパッケージが資金を探しています」といったメッセージが表示される場合もありますが、これは全く正常な動作であり、正常にインストールされたことを意味します。
セキュリティ上の理由から、Notion では各ページまたはデータベースへのアクセスを明示的に許可する必要があります。
Notionを開き、AIにアクセスさせたいページまたはデータベースに移動します
右上隅の**「•••」** （3つの点）をクリックします
**「接続を追加」**を選択
先ほど作成した統合を見つけて選択します
アクセス可能にしたい他のページやデータベースについても繰り返します
Claude Desktop 構成ファイルを見つけます。
Windows: %APPDATA%\Claude\claude_desktop_config.json (このパスをファイルエクスプローラーのアドレスバーに入力してください)
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json (Finder で、Cmd+Shift+G を押してこのパスを貼り付けます)
テキストエディタでファイルを開きます。ファイルが存在しない場合は、以下の内容で作成してください。
{
"mcpServers": {
"notion": {
"command": "node",
"args": [
"C:\\path\\to\\notion-mcp-server\\server.js"
],
"env": {
"NOTION_API_KEY": "your_notion_api_key_here"
}
}
}
}交換する：
C:\\path\\to\\notion-mcp-server\\server.js server.js ファイルへの実際のパスに置き換えます。
Windows: パスに二重のバックスラッシュ (\\) を使用します
Mac: スラッシュ (/) を使用する
your_notion_api_key_hereに Notion API キーを入力します
ファイルを保存し、Claude Desktopを再起動します。
クロードで新しい会話を始める
Claude に Notion ワークスペースを操作するように依頼します。例:
「Notionデータベースのリストを表示」
「タスクデータベースに「テストタスク」というタイトルの新しいページを作成します」
サーバーは AI アシスタントに次のツールを提供します。
list-databases : アクセス可能なすべてのデータベースを表示する
query-database : データベースからエントリを取得する
create-page : データベースに新しいページを追加する
update-page : 既存のページを変更する
create-database : 新しいデータベースを作成する
update-database : データベース構造を変更する
get-page : 特定のページを表示する
get-block-children : コンテンツブロックを表示する
append-block-children : ページにコンテンツを追加する
update-block : コンテンツブロックを編集する
get-block : 特定のブロックを表示する
検索: ワークスペース全体のコンテンツを検索
クロードの「接続に失敗しました」
claude_desktop_config.json のサーバーパスが正しいことを確認してください
Notion APIキーが有効であることを確認してください
Node.jsがインストールされていることを確認する
Notionコンテンツにアクセスすると「アクセスが拒否されました」
ページ/データベースを統合で共有していることを確認してください
APIキーに必要な権限があることを確認してください
サーバーが起動しません
すべての依存関係がインストールされていることを確認する（ npm install ）
APIキーを含む.envファイルが存在することを確認してください
ここで説明されていない問題が発生した場合は、次の手順に従ってください。
コンソール出力でエラーメッセージを確認します
Notion APIキーが有効であることを確認してください
統合がページ/データベースにアクセスできることを確認する
マサチューセッツ工科大学
Append blocks to a parent block
| Name | Required | Description | Default |
|---|---|---|---|
| block_id | Yes | ID of the parent block (page or block) | |
| children | Yes | List of block objects to append | |
| after | No | Optional ID of an existing block to append after |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Append') but lacks details on permissions needed, whether this is a destructive operation, rate limits, error handling, or what happens if 'after' is specified incorrectly. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and wastes no words, making it easy for an agent to parse quickly. Every word earns its place in conveying the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return values, error conditions, or behavioral nuances like how 'after' affects ordering. For a tool that modifies data, more context is needed to ensure correct usage by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the three parameters (block_id, children, after). The description adds no additional meaning beyond what the schema provides, such as examples of block objects or formatting details. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append') and target ('blocks to a parent block'), which is specific and unambiguous. However, it doesn't differentiate this tool from sibling tools like 'update-block' or 'get-block-children', which might also involve block manipulation or retrieval, leaving room for confusion about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'update-block' and 'get-block-children', it's unclear if this is for adding new content, modifying existing blocks, or other scenarios. No context, exclusions, or prerequisites are mentioned, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new database
| Name | Required | Description | Default |
|---|---|---|---|
| parent_id | Yes | ID of the parent page | |
| title | Yes | Database title as rich text array | |
| properties | Yes | Database properties schema | |
| icon | No | Optional icon for the database | |
| cover | No | Optional cover for the database |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new database' implies a write/mutation operation but provides no information about permissions required, whether the operation is idempotent, what happens on failure, or what the response contains. For a creation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single four-word sentence that communicates the essential purpose. There's zero wasted language, and the structure is front-loaded with the core action. Every word earns its place in this minimal but complete statement of function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a database creation tool with 5 parameters (3 required), no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a successful creation, what gets returned, error conditions, or how this differs from page creation. The agent lacks critical context needed to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all 5 parameters thoroughly. The description adds no parameter information beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify usage patterns. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new database'), making the purpose immediately understandable. It distinguishes from siblings like 'list-databases' or 'update-database' by specifying creation rather than listing or modifying. However, it doesn't explicitly differentiate from 'create-page' which creates a different resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when to choose this over 'create-page', or any context about database creation requirements. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new page in a database
| Name | Required | Description | Default |
|---|---|---|---|
| parent_id | Yes | ID of the parent database | |
| properties | Yes | Page properties | |
| children | No | Optional content blocks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a page, implying a write operation, but does not address permissions, side effects, error conditions, or response format. This is a significant gap for a mutation tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized and front-loaded, efficiently conveying the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., what happens on success/failure) and does not compensate for the absence of structured output information, making it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (children, parent_id, properties). The description adds no additional meaning beyond the schema, such as examples or constraints, but since the schema is comprehensive, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('new page in a database'), making the purpose evident. However, it does not differentiate this tool from potential siblings like 'create-database' or 'update-page', which would require specifying that this creates a page within an existing database rather than a database itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a parent database ID), exclusions, or comparisons to siblings like 'append-block-children' or 'update-page', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a block by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| block_id | Yes | ID of the block to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'retrieve' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what happens with invalid IDs. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at just four words. It's front-loaded with the essential action and resource, with zero wasted words. Every element of the description earns its place by communicating the core function efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'block' represents in this context, what format the retrieved data will be in, or any limitations of the retrieval. Given the complexity implied by sibling tools (databases, pages, blocks), more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'block_id' clearly documented in the schema. The description doesn't add any meaningful parameter information beyond what the schema already provides, so it meets the baseline for high schema coverage without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('a block'), making the purpose understandable. It distinguishes this as a read operation rather than a creation or update tool. However, it doesn't explicitly differentiate from similar siblings like 'get-block-children' or 'get-page', which also retrieve content by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get-block-children' (retrieves child blocks), 'get-page' (retrieves pages), and 'search' (finds content), there's no indication of when this specific block retrieval is appropriate versus other lookup methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the children blocks of a block
| Name | Required | Description | Default |
|---|---|---|---|
| block_id | Yes | ID of the block (page or block) | |
| start_cursor | No | Cursor for pagination | |
| page_size | No | Number of results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Retrieve' implies a read operation, it doesn't specify authentication requirements, rate limits, error conditions, or what happens with invalid block IDs. The description lacks crucial behavioral context for a tool that interacts with a content system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a straightforward retrieval operation and gets directly to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'children blocks' means in this system's context, what format the results take, or provide any behavioral context. The description should do more to compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain what constitutes 'children blocks' in this context or provide examples of valid block IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('children blocks of a block'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get-block' or 'get-page', but the focus on children blocks provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get-block' (retrieves a single block), 'get-page' (retrieves a page), and 'search' (finds content), there's no indication of when this specific children-retrieval operation is appropriate versus other retrieval methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a page by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | ID of the page to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves a page but doesn't mention whether this is a read-only operation, what permissions are required, how errors are handled, or what the return format looks like. This leaves significant gaps for a tool that likely interacts with a data source.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that retrieves data with no annotations and no output schema, the description is insufficient. It doesn't explain what 'retrieve' entails (e.g., returns page content, metadata, or both), error conditions, or how it differs from similar tools, leaving the agent with incomplete context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the input schema, which has 100% coverage and clearly documents the 'page_id' parameter. The description implies the parameter is used to identify the page but doesn't provide additional context like format examples or constraints, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and resource ('a page by its ID'), making the tool's purpose immediately understandable. It doesn't differentiate from siblings like 'get-block' or 'get-block-children' which also retrieve content, but the specificity about retrieving a page is adequate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get-block' or 'search'. The description implies it's for retrieving a specific page when you have its ID, but it doesn't explicitly state this or mention prerequisites, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all databases the integration has access to
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires specific permissions, how results are formatted, or if there are rate limits. The description is minimal and lacks essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand quickly with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimal but adequate for basic understanding. However, without annotations or output schema, it lacks details on behavior, result format, or usage context relative to siblings, making it incomplete for optimal agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required, earning a baseline score of 4 for this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('databases'), specifying the scope as 'all databases the integration has access to'. However, it doesn't explicitly differentiate from sibling tools like 'query-database' or 'search', which might also retrieve database information but with different approaches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'query-database' or 'search' from the sibling list. It doesn't mention prerequisites, exclusions, or specific contexts where this tool is preferred over others for listing databases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query a database
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | ID of the database to query | |
| filter | No | Optional filter criteria | |
| sorts | No | Optional sort criteria | |
| start_cursor | No | Optional cursor for pagination | |
| page_size | No | Number of results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is read-only, has side effects, requires permissions, involves rate limits, or describes output format. For a query tool with 5 parameters, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, though it lacks detail. Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, nested objects, no output schema, and no annotations, the description is incomplete. It doesn't explain what the tool returns, how queries are structured, or behavioral traits. For a complex query tool, this leaves critical gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are documented in the schema. The description adds no meaning beyond the schema—it doesn't explain query semantics, filter/sort formats, or pagination behavior. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Query a database' states the basic action (query) and resource (database), which is clear but vague. It doesn't specify what type of query (e.g., SQL, NoSQL, filtered retrieval) or distinguish from siblings like 'search' or 'list-databases'. This provides minimal viable information without differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search' or 'list-databases'. The description implies general querying but doesn't specify contexts, prerequisites, or exclusions. This leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Notion for pages or databases
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query string | |
| filter | No | Optional filter criteria | |
| sort | No | Optional sort criteria | |
| start_cursor | No | Cursor for pagination | |
| page_size | No | Number of results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic action. It doesn't mention whether this is a read-only operation, how results are returned, pagination behavior beyond the schema, rate limits, or authentication needs, leaving significant gaps for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, front-loading the core purpose. It's appropriately sized for a tool with this complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, no output schema) and lack of annotations, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances, failing to provide enough context for effective agent use beyond the basic schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional meaning about parameters beyond implying a general search function, meeting the baseline for high schema coverage without compensating with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and target ('Notion for pages or databases'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'query-database' or 'list-databases' that also retrieve content, missing an opportunity for precise distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'query-database' or 'list-databases'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a block's content or archive status
| Name | Required | Description | Default |
|---|---|---|---|
| block_id | Yes | ID of the block to update | |
| block_type | Yes | The type of block (paragraph, heading_1, to_do, etc.) | |
| content | Yes | The content for the block based on its type | |
| archived | No | Whether to archive (true) or restore (false) the block |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update a block's content or archive status', which implies a mutation operation, but doesn't cover critical aspects like permissions required, whether changes are reversible, error handling, or response format. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error conditions, and what the tool returns, which are crucial for safe and effective use. The description should do more to compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions 'content or archive status', which aligns with the 'content' and 'archived' parameters in the schema, but adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'a block's content or archive status', making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'update-page' or 'update-database', which have similar update operations on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing a block ID, nor does it compare with siblings like 'append-block-children' for adding content or 'get-block' for reading. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing database
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | ID of the database to update | |
| title | No | Optional new title as rich text array | |
| description | No | Optional new description as rich text array | |
| properties | No | Optional updated properties schema |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update an existing database' implies a mutation operation, but it doesn't disclose any behavioral traits: no information about permissions required, whether changes are reversible, rate limits, error conditions, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words: 'Update an existing database.' It's front-loaded with the core action and resource. There's zero wasted language or unnecessary elaboration. While it may be too brief for completeness, it earns full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (update operation) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, what side effects occur, or any behavioral context. The description alone is insufficient for an agent to understand how to properly use this tool beyond the basic action implied by the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents all four parameters (database_id, description, properties, title) with their types and descriptions. The tool description adds no additional meaning about parameters beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing database' clearly states the verb (update) and resource (database), but it's vague about what specifically gets updated. It doesn't distinguish this tool from sibling tools like update-block or update-page, which also perform updates on different resources. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like update-block, update-page, and create-database available, there's no indication of when this tool is appropriate versus those other update/create operations. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing page
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | ID of the page to update | |
| properties | Yes | Updated page properties | |
| archived | No | Whether to archive the page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update an existing page' which implies a mutation operation, but doesn't specify what permissions are required, whether changes are reversible, or what happens to unspecified properties. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, front-loading the essential information with zero wasted words. Every element ('Update', 'an existing page') earns its place by clearly communicating the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'update' entails operationally, what the response looks like, or potential side effects. Given the complexity of updating a page with properties and archival options, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and target resource ('an existing page'), making the tool's purpose immediately understandable. It distinguishes from sibling tools like 'create-page' by specifying it works on existing pages, though it doesn't differentiate from 'update-block' or 'update-database' which also update resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update-block' or 'update-database', nor does it mention prerequisites such as needing a valid page_id. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0append-block-childrencreate-databasecreate-pageget-blockget-block-childrenget-pagelist-databasesquery-databasesearchupdate-blockupdate-databaseupdate-pageScored across 12 tools
Each tool has a clearly distinct purpose targeting specific Notion resources (blocks, databases, pages) and actions (create, get, update, list, query, search, append). There is no overlap or ambiguity between tools, as they cover different resource-action combinations with precise scopes.
All tools follow a consistent verb-noun pattern using kebab-case (e.g., create-database, update-page, get-block). The naming is predictable and uniform across all 12 tools, with verbs like create, get, update, list, query, search, and append consistently applied to appropriate nouns.
With 12 tools, the server is well-scoped for managing Notion's core entities (blocks, databases, pages). Each tool earns its place by covering essential CRUD and query operations without redundancy, making it neither too sparse nor overloaded for the domain.
The tool set provides complete CRUD/lifecycle coverage for Notion's main resources: databases (create, update, list, query), pages (create, get, update), and blocks (get, update, append, get children). It also includes search functionality, leaving no obvious gaps for agent workflows in this domain.
Hosted Notion MCP server for Claude, ChatGPT and Cursor, with each action switched per account.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Hosted Airtable MCP server for Claude, ChatGPT and Cursor, with each action switched per account.
Official Fibery MCP server: query and update your workspace from any AI client via OAuth.
