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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint, openWorldHint) are consistent with the description, which adds substantial behavioral context: built-in robots.txt compliance, rate limiting, caching behavior, diff responses, boilerplate-block removal, and pagination by max_tokens. The description enriches the annotations without contradiction.
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 structured and largely efficient, but it contains some redundancy—particularly the repeated mention of screenshot mode and the slightly rambling final sentence. Overall, each sentence contributes useful information, though a tighter edit would improve flow without losing content.
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 provides thorough coverage of modes, caching, diffs, PDF handling, and pagination. It lacks an explicit output-schema description, but since no output schema is provided, the description's mention of return behaviors (unchanged, diff, section Markdown) offers sufficient context for the agent to use the tool correctly.
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?
All seven parameters are described meaningfully. The schema covers 100% of parameters, and the descriptions add operational detail: 'section' references outline mode, 'force_full' disables diff and boilerplate removal, 'max_tokens' sets a per-page budget, and 'mode' is clarified with defaults and use cases.
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: fetching web pages as low-impact, token-efficient Markdown. It explicitly differentiates from the sibling screenshot tool by indicating when to use screenshot instead (layout-as-information or viewport/scale control), leaving no ambiguity about the tool's core function.
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 mode selection (auto, markdown, outline, screenshot) and explains the rationale for using the screenshot tool as a fallback when Markdown is poor. It also clarifies treatment of cached URLs (unchanged vs. diff) and boilerplate removal, giving the agent clear decision criteria.
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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses significant behavioral traits: tiling up to 10 tiles, truncation with a 'truncated: true' flag, default width 1280, fullPage false behavior, built-in robots.txt compliance, rate limiting, and caching. It also notes the token impact of scale. No contradictions with 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 and front-loaded, starting with the core action and output, then behavioral details, usage guidance, and alternative. Every sentence adds necessary information without redundancy or 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?
Given there is no output schema, the description explains the return as 'up to 10 tiled PNG images' and mentions the 'truncated: true' response field. It covers the main behaviors and usage, though it doesn't specify the exact output structure (e.g., array of image URLs vs base64) or error handling. For a moderately complex tool with 4 parameters, this is fairly 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?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the effect of scale on image tokens ('scale: 0.5 roughly halves image tokens'), the default width, and the fullPage behavior (only first viewport when false). It also clarifies the tiling and truncation mechanics, exceeding the schema 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 renders a page in a headless browser and returns tiled PNG images, with specific parameters like tile width and fullPage behavior. It differentiates from the sibling tool fetch by explicitly stating 'For text content use fetch', making its purpose distinct.
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 when-to-use guidance: 'Use it when the layout or an image is the information (pricing tables, banners, visual QA) or when you need explicit viewport/scale control.' It also gives the alternative: 'For text content use fetch.' This is clear and actionable.
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. Dates show when Glama detected each change.
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)"fetchlinksscreenshotThe three tools have clearly distinct primary purposes: fetch returns Markdown, screenshot returns images, and links enumerates URLs. The only slight overlap is fetch's 'screenshot' mode, but the descriptions explicitly direct users to the screenshot tool when layout is the priority, so confusion is minimal.
All tool names are single lowercase words following a consistent style: fetch, screenshot, links. While not verb_noun, the naming is predictable and uniform across the entire set.
Three tools is well-scoped for a web retrieval server. Each tool covers a distinct retrieval mode without redundancy, and the count feels neither thin nor bloated.
The server covers the full lifecycle of web content retrieval: discovering URLs (links), fetching text content (fetch), and capturing visual layout (screenshot). PDF handling and caching are built in, leaving no obvious gaps for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Reliable web access for AI agents: smart HTTP, rotating proxies, and full-browser rendering.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rererr/amenbo'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
