English | 日本語
水面に波を立てずにウェブを滑る — 日本語ウェブに最適化した、低負荷・トークン効率の高いウェブ収集のためのMCPサーバーです。アウトライン→セクションの段階的開示と差分のみの再取得により、コンテキストを小さく保ちます。
amenbo(アメンボ / 水すまし)は、Claude Code や Codex のようなコーディングエージェント向けの MCP サーバーです。水面に波を立てずに滑る虫のように、収集先に負荷をかけず、少ないトークンで Web から情報を集めます。とりわけ日本語サイトに最適化しています。MCP クライアントを持たないシェル環境からは、同じコアを共有する CLI としても使えます(CLIとして使う参照)。
汎用のスクレイピングツールの多くは英語圏の Web を前提に作られており、日本語サイトでは次のような取りこぼしが起きがちです。amenbo はこれらの課題に対応します。
構造化が甘いサイト：div の入れ子やテーブルレイアウトが多い日本語サイトでも、レンダリング結果のジオメトリ(見た目の配置)から本文領域を推定します
文字化け：Shift_JIS / EUC-JP / ISO-2022-JP を自動判別
ふりがな：<ruby> の振り仮名を除去し、本文の二重化を防止
画像で出す情報：画像化された料金表やバナー中心のページは、テキスト抽出が貧弱なとき自動でスクリーンショットに切り替え
表の欠落・崩れ：リンク密度の高いデータ表(比較表など)は本文抽出時に丸ごと落ちることがあり、そうした表を検出して元の位置へ復元します。本文に残った表も colspan/rowspan・多段ヘッダを正規化し、列ズレを防ぎます
見出しの消失：見出しが編集リンク付きラッパーに包まれたページ(Wiki系など)では本文抽出時に見出し構造が丸ごと失われることがあり、本文が残っている節の見出しを検出して元の位置へ復元します(outline / section の段階開示が安定)
国内主要サイト：Qiita / Zenn / note / はてなブログ / Yahoo!ニュース / PR TIMES に専用アダプタ
類似ツール(公式 fetch MCP / Jina Reader / Playwright MCP / PixelRAG pixelshot)との実測比較は、記事「エージェントのWeb取得、ツール次第でトークンが5000倍違った話」を参照してください。ハーネスと生ログは bench/ にあります。
Related MCP server: Charlotte
段階開示：mode: outline で見出しツリーと各節のトークン量だけ先に返し、必要な節だけ section 指定で取得。長大なページを丸ごと流し込みません
CJK 対応の本文プルーニング：句読点密度、文字種比率、リンク密度でナビ/広告/フッターを除去
差分応答：一度取得した URL の再取得時、変更が無ければ unchanged、あれば変更された節だけを返します
自動 Markdown/画像切替：品質スコアが低いページだけスクリーンショットにし、壊れた Markdown を読ませて取り直す往復を避けます
文字種別のトークン見積り：日本語・韓国語・キリル文字・絵文字などは英語よりトークン単価が重いため、文字クラス別の係数(実測で校正)でページ分割の予算を計算します
二段フェッチ：まず素の HTTP GET。JS 描画が必要なページだけ headless Chromium に昇格するので、大半の取得でブラウザを起動しません
礼儀正しいクローラ：robots.txt と Crawl-Delay を尊重、同一ドメインへは直列 + 既定 1 req/秒（robots.txt の取得もこの1リクエストとして数えます）。リンク列挙は sitemap / RSS を優先しページを舐めません
正直な User-Agent：ボットであることを明示します。anti-bot 回避は実装しません
キャッシュ：ETag / If-Modified-Since で再検証し、無駄な再取得を避けます。有効期限は既定 15 分（AMENBO_CACHE_TTL_MS）で、Cache-Control は延長方向のみ採用します（max-age が 15 分より長ければそちらを使い、上限 24 時間。no-store は保存しません）。max-age=0 や no-cache で期限を縮めることはしません — 主要サイトの実測ではその宣言が大半で、従うとツール呼び出しの度に取得しに行くことになり、低負荷という前提が崩れるためです。
npm install -g amenboMarkdown 取得(通常の fetch / links)はこれだけで動きます。JS 描画が必要な SPA への昇格やスクリーンショットなど、ブラウザ(Chromium)経由の取得を使う場合のみ、初回に一度だけ実行してください(約 170MB のダウンロード):
npx -y amenbo install-browserまたは開発用途:
git clone https://github.com/Rererr/amenbo.git
cd amenbo
npm install
npm run buildClaude Code(--scope user は全プロジェクト共通。プロジェクト単位なら外す):
claude mcp add --scope user amenbo -- amenboCodex CLI:
codex mcp add amenbo -- amenboVS Code:
code --add-mcp '{"name":"amenbo","command":"amenbo"}'その他のクライアント(Cursor / Cline など)は、各クライアントの MCP 設定(Cursor: ~/.cursor/mcp.json、Cline: MCP Servers 画面の settings JSON)に次のエントリを追加します:
{
"mcpServers": {
"amenbo": {
"command": "amenbo"
}
}
}グローバルインストールを避ける場合は "command": "npx", "args": ["-y", "amenbo"]、ローカルビルドを使う場合は "command": "node", "args": ["/path/to/amenbo/dist/server.js"] を指定してください。
stdio 経由で MCP の 2026-07-28(ステートレスコア)と 2025 系の両方に応答します。クライアントがどちらの版を話すかに関わらず、上記の設定のまま繋がります。
ツール定義だけでは「段階開示で取る」といった使い方の作法までは伝わりません。以下を CLAUDE.md や AGENTS.md にコピペすると、エージェントが amenbo を効率よく使うようになります。
## Web取得は amenbo を使う
- ページ取得は `fetch`(mode 既定 `auto`)。長そうなページや一部しか要らないページは、
まず `mode: "outline"` で見出しと各節のトークン量を確認し、必要な節だけ `section` 指定で取得する
- 同じ URL の再取得で `unchanged` / `diff` が返るのは正常(変更なし / 変更節のみ)。
差分ではなく内容全体をもう一度受け取りたいときだけ `force_full: true` を使う
- サイト内のページを探すときは URL を推測せず `links`(`filter` で絞り込み)で列挙する
- シェルが使える環境で、キーワードで探したいだけの長いページや複数ページの一括収集は、
CLI で `amenbo fetch <url> > page.md` に落として grep / 部分読みする(本文をコンテキストに入れない)。
構造を見ながら判断したいページは従来どおり MCP の outline → section が向く
- 日本語以外のサイトにも使える(段階開示・キャッシュ・低負荷は言語非依存)。ただし本文抽出は
日本語向けに調整しているため、非日本語ページで本文が欠けて見えるときは `selector` 指定か
`mode: "screenshot"` で取り直す
- 料金表・レイアウトなど視覚情報が目的なら `screenshot`。`scale: 0.5` 程度で画像トークンを減らせる
- robots.txt 拒否や bot 対策による取得失敗は仕様(回避しない)。失敗はそのままユーザーに報告するCLAUDE.md に書かず、その場のセッションだけに読み込むこともできます。MCP プロンプト対応クライアントでは、サーバーが同じ作法を usage プロンプトとして配布しています(Claude Code では /mcp__amenbo__usage)。
amenbo は MCP サーバーと同一のコア(取得、キャッシュ、ポライトネス、抽出ロジック)を共有する CLI としても動作します。引数なし、または amenbo serve は従来通り MCP サーバーとして起動する(.mcp.json の "command": "amenbo" はそのまま動きます)ので、既存の MCP 登録には影響しません。
# ページをMarkdownとして取得(標準出力へ)
amenbo fetch https://example.com/
# 長いページはまずoutlineで見出しとトークン量だけ確認
amenbo fetch https://example.com/ --mode outline
# 出力をファイルに落として grep や部分読み(head/sed)する
amenbo fetch https://example.com/ > page.md
grep -A3 "料金" page.md
# サイト内のリンクを列挙(sitemap/RSS優先)
amenbo links https://example.com/ --filter "blog/*"
# スクリーンショット(タイルPNGは--out-dirへ保存され、パスが標準出力に列挙される)
amenbo screenshot https://example.com/ --viewport-only --scale 0.5 --out-dir ./shots各サブコマンドの詳細は amenbo <fetch|links|screenshot> --help を参照してください。
MCP と CLI の使い分け:
MCP：エージェントの主経路。ブラウザ(Chromium)がプロセス内でウォームに保たれ、スクリーンショット等の画像を会話へ直接返せる。claude.ai のようにシェルを持たないホストのエージェントにも届く
CLI：シェルスクリプト、CI、デバッグ用途、出力をファイルに落として grep/部分読みしたい場合、または MCP 非対応のエージェント/ツールチェーンから使う場合に向く。1 コマンド= 1 プロセスのためブラウザは毎回起動する
キャッシュ、差分応答(unchanged/diff)、レート制御(robots.txt/ドメイン毎の直列アクセス)の状態は MCP サーバーと CLI で共有されます(同じ ~/.cache/amenbo を使うため)。ただしレート制御のプロセス間共有はベストエフォートです。同一ドメインへの直列化は各プロセス内でのみ厳密に保証され、MCP サーバーと複数の CLI 実行が同時に同じドメインへアクセスした場合、最小間隔が多少すり抜けることがあります。
fetch でページを取得パラメータ | 説明 |
| 取得対象 URL(http/https のみ。PDF 可) |
|
|
| 本文を絞り込む CSS セレクタ |
| outline で得た section ID。その節の Markdown のみ返す(祖先見出しがあれば応答に |
| ページ番号(既定 1) |
| 1 ページの概算トークン上限(既定 8000) |
| true で差分応答・定型ブロック除去を無効化する( |
links でリンクを列挙パラメータ | 説明 |
| 起点 URL |
| URL/リンクテキストの部分一致、または |
sitemap → RSS/Atom → ページ内リンクの順で探索します。
screenshot でスクリーンショットを撮影パラメータ | 説明 |
| 撮影対象 URL(http/https のみ) |
| 既定 true。false で最初のビューポート分のみ |
| タイル幅 px(既定 1280) |
| 解像度スケール 0.5〜1.0(既定 1.0)。小さいほど画像トークン減 |
変数 | 既定 | 説明 |
|
| キャッシュ(SQLite + PNG)の保存先 |
|
| キャッシュの有効期限 |
|
| 取得ボディの上限サイズ |
SSRF 対策：http/https 以外のスキーム(file:, ftp: 等)を拒否。DNS 解決した接続先が private / loopback / link-local / 予約アドレスなら拒否。DNS rebinding(TOCTOU)対策として実接続を検証済み IP に固定します。
ボディサイズ上限：巨大レスポンスによる OOM を防止
本文抽出は日本語チューニング：段階開示・キャッシュ・低負荷は言語非依存で、非日本語サイトでも動きます。ただし本文抽出のヒューリスティックは日本語ページで調整しているため、非日本語ページで本文が欠けて見えるときは selector 指定か mode: "screenshot" で取り直してください。
HTTP プロキシ非対応：HTTP_PROXY / HTTPS_PROXY 等の環境変数は尊重しません。SSRF 対策として接続先を検証済み IP に固定する設計(DNS rebinding 対策)と、プロキシへ名前解決を委ねる方式が両立しないためです。上流プロキシ必須のネットワークでは現状ご利用いただけません。
anti-bot 回避は実装しません：robots.txt 拒否やボット対策による取得失敗は仕様です。失敗はそのまま報告します(収集先への低負荷参照)。
clone 後に1回、秘密情報検査（gitleaks）の pre-commit フックを有効化する:
git config core.hooksPath githooksnpm run typecheck # strict 型チェック
npm test # vitest
npm run build # dist/ へビルド記事や研究で参照する場合は Zenodo の DOI を使ってください。上のバッジの 10.5281/zenodo.21553636 は全バージョン共通の Concept DOI で、常に最新版へ解決されます。特定の版を指す場合は、その版の DOI を Zenodo のレコードから取得してください。
機械可読な引用情報は CITATION.cff にあります(GitHub の "Cite this repository" から BibTeX / APA を生成できます)。
Fetch a web page (Japanese-web-native) as low-impact, token-efficient Markdown. Built-in robots.txt compliance, rate limiting, and caching. mode: auto (default; quality score picks Markdown or screenshot) / markdown / outline (heading summary) / screenshot. Refetching a cached URL returns cache: unchanged, or diff (changed sections only), to save tokens. PDF URLs are handled automatically. mode: screenshot is the retry for pages whose Markdown came back poor; when the layout itself is the information or you need viewport/scale control, use the screenshot tool instead.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL (http/https only; PDF supported) | |
| mode | No | Default: auto | |
| page | No | Page number (default 1) | |
| section | No | Section ID obtained from outline mode; returns only that section's Markdown | |
| selector | No | CSS selector to narrow the content | |
| force_full | No | Default false. If true, disables diff responses (unchanged/diff) and boilerplate-block removal (pagination by max_tokens still applies) | |
| max_tokens | No | Approximate token budget per page (default 8000) | |
| ask_robots_override | No | Set true only when the user explicitly asked to fetch this page even though robots.txt denies it. amenbo then asks the user to confirm in the client UI and fetches only if they approve; this flag alone never bypasses robots.txt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/openWorldHint the description discloses robots.txt compliance, rate limiting, caching with `unchanged`/`diff` responses, automatic PDF handling, and the important nuance that `ask_robots_override` merely triggers a user confirmation rather than bypassing robots.txt. These are exactly the behaviors an agent cannot infer from 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?
Front-loaded with purpose then behavior then routing, so the most decision-relevant content comes first. Slightly dense — the `mode` values are enumerated mid-paragraph and then revisited at the end for the screenshot retry case — but no sentence is filler.
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 an 8-parameter, no-output-schema tool, the description covers the mutation-free safety profile, return shapes (Markdown, outline, screenshot, unchanged/diff), token budgeting via max_tokens pagination, and the consent flow for robots-denied pages. Nothing an agent needs before calling it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description earns above that by explaining what the `mode` enum values actually do (auto quality scoring, outline as heading summary) and by tying `section` implicitly to outline output and `force_full` to diff suppression. Remaining parameters (page, selector, max_tokens) are left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Fetch a web page') plus the transformation applied ('as ... Markdown'), and explicitly names the sibling it is not: partial-layout work belongs to the `screenshot` tool. An agent can distinguish fetch from screenshot and links without opening any schema.
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?
Gives explicit routing rules: default to `auto`, drop to `screenshot` mode as the retry when Markdown quality is poor, and switch to the separate `screenshot` tool when the layout itself is the information or viewport/scale control is needed. It also explains the refetch path (cached URL returns `unchanged` or `diff`), which is when-not-to-expect-fresh-content guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate URLs under a site or page without fetching each one. Tries sitemap.xml, then RSS/Atom feeds, then falls back to links found in the page itself; the response header reports which source was used (source:), the count:, and (truncated) when more than 200 links were cut. Each link is one line, - <title> — <url> (title omitted when unknown). filter narrows by substring or * glob against URL and link text; an empty result states whether the filter removed everything or the source had no links. Use it to find the right page before fetch. It does not return page content and does not follow more than the first 3 child sitemaps.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Starting URL | |
| filter | No | Substring match against URL/link text, or a glob using * |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses network behavior: it tries sitemap.xml, RSS/Atom feeds, then page links; it limits child sitemaps to 3; it reports source, count, and truncation in the response; and it explicitly does not return page content. This adds substantial behavioral context beyond the 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 dense but every sentence adds value: the core purpose, the fallback chain, the output format, the filter behavior, the usage guidance, and the limitations. It is well-organized and front-loaded with the primary function, making it efficient for an agent to parse.
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 there is no output schema, the description fully specifies the output format ('- <title> — <url>'), edge cases (truncated at 200, empty filter results), and restrictions (no page content, max 3 child sitemaps). This makes the tool's behavior predictable and complete for 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?
Both parameters are fully described. `url` is defined as 'Starting URL' with a URI format. `filter` is detailed as 'Substring match against URL/link text, or a glob using *', which precisely explains its matching behavior. The schema description coverage is 100% and the descriptions add meaningful semantics.
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 function: 'Enumerate URLs under a site or page without fetching each one.' It differentiates from siblings by targeting link discovery, with explicit guidance 'Use it to find the right page before fetch', which aligns with the presence of `fetch` as a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (before fetching) and when not to (it does not return page content), plus details the fallback chain (sitemap, RSS/Atom, page links). This is sufficient guidance relative to the sibling tools `screenshot` and `fetch`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a page in a headless browser and return it as up to 10 tiled PNG images (1280px wide by default; fullPage: false returns only the first viewport). Pages taller than 10 tiles are cut off and the response says truncated: true. Use it when the layout or an image is the information (pricing tables, banners, visual QA) or when you need explicit viewport/scale control; scale: 0.5 roughly halves image tokens. For text content use fetch. Built-in robots.txt compliance, rate limiting, and caching.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL (http/https only) | |
| scale | No | Resolution scale (0.5-1.0, default 1.0); lower reduces image tokens | |
| width | No | Tile width in px (default 1280) | |
| fullPage | No | Default true. If false, captures only the first viewport (1 tile) | |
| ask_robots_override | No | Set true only when the user explicitly asked to fetch this page even though robots.txt denies it. amenbo then asks the user to confirm in the client UI and fetches only if they approve; this flag alone never bypasses robots.txt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the hard 10-tile cap, the `truncated: true` signal, the `fullPage` default, the token cost tradeoff of `scale: 0.5`, and the built-in robots.txt compliance, rate limiting, and caching. These are exactly the operational constraints an agent needs before committing to a render.
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?
Front-loads what the tool returns before the usage conditions and alternatives; parenthetical examples replace whole sentences. No sentence is filler and nothing is buried.
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 no output schema, the description still characterizes the response shape (tuples of tiles, truncation flag). Behavior, limits, alternatives, and cost controls are all present for a five-parameter open-world tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds practical meaning: `fullPage: false` is framed as "only the first viewport," and `scale: 0.5` is quantified as roughly halving image tokens. It stops short of explaining how `width` interacts with the 10-tile cutoff, which is the one genuinely non-obvious parameter relationship.
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?
States a specific verb and resource (render a page in a headless browser) plus the exact output form (up to 10 tiled PNGs, 1280px wide default). The explicit handoff to `fetch` for text content separates it from the closest sibling without opening either schema.
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?
Names the selection conditions directly: use when layout or an image is the information (pricing tables, banners, visual QA) or when explicit viewport/scale control is needed, and use `fetch` instead for text. This is explicit when-to-use plus a named alternative.
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.7.0fetch1 field changedInput schema / properties / ask_robots_overrideAdded value: +{
+ "description": "Set true only when the user explicitly asked to fetch this page even though robots.txt denies it. amenbo then asks the user to confirm in the client UI and fetches only if they approve; this flag alone never bypasses robots.txt",
+ "type": "boolean"
+}screenshot1 field changedInput schema / properties / ask_robots_overrideAdded value: +{
+ "description": "Set true only when the user explicitly asked to fetch this page even though robots.txt denies it. amenbo then asks the user to confirm in the client UI and fetches only if they approve; this flag alone never bypasses robots.txt",
+ "type": "boolean"
+}v0.6.0fetch2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / force_full / descriptionPrevious value: -"Default false. If true, disables diff responses (unchanged/diff) and boilerplate-block removal, always returning the full content"New value: +"Default false. If true, disables diff responses (unchanged/diff) and boilerplate-block removal (pagination by max_tokens still applies)"links1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"screenshot1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"v0.1.5fetch7 fields changedInput schema / properties / force_full / descriptionPrevious value: -"既定false。trueで差分応答(unchanged/diff)と定型ブロック除去を無効化し常に全文を返す"New value: +"Default false. If true, disables diff responses (unchanged/diff) and boilerplate-block removal, always returning the full content"Input schema / properties / max_tokens / descriptionPrevious value: -"1ページの概算トークン上限(既定8000)"New value: +"Approximate token budget per page (default 8000)"Input schema / properties / mode / descriptionPrevious value: -"既定auto"New value: +"Default: auto"Input schema / properties / page / descriptionPrevious value: -"ページ番号(既定1)"New value: +"Page number (default 1)"Input schema / properties / section / descriptionPrevious value: -"outlineで得たsection ID。指定時はその節のMarkdownのみ返す"New value: +"Section ID obtained from outline mode; returns only that section's Markdown"Input schema / properties / selector / descriptionPrevious value: -"本文を絞り込むCSSセレクタ"New value: +"CSS selector to narrow the content"Input schema / properties / url / descriptionPrevious value: -"取得対象URL(http/httpsのみ。PDFも可)"New value: +"Target URL (http/https only; PDF supported)"links2 fields changedInput schema / properties / filter / descriptionPrevious value: -"URL/リンクテキストの部分一致、または*を使ったglob"New value: +"Substring match against URL/link text, or a glob using *"Input schema / properties / url / descriptionPrevious value: -"起点URL"New value: +"Starting URL"screenshot4 fields changedInput schema / properties / fullPage / descriptionPrevious value: -"既定true。falseの場合は最初のビューポート分(1タイル)のみ撮影する"New value: +"Default true. If false, captures only the first viewport (1 tile)"Input schema / properties / scale / descriptionPrevious value: -"解像度スケール(0.5〜1.0、既定1.0)。小さいほど画像サイズ(トークン)が減る"New value: +"Resolution scale (0.5-1.0, default 1.0); lower reduces image tokens"Input schema / properties / url / descriptionPrevious value: -"撮影対象のURL(http/httpsのみ)"New value: +"Target URL (http/https only)"Input schema / properties / width / descriptionPrevious value: -"タイル幅(px)。既定1280"New value: +"Tile width in px (default 1280)"fetchlinksscreenshotScored across 3 tools
fetch, screenshot, and links have largely distinct purposes, and the descriptions explicitly cross-reference each other to steer selection (text vs. layout vs. URL discovery). The remaining ambiguity is that fetch embeds a `mode: screenshot` that partially duplicates the standalone screenshot tool, requiring the agent to read the guidance to pick correctly.
All three names are short, lowercase, single-token identifiers with no style mixing, which is easy to scan and predict. However, they are not a verb_noun pattern and mix grammatical forms (verb 'fetch' vs. nouns 'screenshot'/'links'), so the convention is consistent in form but not in structure.
Three tools is lean for the stated scope, but this server targets a narrow purpose (token-efficient web retrieval) and each tool covers a genuinely different need: content, rendering, and link discovery. Nothing feels padded or missing at the tool level.
The surface covers the main retrieval lifecycle: discover URLs (links), get text (fetch), and get visual layout (screenshot), including caching/diff and PDF handling. Gaps are minor and acknowledged (links follows only 3 child sitemaps, no crawling or structured extraction), and agents can chain the tools to work around them.
Hosted Web Crawler MCP server for Claude, ChatGPT and Cursor, with each action switched per account.
Web search API and MCP server for developers building AI agents.
One MCP server for all web data. Scrape, search, crawl, and AI research in one install.
Turn any public website into an MCP server for agents to search, read and navigate.
