A
licenseNot graded
qualityD
maintenanceA Model Context Protocol server that provides a standardized interface for interacting with Notion's API, enabling users to list databases, create pages, and search across their Notion workspace.
111
MIT
Notion MCP Server
by SAhmadUmass
Notion MCP サーバー
Notion 統合用のモデル コンテキスト プロトコル サーバー。Claude や他の LLM が Notion ワークスペースと対話できるようになります。
特徴
Notionを検索: Notionワークスペース全体を検索
ページの取得: 特定のNotionページからコンテンツを取得する
ページを作成: Notionワークスペースに新しいページを作成します
ページの更新: 既存のページを新しいコンテンツまたはタイトルで更新します
データベースの作成: カスタムプロパティを使用して新しいデータベースを作成します
データベースのクエリ: フィルターと並べ替えを使用してデータベースをクエリします
データベースエントリの更新: データベースエントリのプロパティを更新します
データベース行の作成: カスタムプロパティを使用して既存のデータベースに新しい行を追加します
Related MCP server: Notion MCP Server
設定
このリポジトリをクローンする
依存関係をインストールする
npm installNotion APIキーを設定する
Notion開発者ポータルで統合を作成する
APIキーをコピーする
次のいずれかを実行できます。
.envファイルを編集し、your_notion_api_key_here実際のAPIキーに置き換えます。Claude for Desktop 構成に直接渡します (推奨、下記参照)
サーバーを構築する
npm run buildサーバーの実行
npm start
Claude for Desktop の設定
Claude for Desktop をインストールします（まだインストールされていない場合）
Claude for Desktop App の構成を開きます。
macOSの場合:
~/Library/Application Support/Claude/claude_desktop_config.jsonファイルが存在しない場合は作成する
Notion サーバーを設定に追加します。
{ "mcpServers": { "notion": { "command": "node", "args": [ "/Users/shaheerahmad/Documents/notion-mcp-server/dist/index.js", "--notion-api-key=YOUR_ACTUAL_API_KEY_HERE" ] } } }交換する：
/Users/shaheerahmad/Documents/notion-mcp-serverプロジェクトディレクトリへのフルパスを入力します。YOUR_ACTUAL_API_KEY_HEREを実際の Notion API キーに置き換えます
デスクトップ版のClaudeを再起動する
サーバーの使用
Claude for Desktop に接続すると、次のような質問をしてサーバーを使用できるようになります。
「Notionワークスペースで会議メモを検索する」
「プロジェクト計画ページの内容を取得する」（ページIDが必要です）
「Notionでタスクリストを含む新しいページを作成する」
「ID 1aaada269d1b8003adceda69cf7bcd97 の Notion ページを、「ページに追加する新しいコンテンツがあります。」というコンテンツで更新します。」
「NotionページにID 1aaada269d1b8003adceda69cf7bcd97で新しいデータベースを作成します」
「ID 1aaada269d1b8003adceda69cf7bcd97 の Notion データベースで、ステータスが「完了」のアイテムをクエリします。」
Claude はあなたのリクエストに基づいて適切なツールを自動的に使用します。
ツールの使用例
Notionを検索
Search for "meeting notes" in my Notion workspaceページコンテンツを取得
Get the content of my Notion page with ID 1aaada269d1b8003adceda69cf7bcd97新しいページを作成する
Create a new page in Notion with title "Weekly Report" and content "This week we accomplished the following tasks..."既存のページを更新する
Update my Notion page with ID 1aaada269d1b8003adceda69cf7bcd97 with content "Adding this new information to the page."タイトルを更新することもできます。
Update my Notion page with ID 1aaada269d1b8003adceda69cf7bcd97 with title "New Title" and content "New content to add."新しいデータベースを作成する
Create a new database in my Notion page with ID 1aaada269d1b8003adceda69cf7bcd97 with title "Task Tracker" and properties {
"Task Name": { "title": {} },
"Status": {
"select": {
"options": [
{ "name": "Not Started", "color": "red" },
{ "name": "In Progress", "color": "yellow" },
{ "name": "Completed", "color": "green" }
]
}
},
"Priority": {
"select": {
"options": [
{ "name": "Low", "color": "blue" },
{ "name": "Medium", "color": "yellow" },
{ "name": "High", "color": "red" }
]
}
},
"Due Date": { "date": {} }
}データベースのクエリ
Query my Notion database with ID 1aaada269d1b8003adceda69cf7bcd97 with filter {
"property": "Status",
"select": {
"equals": "Completed"
}
}並べ替えを追加することもできます。
Query my Notion database with ID 1aaada269d1b8003adceda69cf7bcd97 with sort {
"property": "Due Date",
"direction": "ascending"
}データベースエントリの更新
既存のデータベース エントリ (データベース内のページ) のプロパティを更新します。
{
"tool_name": "update-database-entry",
"tool_params": {
"pageId": "page_id_of_database_entry",
"properties": {
"Status": {
"select": {
"name": "Completed"
}
},
"Priority": {
"select": {
"name": "High"
}
},
"Due Date": {
"date": {
"start": "2023-12-31"
}
}
}
}
}propertiesパラメータは、データベース内の特定のプロパティタイプに対してNotion APIが期待する構造と一致する必要があります。プロパティタイプ（テキスト、選択、日付など）によって必要なフォーマットが異なります。
データベース行の作成
カスタム プロパティを使用して既存のデータベースに新しい行を追加します。
{
"tool_name": "create-database-row",
"tool_params": {
"databaseId": "your_database_id_here",
"properties": {
"Name": {
"title": [
{
"text": {
"content": "New Task"
}
}
]
},
"Status": {
"select": {
"name": "Not Started"
}
},
"Priority": {
"select": {
"name": "Medium"
}
},
"Due Date": {
"date": {
"start": "2023-12-15"
}
},
"Notes": {
"rich_text": [
{
"text": {
"content": "This is a new task created via the API"
}
}
]
}
}
}
}propertiesパラメータには、データベースに必要なすべてのプロパティを含める必要があり、各プロパティ タイプの Notion API 構造に従う必要があります。
トラブルシューティング
ツールが表示されない場合は、Claude for Desktop のログを確認してください。
tail -n 20 -f ~/Library/Logs/Claude/mcp*.logNotion API キーが正しく設定されており、統合により対話するページへのアクセスが許可されていることを確認してください。
ログに「予期しないトークン」エラーが表示される場合、console.log ステートメントが MCP プロトコルに干渉している可能性があります。このバージョンのサーバーは、これらの問題を回避するために更新されています。
今後の改善
データベースクエリ機能を追加する
コンテンツのフォーマットを改善する
より多くのブロックタイプのサポートを追加
Available Tools
10 toolsadd-articleD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| databaseId | Yes | ||
| generateSummary | No | ||
| url | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create-databaseD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| parentPageId | Yes | ||
| properties | Yes | ||
| title | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create-database-rowD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| databaseId | Yes | ||
| properties | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create-pageD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| parentId | No | ||
| title | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract-url-metadataD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| authorPropertyName | No | ||
| batchSize | No | ||
| databaseId | Yes | ||
| datePropertyName | No | ||
| generateSummary | No | ||
| limit | No | ||
| publicationPropertyName | No | ||
| silentErrors | No | ||
| summaryPropertyName | No | ||
| urlPropertyName | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-pageD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query-databaseD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| databaseId | Yes | ||
| filter | No | ||
| sort | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search-notionD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update-database-entryD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | ||
| properties | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update-pageD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| pageId | Yes | ||
| title | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
10 tool updates
v1.0.0- First observed
add-article - First observed
create-database - First observed
create-database-row - First observed
create-page - First observed
extract-url-metadata - First observed
get-page - First observed
query-database - First observed
search-notion - First observed
update-database-entry - First observed
update-page
TDQS
D1.9/5.0
Scored across 10 tools
Disambiguation4/5
Most tools have distinct purposes targeting different Notion resources and actions, but 'create-database-row' and 'update-database-entry' could be confused as they both modify database entries with unclear boundary between creation and updating. Other tools like 'add-article' vs 'create-page' might overlap if articles are pages, but overall ambiguity is low.
Naming Consistency4/5
Tools follow a consistent kebab-case verb-noun pattern throughout, with clear action-object naming (e.g., 'create-database', 'query-database', 'update-page'). The only minor deviation is 'extract-url-metadata' which uses a different verb style but maintains the same casing convention.
Tool Count5/5
With 10 tools, this is well-scoped for a Notion integration server. The count aligns with typical MCP servers (3-15 tools), covering core operations without being overwhelming or insufficient for the domain.
Completeness3/5
The toolset covers basic CRUD operations for pages and databases, but has notable gaps: no delete operations for pages, databases, or rows/entries, and missing tools for managing blocks, comments, or users. This could lead to dead ends in workflows requiring full lifecycle management.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP-native open-source Notion alternative: read & write pages, databases and kanban boards.
A Model Context Protocol server for Wix AI tools
- TaprootOAuthcom.taproothq
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Related MCP Servers
- AlicenseBqualityDmaintenanceA Model Context Protocol server that connects Claude and other AI assistants to your Notion workspace, allowing AIs to interact with databases, pages, and blocks.127 npm11MIT
- AlicenseAqualityDmaintenanceA Model Context Protocol server that connects AI assistants like Claude to Notion workspaces, enabling them to view, search, create, and update Notion databases, pages, and content blocks.124,521 npm1MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that provides a standardized interface for AI models to access, query, and modify content in Notion workspaces.4,521 npm4MIT