Scrapbox AI Assistant
Enables advanced knowledge management by providing search, filtering, page relationship analysis, theme extraction, and literary analysis of Scrapbox project data. Supports exporting and processing large datasets with automatic data splitting capabilities.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Scrapbox AI Assistantsearch my knowledge base for pages about creative writing"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🤖 Scrapbox AI Assistant
Scrapbox を Claude Code で活用するための MCP サーバ
あなたの Scrapbox の知識・創作・内省データを Claude Code と連携させ、AI による高度な知識管理と創作支援を実現します。
✨ 特徴
🔍 知的検索: Scrapbox データの高度な検索・フィルタリング
🔗 関連性分析: ページ間のつながりと知識ネットワークの可視化
📝 創作支援: 文学的分析と創作継続のための AI プロンプト
🎯 テーマ抽出: 大量のデータから潜在的なパターンとテーマを発見
📊 大容量対応: 数万ページのデータも分割処理で高速化
🛡️ プライバシー保護: 個人データの安全な管理とGit除外
🚀 クイックスタート
📦 デモでの体験
# リポジトリをクローン
git clone https://github.com/yourusername/scrapbox-ai-assistant.git
cd scrapbox-ai-assistant
# 依存関係のインストール
npm install
# ビルド
npm run build
# デモ設定をコピー
cp scrapbox-config.example.json scrapbox-config.json
# デモサーバー起動
npm start詳細なデモ手順は DEMO.md をご覧ください。
🛠️ 実際のデータでのセットアップ
1. Scrapbox データの準備
Scrapbox の「設定」→「ページデータ」→「ページをエクスポート」
JSON ファイルをダウンロード
./data/ディレクトリに配置
2. 設定ファイルの作成
cp scrapbox-config.example.json scrapbox-config.json設定例：
{
"projects": [
{
"name": "my-knowledge-base",
"exportDataPath": "./data/my-export.json",
"description": "私の知識ベース"
}
]
}3. 大容量データの分割（オプション）
# 15個のファイルに分割
node scripts/split-json.js ./data/my-export.json ./data/parts 15🎯 主な機能
MCP リソース
scrapbox://projects- プロジェクト一覧scrapbox://projects/{project}/pages- ページ一覧scrapbox://projects/{project}/pages/{page}- 個別ページ詳細scrapbox://projects/{project}/tags- タグ一覧
MCP ツール
search_pages- 高度な検索・フィルタリングanalyze_connections- ページ間関連性分析extract_themes- テーマ・パターン抽出
MCP プロンプト
literary_analysis- 文学的分析支援creative_continuation- 創作継続支援knowledge_synthesis- 知識統合支援
🛡️ プライバシーとセキュリティ
⚠️ 重要な注意事項
このツールは個人的な Scrapbox データを処理します：
個人データファイルは絶対に Git リポジトリにコミットしないでください
.gitignoreによりdata/ディレクトリは自動的に除外されます設定ファイル
scrapbox-config.jsonも Git 管理から除外されますデモ用サンプルデータは安全な架空データです
保護されるファイル
data/ # 個人のScrapboxデータ
scrapbox-config.json # 個人設定
*-analysis-results.json # 分析結果🔧 Claude Code との連携
MCP サーバーの設定
Claude Code の設定に以下を追加：
{
"mcpServers": {
"scrapbox": {
"command": "node",
"args": ["/path/to/scrapbox-ai-assistant/dist/index.js"],
"env": {
"SCRAPBOX_CONFIG_PATH": "/path/to/scrapbox-config.json"
}
}
}
}使用例
知識検索
search_pages クエリ:"創作について" プロジェクト:["my-knowledge"] タグ:["詩", "エッセイ"]関連性分析
analyze_connections プロジェクト:"knowledge-base" ページ:"哲学について" 深度:3テーマ抽出
extract_themes プロジェクト:"reading-notes" 期間:{開始:"2024-01-01", 終了:"2024-12-31"}文学的分析
@literary_analysis テキスト:"[創作断片]" 視点:"ポストモダン文学"💻 開発とカスタマイズ
プロジェクト構造
src/
├── types.ts # 型定義
├── scrapbox-client.ts # Scrapbox API クライアント
├── mcp-server.ts # MCP サーバ実装
└── index.ts # エントリーポイント
scripts/
├── split-json.js # データ分割スクリプト
└── analyze-tags.js # タグ分析スクリプト
data/
├── sample-export.json # デモ用サンプルデータ
└── parts-sample/ # 分割デモデータ
├── demo-part1.json
├── demo-part2.json
└── demo-part3.json開発モード
# 開発サーバー起動
npm run dev
# スタンドアロン実行
npm start
# ビルド
npm run build新機能の追加
型定義:
src/types.tsに必要な型を追加データ処理:
src/scrapbox-client.tsに処理ロジック実装MCP エンドポイント:
src/mcp-server.tsに API 追加
カスタムプロンプトの作成
// 新しいプロンプトの追加例
server.setRequestHandler(ListPromptsRequestSchema, async () => ({
prompts: [
{
name: "custom_analysis",
description: "カスタム分析プロンプト",
arguments: [
{ name: "content", description: "分析対象テキスト", required: true },
{ name: "perspective", description: "分析視点", required: false }
]
}
]
}));🤝 コントリビューション
このプロジェクトへの貢献を歓迎します！
貢献方法
Issue の報告: バグ報告や機能要望
Pull Request: コード改善や新機能の追加
ドキュメント: 使用例や説明の改善
フィードバック: 使用感や改善提案
開発に参加する
# フォークしてクローン
git clone https://github.com/yourusername/scrapbox-ai-assistant.git
cd scrapbox-ai-assistant
# 依存関係をインストール
npm install
# 開発開始
npm run devガイドライン
プライバシー重視: 個人データの保護を最優先
型安全: TypeScript を活用した堅牢な実装
MCP標準準拠: Model Context Protocol の仕様に従った実装
テスト: 新機能には適切なテストを追加
📄 ライセンス
MIT License - 詳細は LICENSE ファイルをご覧ください。
🙏 謝辞
Scrapbox - 素晴らしい知識管理プラットフォーム
Claude Code - AI駆動の開発環境
Model Context Protocol - AI統合の標準化
📞 サポート
Issues: GitHub Issues
Discussions: GitHub Discussions
Documentation: Wiki
⚠️ 注意: このツールは個人の知識管理を支援する目的で開発されています。個人データの取り扱いには十分ご注意ください。
Available Tools
3 toolsanalyze_connectionsC
Analyze connections and relationships between pages
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | Yes | Project name | |
| pageTitle | Yes | Starting page title | |
| depth | No | Connection depth to analyze | |
| connectionTypes | No |
TDQS
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. While 'analyze' suggests a read-only operation, the description doesn't clarify permissions needed, computational cost, whether this is a heavy operation, what format results come in, or any rate limits. For a tool with 4 parameters and no annotation coverage, this is insufficient.
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 - a single sentence that gets straight to the point without any fluff. Every word earns its place by communicating the core functionality efficiently, making it easy for an agent 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 with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what kind of analysis is performed, what format results are returned in, computational characteristics, or how this differs from sibling tools. The agent would struggle to use this tool effectively without additional context.
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 75%, with three parameters having descriptions and one (connectionTypes) lacking description. The tool description adds no additional parameter information beyond what's in the schema - it doesn't explain what 'depth' means in practical terms, what the connection types represent, or how parameters interact. With decent schema coverage, this meets the baseline.
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 ('analyze') and resource ('connections and relationships between pages'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'extract_themes' or 'search_pages' - both could also involve analyzing page relationships, so differentiation is missing.
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 'extract_themes' or 'search_pages'. There's no mention of specific scenarios, prerequisites, or comparative use cases that would help an agent choose appropriately between these sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_themesC
Extract themes and patterns from pages
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | Yes | Project name | |
| dateRange | No | ||
| tags | No | Filter by tags | |
| limit | No | Maximum number of themes |
TDQS
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. It mentions extraction but doesn't specify whether this is a read-only operation, if it requires specific permissions, what the output format might be, or any rate limits. The description is too brief to provide meaningful behavioral context beyond the basic 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?
The description is extremely concise at just 5 words. It's front-loaded with the core action and resource. While potentially too brief for completeness, every word earns its place by conveying essential information without 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 has 4 parameters, no annotations, no output schema, and a vague purpose, the description is inadequate. It doesn't explain what constitutes a 'theme' or 'pattern', how results are returned, or what the relationship is between the input parameters and the extraction process. The description leaves too many open questions for effective tool selection.
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 75% (3 of 4 parameters have descriptions), so the baseline is 3. The description doesn't add any parameter semantics beyond what's in the schema - it doesn't explain how 'projectName' relates to 'pages', what 'themes' might look like, or how 'tags' filtering interacts with theme extraction.
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 states the tool's purpose as 'Extract themes and patterns from pages', which is clear but vague. It specifies the verb 'extract' and resource 'themes and patterns from pages', but doesn't differentiate from sibling tools like 'analyze_connections' or 'search_pages', nor does it clarify what 'pages' refers to in this context.
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 'analyze_connections' or 'search_pages'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_pagesC
Search pages across Scrapbox projects with intelligent filtering
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| projects | No | Project names to search in | |
| tags | No | Filter by tags | |
| creativeType | No | Filter by creative type | |
| limit | No | Maximum number of results |
TDQS
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 mentions 'intelligent filtering' but doesn't elaborate on what that entails (e.g., ranking, pagination, rate limits, or authentication needs). For a search tool with zero annotation coverage, this lacks critical operational details.
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 redundancy. It's appropriately sized and front-loaded, with no wasted words, 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 no annotations and no output schema, the description is incomplete for a search tool with 5 parameters. It doesn't explain result format, error handling, or the 'intelligent filtering' mentioned, leaving gaps in understanding the tool's behavior and output.
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 has 100% description coverage, clearly documenting all 5 parameters. The description adds no additional parameter semantics beyond the schema, such as query syntax or filtering logic. Baseline 3 is appropriate when the schema handles all parameter documentation.
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's purpose: 'Search pages across Scrapbox projects with intelligent filtering.' It specifies the verb ('search'), resource ('pages'), and scope ('across Scrapbox projects'), but doesn't explicitly differentiate from sibling tools like 'analyze_connections' or 'extract_themes' beyond the search focus.
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 mentions 'intelligent filtering' but doesn't specify scenarios, prerequisites, or exclusions, nor does it reference sibling tools for comparison, leaving usage context ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a clearly distinct purpose: analyze_connections focuses on relationships between pages, extract_themes identifies patterns and themes, and search_pages handles finding pages with filtering. There is no overlap in functionality, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern with snake_case (analyze_connections, extract_themes, search_pages). The naming is predictable and readable, with no deviations or mixed conventions.
With only 3 tools, the set feels thin for an 'AI Assistant' server, potentially lacking operations like creating, updating, or deleting pages. While the tools are well-defined, the count is borderline low for comprehensive assistance in a content management domain like Scrapbox.
The tool surface is significantly incomplete for a Scrapbox AI Assistant. There are obvious gaps in CRUD/lifecycle coverage—no tools for creating, editing, or managing pages or projects—which will likely cause agent failures when trying to perform basic content operations.
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Search, read, create and edit your Memol notes from Claude. Team note-taking with AI search.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yoheitabo/scrapbox-ai-assistant'
If you have feedback or need assistance with the MCP directory API, please join our Discord server