Cosense（旧 Scrapbox） 用の MCP サーバーです。
ツール | 説明 | 認証が必要 |
| ページのコンテンツ、メタデータ、リンクを取得します | 非公開プロジェクトの場合 |
| 並べ替えとページネーションでページを閲覧します（最大1000件） | 非公開プロジェクトの場合 |
| キーワードハイライト付きの全文検索（最大100件） | 非公開プロジェクトの場合 |
| WebSocket API を使用して Markdown / Scrapbox ボディでページを作成します | はい |
| ページの直接 URL を生成します | いいえ |
| ページ内の指定行の後にテキストを挿入します | はい |
| 完全一致する行を置換します（複数行ブロックを含む。最初の一致、または | はい |
| 完全一致する行を削除します（複数行ブロックを含む。最初の一致、または | はい |
| すべての行を空にしてページを削除します — オプトイン、後述 | はい |
| ページの全コンテンツを置き換えます — オプトイン、後述 | はい |
| AI 向けに最適化された形式でページとそのリンク先ページ（1-hop/2-hop）を取得します | はい |
create_page、insert_lines、edit_lines、rewrite_page は、コンテンツ変換を制御する format パラメータ（"markdown" または "scrapbox"）をサポートしています。
edit_lines はデフォルトでは最初に一致した行のみを置換します。すべての出現箇所を置換するには matchAll: true を設定します。デフォルトは意図的に慎重になっています。箇条書きマーカーや空行などの行はページ内で何度も繰り返される可能性があり、一度にすべてを置換することは呼び出し側の意図と一致しないことがほとんどだからです。
targetLineText は改行を含めて連続する複数行のブロックに一致させることができます。ブロックは全体として置換されるため、n 行を m 行にできます（例: 複数行を1行にまとめる）。matchAll: true のブロック一致は重複しません。
delete_lines は同じ完全一致（およびブロック）のセマンティクスを使用しますが、一致した行を置換するのではなく削除します。タイトル行（最初の行）の削除は拒否されます。ページ自体の名前変更や削除につながるためです。その場合は delete_page を使用してください。
delete_page と rewrite_page はオプトインdelete_page と rewrite_page は、COSENSE_ENABLE_DELETE=true が設定されない限り登録されません。設定がない場合、どちらのツールもツールリストに一切表示されないため、エージェントが誤って呼び出すこともできません。このサーバーは共有の MCP 構成に追加されることが多いため、ページ全体の破壊は意図的に有効にした人だけに公開されます。
理由: insert_lines、edit_lines、delete_lines はすべて完全一致を必要とし、それは呼び出し側が実際にページを読んだ場合にのみ可能です。つまり、すでに知っている行しか破壊できません。delete_page と rewrite_page は呼び出し側がページを読んだかどうかに関係なくページ全体に作用するため、別のオプトインゲートを設けています。
delete_page はページのすべての行を空にし、Cosense はすべての行が空になるとページを削除します。元に戻すことはできません。さらに2つのガードが組み込まれています:
ページが存在している必要があります。存在しないページは、黙って成功するのではなくエラーを返します。（REST API は作成されていないページでもタイトル行を返すため、create_page と同じ方法で persistent を確認します。）
dryRun: true は、削除される行数と最初の5行を表示しますが、ページには触れません。
rewrite_page はページの全コンテンツを置き換えます（タイトルは最初の行として保持されます）。同じガードに加えて、独自のガードが2つあります:
ページが存在している必要があります — persistent の確認は create_page と逆で、タイプミスによって新しいページが黙って作成されることはありません。
空のコンテンツは拒否されます — ページの削除は delete_page の役割です。
dryRun: true は、変更前後の行数とプレビューを表示しますが、ページには触れません。
異なるプロジェクト用にこのサーバーの複数のインスタンスを実行する場合、削除を許可する各インスタンスに変数を設定してください:
{
"mcpServers": {
"cosense-notes": {
"command": "npx",
"args": ["-y", "scrapbox-cosense-mcp"],
"env": {
"COSENSE_PROJECT_NAME": "notes",
"COSENSE_SID": "s:your-session-id",
"COSENSE_TOOL_SUFFIX": "notes",
"COSENSE_ENABLE_DELETE": "true"
}
},
"cosense-archive": {
"command": "npx",
"args": ["-y", "scrapbox-cosense-mcp"],
"env": {
"COSENSE_PROJECT_NAME": "archive",
"COSENSE_SID": "s:your-session-id",
"COSENSE_TOOL_SUFFIX": "archive"
}
}
}
}ここでは、notes インスタンスは delete_page_notes を公開し、archive インスタンスは削除ツールを一切公開しません。
insert_lines と edit_lines は、対象の行が存在しない場合の動作が異なります。insert_lines はページの末尾に追記します。「このテキストをどこかに追加」にはまだ妥当な結果があるためです。edit_lines はエラーを返し、ページには触れません。「この特定の行を置換」には意味のあるフォールバックがないためです。置換テキストを追記すると、呼び出し側が求めていないページが黙って生成されることになります。
Related MCP server: scrapbox-cosense-mcp-editable
GitHub Releases から scrapbox-cosense-mcp.mcpb をダウンロードします
ダブルクリック — Claude Desktop にインストールダイアログが表示されます
プロジェクト名を入力します（非公開プロジェクトの場合はセッション ID も）
マーケットプレイスを追加:
/plugin marketplace add worldnine/scrapbox-cosense-mcpプラグインをインストール:
/plugin install scrapbox-cosense@worldnine-scrapbox-cosense-mcpデフォルトではグローバルにインストールされます。他のスコープには --scope project または --scope local を使用します。
設定ファイルに環境変数を設定:
{
"env": {
"COSENSE_PROJECT_NAME": "your_project_name",
"COSENSE_SID": "your_sid"
}
}ファイル | スコープ |
| すべてのプロジェクト（グローバル） |
| このプロジェクトのみ（gitignore 対象） |
プラグインには MCP サーバー設定と CLI 操作用の /cosense スキルが含まれています。
プラグインではなく手動で設定する場合は:
claude mcp add scrapbox-cosense-mcp \
-e COSENSE_PROJECT_NAME=your_project \
-e COSENSE_SID=your_sid \
-- npx -y scrapbox-cosense-mcp設定ファイルに追加:
クライアント | 設定ファイル |
Claude Desktop (macOS) |
|
Claude Desktop (Windows) |
|
Cursor |
|
Windsurf |
|
{
"mcpServers": {
"scrapbox-cosense-mcp": {
"command": "npx",
"args": ["-y", "scrapbox-cosense-mcp"],
"env": {
"COSENSE_PROJECT_NAME": "your_project_name",
"COSENSE_SID": "your_sid"
}
}
}
}git clone https://github.com/worldnine/scrapbox-cosense-mcp.git
cd scrapbox-cosense-mcp
npm install && npm run build変数 | 説明 |
| あなたの Scrapbox/Cosense プロジェクト名 |
| 非公開プロジェクト用のセッション ID（ |
変数 | デフォルト | 説明 |
|
| API ドメイン |
|
| ツール説明内の表示名 |
|
| 初回ページ取得制限（1〜1000） |
|
| 初期ソート: updated、created、accessed、linked、views、title |
| — | 複数インスタンス用のツール名サフィックス（例: |
|
| Markdown 変換で番号付きリストを箇条書きリストに変換します |
|
| 初期リソースリストからピン留めページを除外します |
|
|
|
同じバイナリはスタンドアロン CLI としても機能します:
scrapbox-cosense-mcp get "Page Title"
scrapbox-cosense-mcp search "keyword"
scrapbox-cosense-mcp list --sort=updated --limit=20
scrapbox-cosense-mcp create "New Page" --body="Markdown content"
scrapbox-cosense-mcp insert "Page" --after="target line" --text="new text"
scrapbox-cosense-mcp edit "Page" --target="old line" --text="new text"
scrapbox-cosense-mcp delete-lines "Page" --target="old line"
scrapbox-cosense-mcp delete "Page" --dry-run # needs COSENSE_ENABLE_DELETE=true
scrapbox-cosense-mcp rewrite "Page" --body="new content" --dry-run # needs COSENSE_ENABLE_DELETE=true
scrapbox-cosense-mcp url "Page Title"フラグ | 説明 |
| トークン効率の良いコンパクトな出力（AI エージェント推奨） |
| プロジェクト名を上書き |
| JSON として出力 |
| ヘルプを表示（詳細は |
すべてのツールは、単一のサーバーから別のプロジェクトを対象にするためのオプションの projectName パラメータを受け入れます。資格情報が異なる複数の非公開プロジェクトの場合は、COSENSE_TOOL_SUFFIX を使用して個別のサーバーインスタンスを実行します。
詳細な設定例については docs/multiple-projects.md を参照してください。
コマンド | 説明 |
| ビルド（TypeScript → JavaScript） |
| 開発中の自動リビルド |
| テストスイートを実行 |
| ESLint を実行 |
| MCP Inspector でデバッグ |
main からフィーチャーブランチを作成します
変更に対するテストを追加します
npm run lint && npm test を実行します
プルリクエストを作成します — CI が自動的に実行されます
MIT
Create a new page in Scrapbox project on cosense (scrapbox). Creates a new page with the specified title and optional body text. Returns the page creation URL without opening browser. Uses my-cosense-project project as default if projectName is not specified.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Content in markdown format (default) or Scrapbox syntax (when format is 'scrapbox'). Avoid duplicating the title in the body since it's automatically displayed at the top. Supports links, code blocks, lists, and emphasis. | |
| title | Yes | Title of the new page | |
| format | No | Content format of the body. 'markdown' (default) converts Markdown to Scrapbox syntax. 'scrapbox' passes content through as-is, preserving Scrapbox-native indentation and syntax. | |
| projectName | No | Target project name. If not specified, defaults to 'my-cosense-project'. | |
| createActually | No | Whether to actually create the page using WebSocket API. If true (default), creates the page immediately. If false, returns only the creation URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral details. It discloses that it uses the WebSocket API, returns the page creation URL without opening a browser, and mentions the createActually flag behavior. It doesn't address error handling, idempotency, or permissions, which are relevant for a write operation. Overall, it provides some behavioral insight but leaves 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 three sentences and front-loaded with the core action and outcome. It packs essential information about return behavior and defaults without redundancy. Every sentence adds value; no fluff.
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?
With 5 parameters, no output schema, and no annotations, the description covers the key aspects: creation, default project, body format, and the createActually flag. It does not mention what happens if the page already exists or error conditions, but for a straightforward create tool that's acceptable. The description is complete enough for typical agent use, with the main gaps being edge cases.
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 each parameter already has a description. The description adds a useful note about not duplicating the title in the body ('Avoid duplicating the title in the body since it's automatically displayed at the top') and clarifies the default behavior for format and projectName. This exceeds what the schema states, but not significantly, so a baseline 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 a new page in Scrapbox project on cosense (scrapbox).' It specifies the verb 'create' and the resource 'new page', and distinguishes itself from siblings like search_pages, get_page, and edit_lines by focusing on creation. The phrase 'returns the page creation URL without opening browser' adds clarity on the outcome.
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 mentions the default project behavior ('Uses my-cosense-project as default if projectName is not specified') and the body format options, giving context for usage. However, it does not explicitly state when to use this tool over siblings (e.g., when to prefer create_page vs edit_lines), though the create-vs-edit distinction is implicit. No exclusions or when-not-to-use guidance is given, but for a creation tool, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one or more lines from a Scrapbox page on cosense (scrapbox). Matches the target by exact text. If targetLineText contains newline characters, it is matched as a contiguous block of lines and removed as a whole. By default only the first match is removed; set matchAll to remove every (non-overlapping) occurrence. Refuses to delete the title line (the first line), which would rename or remove the page — use delete_page for that. Returns an error if no match is found. Requires COSENSE_SID. Uses my-cosense-project project as default if projectName is not specified.
| Name | Required | Description | Default |
|---|---|---|---|
| matchAll | No | If true, delete every occurrence of the target (a single line or a contiguous block). Block matches are non-overlapping. The operation is atomic: if any match includes the title line, the whole call is refused. Defaults to false (delete only the first match). | |
| pageTitle | Yes | Title of the page to modify | |
| projectName | No | Target project name. If not specified, defaults to 'my-cosense-project'. | |
| targetLineText | Yes | Exact text of the line(s) to delete. Matching is case-sensitive and requires full-line exact matches. If it contains newline characters, the consecutive lines are matched as a contiguous block and removed as a whole. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses matching semantics, block removal with newlines, default first-match behavior, matchAll option, refusal to delete title line, error handling for no match, authentication requirement (COSENSE_SID), and default project. This is highly transparent.
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, well-organized paragraph that front-loads the primary action and then details edge cases and constraints. Every sentence conveys necessary information without fluff, making it appropriately sized for the complexity.
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?
As a mutation tool with no output schema and no annotations, the description covers all critical aspects: operation semantics, edge cases (title line, multiple matches, block removal), error conditions, authentication, and defaults. It is complete for the tool's complexity.
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 the schema is thorough, but the description adds substantial value: exact-match and case-sensitive semantics, newline as block, atomicity for block matches, title-line protection, and default project behavior. This goes beyond the schema's 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 deletes lines from a Scrapbox page and matches by exact text. It also differentiates from delete_page for deleting the title line, distinguishing it from sibling tools.
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 explicit guidance on when to use (delete lines) and when not (use delete_page for deleting the page/title). Also mentions default project behavior, though it doesn't contrast with edit_lines or insert_lines, but the core use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace one or more lines in a Scrapbox page on cosense (scrapbox). Matches the target by exact text and substitutes it with new content (which may span multiple lines). If targetLineText contains newline characters, it is matched as a contiguous block of lines, so any n lines can be replaced with m lines. By default only the first match is replaced; set matchAll to replace every (non-overlapping) occurrence. Returns an error if no match is found. Requires COSENSE_SID. Uses my-cosense-project project as default if projectName is not specified.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Content format of newText. 'markdown' (default) converts Markdown to Scrapbox syntax. 'scrapbox' passes content through as-is, preserving Scrapbox-native indentation and syntax. | |
| newText | Yes | Replacement content in markdown format (default) or Scrapbox syntax (when format is 'scrapbox'). May contain multiple lines separated by newline characters. | |
| matchAll | No | If true, replace every occurrence of the target (a single line or a contiguous block). Block matches are non-overlapping. Defaults to false (replace only the first match). | |
| pageTitle | Yes | Title of the page to modify | |
| projectName | No | Target project name. If not specified, defaults to 'my-cosense-project'. | |
| targetLineText | Yes | Exact text of the line(s) to replace. Matching is case-sensitive and requires full-line exact matches. If it contains newline characters, the consecutive lines are matched as a contiguous block and replaced as a whole. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: exact, case-sensitive matching; contiguous newline-block replacement; non-overlapping matchAll; error on missing match; and COSENSE_SID requirement. This gives an agent strong information about side effects and failure modes.
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 compact, front-loaded, and has no filler. Every sentence adds a meaningful behavior or default, while keeping the total length reasonable for a six-parameter tool.
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 output schema and no annotations, the description is complete: it covers purpose, matching semantics, default behavior, multi-line replacement, project fallback, auth, and error conditions. This gives an agent everything needed to select and invoke the 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 coverage is 100%, and the schema already explains targetLineText, newText, format, matchAll, and projectName. The description adds only marginal context beyond the schema, such as 'any n lines can be replaced with m lines' and the no-match error, but not enough to move far beyond the schema 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?
Description opens with 'Replace one or more lines in a Scrapbox page on cosense (scrapbox)', a specific verb and resource. It clearly frames edit_lines as replacement behavior, distinguishing it from insert_lines and delete_lines.
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 clear context: exact-text matching, block replacement, first-match default, matchAll option, no-match errors, and auth requirement. It does not explicitly name sibling tools as alternatives or exclusions, but it is easy for an agent to infer when replacement is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a page from Scrapbox project on cosense (scrapbox). Returns page content and its linked pages. Page content includes title and description in plain text format. Uses my-cosense-project project as default if projectName is not specified.
| Name | Required | Description | Default |
|---|---|---|---|
| pageTitle | Yes | Title of the page | |
| projectName | No | Target project name. If not specified, defaults to 'my-cosense-project'. |
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 key behaviors: it returns 'page content and its linked pages' and specifies the format ('plain text format'). However, it misses details like error handling (e.g., what happens if the page doesn't exist), performance aspects, or authentication needs, which are important for a read operation without annotations.
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 appropriately sized with three sentences that are front-loaded: the first states the purpose, the second details returns, and the third covers defaults. There is no wasted text, but it could be slightly more structured (e.g., bullet points for returns) without losing 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 no annotations and no output schema, the description partially compensates by explaining return values ('page content and its linked pages') and format. However, for a tool with two parameters and no structured output, it lacks completeness in areas like error cases, pagination, or example usage, leaving gaps for an AI agent to infer behavior.
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 both parameters fully. The description adds minimal value beyond the schema by reiterating the default for 'projectName' ('my-cosense-project'), but does not provide additional context like examples or constraints. This 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 tool's purpose: 'Get a page from Scrapbox project on cosense (scrapbox).' It specifies the verb ('Get') and resource ('page'), and distinguishes it from siblings like 'create_page' (creation) and 'list_pages' (listing). However, it doesn't explicitly differentiate from 'get_page_url' (which might retrieve a URL rather than content), leaving some ambiguity.
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 implies usage by stating it 'Uses my-cosense-project project as default if projectName is not specified,' which provides context for when to omit a parameter. However, it lacks explicit guidance on when to use this tool versus alternatives like 'search_pages' or 'get_page_url,' and does not mention prerequisites or exclusions, leaving usage somewhat inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate URL for a page in Scrapbox project on cosense (scrapbox). Returns the direct URL to the specified page without opening it in browser. Uses my-cosense-project project as default if projectName is not specified.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the page | |
| projectName | No | Target project name. If not specified, defaults to 'my-cosense-project'. |
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 adds useful context: the tool generates a URL without browser interaction and has a default project. However, it does not cover potential errors (e.g., if the page doesn't exist), rate limits, authentication needs, or the exact URL format, leaving gaps in behavioral transparency for a tool with no annotation support.
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 concise and well-structured, consisting of two sentences that efficiently convey the tool's purpose, behavior, and default parameter. Every sentence adds value: the first defines the action and context, and the second clarifies the default project and non-browser behavior, with no redundant or wasted 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?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers the core functionality and default behavior adequately, but lacks details on error handling, return format (beyond 'direct URL'), and differentiation from siblings. Without annotations or output schema, more context would improve completeness for safe agent 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?
Schema description coverage is 100%, with clear descriptions for both parameters in the input schema. The description adds marginal value by reiterating the default project behavior for 'projectName,' but does not provide additional semantic context beyond what the schema already documents, such as examples or constraints on the 'title' parameter. Baseline 3 is appropriate given 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 tool's purpose: 'Generate URL for a page in Scrapbox project on cosense (scrapbox).' It specifies the verb ('Generate URL'), resource ('a page'), and platform context ('Scrapbox project on cosense'). However, it does not explicitly differentiate from sibling tools like 'get_page' (which likely retrieves page content rather than just the URL), leaving room for improvement.
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 some usage context by mentioning the default project ('my-cosense-project') and that it 'Returns the direct URL... without opening it in browser,' which implies a non-interactive use case. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_page' or 'list_pages,' and does not specify prerequisites or exclusions, relying on implied understanding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get smart context for a page on cosense (scrapbox). Returns the target page and its linked pages (1-hop or 2-hop) with full content in AI-optimized format. Useful for understanding the context and related knowledge around a specific topic. Requires COSENSE_SID authentication. Uses my-cosense-project project as default if projectName is not specified.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the page to get context for | |
| hopCount | No | Number of link hops to include. 1 (default) returns directly linked pages. 2 returns pages linked from linked pages (larger response). | |
| projectName | No | Target project name. If not specified, defaults to 'my-cosense-project'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states authentication requirements (COSENSE_SID) and the default project behavior. It also discloses that the tool returns full content and uses AI-optimized formatting. While it does not explicitly state read-only or side effects, the nature of 'get context' is clearly a read operation, and no annotations exist to carry that burden. It adds meaningful behavioral context without contradicting anything.
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 compact and front-loaded: it states the purpose, the return value, the use case, authentication, and a default behavior in four sentences with no filler or redundancy. It is well-structured for quick scanning.
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 tool is relatively complex (returns target page and linked pages with full contents) and has no output schema, but the description covers the key points: what is returned (page + linked pages, hop counts), the format (AI-optimized), the required auth, and the default project. This is sufficient for an agent to call it appropriately.
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% coverage for all three parameters. The description repeats the default projectName behavior and mentions hop counts but adds no additional detail beyond what the schema already provides. Baseline 3 is appropriate since the schema fully documents parameters, though the description could have clarified the return format structure slightly more.
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: 'Get smart context for a page' on cosense. It specifies the resource (page) and the scope (linked pages 1-hop or 2-hop) and distinguishes itself from sibling tools like get_page or search_pages by emphasizing the AI-optimized format and related-knowledge 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?
It indicates this tool is useful for understanding context and related knowledge around a topic, which gives a clear usage context. It does not explicitly state when not to use it or mention alternatives like get_page, but the context is clear enough and no misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert text after a specified line in a Scrapbox page on cosense (scrapbox). If target line not found, text is appended to the end of the page. Uses my-cosense-project project as default if projectName is not specified.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to insert in markdown format (default) or Scrapbox syntax (when format is 'scrapbox'). Can contain multiple lines separated by newline characters. | |
| format | No | Content format of the text. 'markdown' (default) converts Markdown to Scrapbox syntax. 'scrapbox' passes content through as-is, preserving Scrapbox-native indentation and syntax. | |
| pageTitle | Yes | Title of the page to modify | |
| projectName | No | Target project name. If not specified, defaults to 'my-cosense-project'. | |
| targetLineText | Yes | Text content of the line after which to insert new text. If not found, text will be appended to the end of 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. It discloses the append fallback and default project behavior, adding useful context. However, it does not mention what happens if the page does not exist, how duplicate line matches are handled, or any permission/error conditions. This is adequate but not exhaustive.
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, succinct, and front-loaded with the core function. No unnecessary wording or repetition. Every word contributes to understanding the tool.
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 handles the core insert behavior and fallback logic. It does not cover edge cases like missing pages or ambiguous target lines, but given the schema already documents all parameters and there is no output schema, it is reasonably complete for the tool's complexity.
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 description adds minimal value beyond what the schema already states. It repeats the default project and append behavior, which are also in the schema. No additional parameter insights are provided, so baseline 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 (insert text after a specified line) and resource (Scrapbox page on cosense). It distinguishes from siblings like edit_lines and delete_lines by focusing on insertion. The verb is specific and the target is unambiguous.
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 implies when to use the tool: when you need to insert new text after a specific line, with a fallback to appending if not found. It does not explicitly mention alternatives or when not to use it, but the wording provides clear context for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse and list pages from Scrapbox project on cosense (scrapbox) with flexible sorting and pagination. Use this tool to discover pages by recency, popularity, or alphabetically. Returns page metadata and first 5 lines of content. Available sorting methods: updated (last update time), created (creation time), accessed (access time), linked (number of incoming links), views (view count), title (alphabetical). Different from search_pages which finds content by keywords. Uses my-cosense-project project as default if projectName is not specified.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Number of pages to skip | |
| sort | No | Sort method for the page list | |
| limit | No | Maximum number of pages to return (1-1000) | |
| projectName | No | Target project name. If not specified, defaults to 'my-cosense-project'. | |
| excludePinned | No | Whether to exclude pinned pages from the results |
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 does well by describing the return format ('Returns page metadata and first 5 lines of content'), pagination capability (implied through 'skip' parameter), and default project behavior. However, it doesn't mention rate limits, authentication requirements, or error conditions that would be helpful for a read operation.
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 appropriately sized and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds valuable information about usage, return values, sorting options, and sibling differentiation. There's minimal redundancy, though the sorting methods list could be slightly more 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?
For a read-only listing tool with no output schema, the description provides good contextual completeness by explaining what's returned, how to use it versus alternatives, and default behaviors. It covers the essential aspects an agent needs, though additional details about response format structure or error handling would make it more complete.
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 parameters thoroughly. The description adds some value by listing all sorting methods and explaining the default project behavior, but doesn't provide additional semantic context beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is high.
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 with specific verbs ('browse and list pages') and resource ('from Scrapbox project on cosense'), distinguishing it from sibling tools by explicitly contrasting with search_pages. It provides concrete details about what the tool does, including the scope of returned data (page metadata and first 5 lines of content).
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 explicitly states when to use this tool ('to discover pages by recency, popularity, or alphabetically') and when not to use it ('Different from search_pages which finds content by keywords'), providing clear alternatives. It also includes practical guidance about default project behavior, making it easy for an agent to choose between this tool and its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for content within pages in Scrapbox project on cosense (scrapbox). Use this tool to find pages containing specific keywords or phrases. Returns matching pages with highlighted search terms and content snippets. Limited to 100 results maximum. Supports basic search ("keyword"), multiple keywords ("word1 word2" for AND search), exclude words ("word1 -word2"), and exact phrases (""exact phrase""). Different from list_pages which browses pages by metadata. Uses my-cosense-project project as default if projectName is not specified.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| projectName | No | Target project name. If not specified, defaults to 'my-cosense-project'. |
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 and does so effectively. It reveals important behavioral traits: result limitation ('Limited to 100 results maximum'), search syntax capabilities ('Supports basic search...'), and default project behavior. However, it doesn't mention potential error conditions, authentication requirements, or rate limits, which prevents a perfect score.
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 efficiently structured and front-loaded with the core purpose. Every sentence adds value: purpose statement, usage guidance, return format, limitations, search syntax, sibling differentiation, and default behavior. There's no wasted text, and information is presented in a logical flow.
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 search tool with 2 parameters, 100% schema coverage, and no output schema, the description provides substantial context about behavior, limitations, and usage. It explains what the tool returns ('Returns matching pages with highlighted search terms and content snippets') and search capabilities. The main gap is lack of output format details, which would be helpful given no output schema exists.
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?
With 100% schema description coverage, the baseline is 3, but the description adds meaningful context beyond the schema. It explains the default project behavior ('Uses my-cosense-project project as default if projectName is not specified') and provides search syntax examples that help interpret the query parameter. This adds practical value for parameter understanding.
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 with specific verb ('Search for content') and resource ('within pages in Scrapbox project'), and explicitly distinguishes it from sibling tool list_pages ('Different from list_pages which browses pages by metadata'). This provides excellent clarity about what this tool does and how it differs from alternatives.
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 explicit guidance on when to use this tool ('Use this tool to find pages containing specific keywords or phrases') and when to use alternatives ('Different from list_pages which browses pages by metadata'). It also specifies the default project behavior, giving clear context for usage decisions.
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.10.1create_page2 fields changedInput schema / properties / body / descriptionPrevious value: -"Content in markdown format. Avoid duplicating the title in the body since it's automatically displayed at the top. Supports links, code blocks, lists, and emphasis."New value: +"Content in markdown format (default) or Scrapbox syntax (when format is 'scrapbox'). Avoid duplicating the title in the body since it's automatically displayed at the top. Supports links, code blocks, lists, and emphasis."Input schema / properties / formatAdded value: +{
+ "description": "Content format of the body. 'markdown' (default) converts Markdown to Scrapbox syntax. 'scrapbox' passes content through as-is, preserving Scrapbox-native indentation and syntax.",
+ "enum": [
+ "markdown",
+ "scrapbox"
+ ],
+ "type": "string"
+}delete_linesedit_linesget_smart_contextinsert_lines2 fields changedInput schema / properties / formatAdded value: +{
+ "description": "Content format of the text. 'markdown' (default) converts Markdown to Scrapbox syntax. 'scrapbox' passes content through as-is, preserving Scrapbox-native indentation and syntax.",
+ "enum": [
+ "markdown",
+ "scrapbox"
+ ],
+ "type": "string"
+}Input schema / properties / text / descriptionPrevious value: -"Text to insert. Can contain multiple lines separated by newline characters."New value: +"Text to insert in markdown format (default) or Scrapbox syntax (when format is 'scrapbox'). Can contain multiple lines separated by newline characters."v0.4.0create_page1 field changedInput schema / properties / projectName / descriptionPrevious value: -"Target project name. If not specified, defaults to 'example-project'."New value: +"Target project name. If not specified, defaults to 'my-cosense-project'."get_page1 field changedInput schema / properties / projectName / descriptionPrevious value: -"Target project name. If not specified, defaults to 'example-project'."New value: +"Target project name. If not specified, defaults to 'my-cosense-project'."get_page_url1 field changedInput schema / properties / projectName / descriptionPrevious value: -"Target project name. If not specified, defaults to 'example-project'."New value: +"Target project name. If not specified, defaults to 'my-cosense-project'."insert_lines1 field changedInput schema / properties / projectName / descriptionPrevious value: -"Target project name. If not specified, defaults to 'example-project'."New value: +"Target project name. If not specified, defaults to 'my-cosense-project'."list_pages1 field changedInput schema / properties / projectName / descriptionPrevious value: -"Target project name. If not specified, defaults to 'example-project'."New value: +"Target project name. If not specified, defaults to 'my-cosense-project'."search_pages1 field changedInput schema / properties / projectName / descriptionPrevious value: -"Target project name. If not specified, defaults to 'example-project'."New value: +"Target project name. If not specified, defaults to 'my-cosense-project'."create_pageget_pageget_page_urlinsert_lineslist_pagessearch_pagesScored across 9 tools
Each tool has a clearly distinct purpose: search_pages for keyword search, list_pages for metadata browsing, get_page for content retrieval, get_page_url for URL generation, get_smart_context for context expansion, and separate create/edit/insert/delete operations for lines. No two tools overlap in functionality.
All tool names follow a consistent snake_case verb_noun pattern (search_pages, create_page, list_pages, insert_lines, edit_lines, delete_lines). The verbs are intuitive and match the actions, making the set predictable.
With 9 tools, the server is well-scoped for managing Scrapbox pages and lines. Each tool serves a distinct function, and the count is within the ideal 3-15 range, balancing coverage without redundancy.
The set covers create, read, and line-level update/delete, but omits a delete_page tool even though the delete_lines description references it. This missing operation breaks the page lifecycle and forces agents to use unsupported calls, causing failures. Additionally, there is no tool to rename or update page metadata.
OAuth-protected, read-only-by-default MCP server for provenance-labeled QuillCaddie project memory.
Private journal MCP server to search, analyze, and create Dabble Me entries securely via OAuth.
DocBase MCP server for AI agents
Shared project wiki for AI agents: read and write pages, next actions, and activity logs over MCP.
