amenbo
amenbo 🐜💧
English | 日本語
Gleitet über das Web, ohne Wellen zu schlagen — ein auf japanische Websites spezialisierter MCP-Server für ressourcenschonende, token-effiziente Websammlung: schrittweise Offenlegung von Gliederung→Abschnitt und Nur-Diff-Neuabrufe halten den Kontext klein.
amenbo (アメンボ / Wasserläufer) ist ein MCP-Server für Coding-Agenten wie Claude Code oder Codex. Wie ein Insekt, das über die Wasseroberfläche gleitet, ohne Wellen zu schlagen, sammelt es Informationen aus dem Web ohne die Zielseiten zu belasten und mit wenigen Tokens. Es ist insbesondere für japanische Websites optimiert. Aus einer Shell-Umgebung ohne MCP-Client kann es auch als CLI verwendet werden, die denselben Kern nutzt (siehe Als CLI verwenden).
Warum amenbo?
Viele allgemeine Scraping-Tools sind für das englischsprachige Web konzipiert und lassen bei japanischen Websites oft etwas liegen. amenbo begegnet diesen Herausforderungen:
Schwach strukturierte Websites: Auch bei japanischen Websites mit vielen verschachtelten Divs oder Tabellen-Layouts wird der Haupttextbereich anhand der Geometrie (visuellen Anordnung) des gerenderten Ergebnisses geschätzt.
Zeichensatzprobleme: Automatische Erkennung von Shift_JIS / EUC-JP / ISO-2022-JP.
Furigana: Entfernt die Lesung von
<ruby>und verhindert so eine Doppelung des Texts.Als Bild dargestellte Informationen: Bei Seiten mit bildbasierten Preistabellen oder bannerlastigen Seiten wird bei schwacher Textextraktion automatisch auf Screenshots umgeschaltet.
Fehlende oder zerbrochene Tabellen: Datentabellen mit hoher Linkdichte (z. B. Vergleichstabellen) können bei der Textextraktion komplett verloren gehen; solche Tabellen werden erkannt und an ihrer ursprünglichen Position wiederhergestellt. Auch im Haupttext verbliebene Tabellen werden mit colspan/rowspan und mehrstufigen Kopfzeilen normalisiert, um Spaltenverschiebungen zu vermeiden.
Verschwindende Überschriften: Bei Seiten, deren Überschriften in Wrapper mit Bearbeitungslinks eingebettet sind (z. B. Wiki-Systeme), kann die Überschriftenstruktur bei der Textextraktion vollständig verloren gehen; Überschriften von Abschnitten mit verbleibendem Text werden erkannt und an ihrer ursprünglichen Position wiederhergestellt (stabile schrittweise Offenlegung von Gliederung/Abschnitt).
Wichtige japanische Websites: Spezielle Adapter für Qiita / Zenn / note / Hatena Blog / Yahoo! News / PR TIMES.
Einen praktischen Vergleich mit ähnlichen Tools (offizieller Fetch-MCP / Jina Reader / Playwright MCP / PixelRAG pixelshot) finden Sie im Artikel „Wie die Webabfrage eines Agenten je nach Tool bis zu 5000-mal mehr Tokens verbrauchte“. Testumgebung und Rohprotokolle finden Sie unter bench/.
Related MCP server: Charlotte
Mechanismen zur Token-Ersparnis
Schrittweise Offenlegung: Mit
mode: outlinewerden zuerst nur der Überschriftenbaum und die Token-Anzahl jedes Abschnitts zurückgegeben; nur die benötigten Abschnitte werden persectionabgerufen. So werden keine langen Seiten vollständig übertragen.CJK-fähiges Text-Pruning: Entfernt Navigation, Werbung und Fußzeilen anhand von Satzzeichen-Dichte, Zeichentyp-Verhältnis und Link-Dichte.
Differenzantwort: Bei erneutem Abruf einer bereits abgerufenen URL wird bei keiner Änderung
unchangedzurückgegeben, bei Änderungen nur die geänderten Abschnitte.Automatischer Wechsel zwischen Markdown und Bild: Nur Seiten mit niedrigem Qualitäts-Score werden als Screenshot erfasst, um den Umweg über defektes Markdown und erneutes Abrufen zu vermeiden.
Token-Schätzung nach Zeichentyp: Da Japanisch, Koreanisch, Kyrillisch und Emojis pro Zeichen mehr Tokens kosten als Englisch, wird das Seitenaufteilungsbudget anhand von Faktoren pro Zeichenklasse (empirisch kalibriert) berechnet.
Geringe Belastung der Zielseiten
Zweistufiger Abruf: Zuerst ein einfacher HTTP-GET. Nur Seiten, die JavaScript-Rendering benötigen, werden auf headless Chromium hochgestuft, sodass bei den meisten Abrufen kein Browser gestartet wird.
Höflicher Crawler: Respektiert robots.txt und Crawl-Delay, serielle Zugriffe auf dieselbe Domain mit standardmäßig 1 Anfrage/Sekunde (der Abruf von robots.txt zählt als eine Anfrage). Die Link-Enumeration bevorzugt Sitemap/RSS und durchsucht keine Seiten.
Ehrlicher User-Agent: Gibt an, dass es sich um einen Bot handelt. Anti-Bot-Umgehung ist nicht implementiert.
Cache: Überprüft mit ETag / If-Modified-Since und vermeidet unnötige Neuabrufe. Die Gültigkeitsdauer beträgt standardmäßig 15 Minuten (
AMENBO_CACHE_TTL_MS), wobeiCache-Controlnur in verlängernder Richtung übernommen wird (wennmax-agelänger als 15 Minuten ist, wird dieser Wert verwendet, mit einem Maximum von 24 Stunden.no-storewird nicht gespeichert).max-age=0oderno-cacheverkürzen die Frist nicht – da die meisten großen Websites diese Angaben machen, würde ein Befolgen dazu führen, dass bei jedem Tool-Aufruf neu abgerufen wird, was die Prämisse der geringen Belastung zerstören würde.
Installation
npm install -g amenboFür den Markdown-Abruf (normales fetch / links) reicht dies aus. Nur wenn Sie den Aufstieg auf JS-gerenderte SPAs oder Screenshots über den Browser (Chromium) nutzen möchten, führen Sie einmalig Folgendes aus (ca. 170 MB Download):
npx -y amenbo install-browserOder für Entwicklungszwecke:
git clone https://github.com/Rererr/amenbo.git
cd amenbo
npm install
npm run buildRegistrierung beim MCP-Client
Claude Code (--scope user gilt für alle Projekte; für projektspezifisch ohne):
claude mcp add --scope user amenbo -- amenboCodex CLI:
codex mcp add amenbo -- amenboVS Code:
code --add-mcp '{"name":"amenbo","command":"amenbo"}'Für andere Clients (Cursor / Cline usw.) fügen Sie den folgenden Eintrag in die MCP-Konfiguration des jeweiligen Clients ein (Cursor: ~/.cursor/mcp.json, Cline: settings JSON im MCP-Servers-Bildschirm):
{
"mcpServers": {
"amenbo": {
"command": "amenbo"
}
}
}Um eine globale Installation zu vermeiden, verwenden Sie "command": "npx", "args": ["-y", "amenbo"]; für einen lokalen Build verwenden Sie "command": "node", "args": ["/path/to/amenbo/dist/server.js"].
Über stdio antwortet es sowohl auf MCP 2026-07-28 (zustandsloser Kern) als auch auf die 2025er-Versionen. Unabhängig davon, welche Version der Client spricht, funktioniert die obige Konfiguration.
Dem Agenten die Nutzung beibringen (empfohlener Prompt)
Die Tool-Definition allein vermittelt nicht die Vorgehensweise wie „schrittweise abrufen“. Wenn Sie Folgendes in CLAUDE.md oder AGENTS.md einfügen, nutzt der Agent amenbo effizient.
## 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 対策による取得失敗は仕様(回避しない)。失敗はそのままユーザーに報告するSie können es auch nicht in CLAUDE.md schreiben, sondern nur für die aktuelle Sitzung laden. Bei Clients mit MCP-Prompt-Unterstützung verteilt der Server dieselbe Vorgehensweise als usage-Prompt (bei Claude Code: /mcp__amenbo__usage).
Als CLI verwenden
amenbo funktioniert auch als CLI, die denselben Kern wie der MCP-Server (Abruf, Cache, Höflichkeit, Extraktionslogik) teilt. Ohne Argumente oder mit amenbo serve startet es wie bisher als MCP-Server (die "command": "amenbo"-Einstellung in .mcp.json funktioniert weiterhin), sodass bestehende MCP-Registrierungen nicht beeinträchtigt werden.
# ページを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 ./shotsDetails zu den Unterbefehlen finden Sie unter amenbo <fetch|links|screenshot> --help.
Unterscheidung zwischen MCP und CLI:
MCP: Hauptweg für Agenten. Der Browser (Chromium) bleibt im Prozess warm und kann Bilder wie Screenshots direkt in die Konversation zurückgeben. Funktioniert auch für Agenten auf Hosts ohne Shell, wie z. B. claude.ai.
CLI: Geeignet für Shell-Skripte, CI, Debugging, wenn Sie die Ausgabe in eine Datei schreiben und mit
grep/teilweise lesen möchten, oder für Agenten/Toolchains ohne MCP-Unterstützung. Da ein Befehl = ein Prozess ist, wird der Browser bei jedem Aufruf gestartet.
Cache, Differenzantwort (unchanged/diff) und Ratenbegrenzung (robots.txt/serielle Zugriffe pro Domain) werden zwischen MCP-Server und CLI geteilt (da beide denselben ~/.cache/amenbo verwenden). Die prozessübergreifende Weitergabe der Ratenbegrenzung ist jedoch nur best effort. Die Serialisierung auf dieselbe Domain ist nur innerhalb jedes Prozesses strikt gewährleistet; wenn MCP-Server und mehrere CLI-Ausführungen gleichzeitig auf dieselbe Domain zugreifen, kann das Mindestintervall leicht unterschritten werden.
Werkzeuge
fetch zum Abrufen von Seiten
Parameter | Beschreibung |
| Ziel-URL (nur http/https, PDF möglich) |
|
|
| CSS-Selektor zum Eingrenzen des Haupttexts |
| Abschnitts-ID aus der Gliederung. Gibt nur das Markdown dieses Abschnitts zurück (bei vorhandenen Vorfahren-Überschriften wird |
| Seitennummer (Standard 1) |
| Ungefähres Token-Limit pro Seite (Standard 8000) |
| Bei |
links zum Auflisten von Links
Parameter | Beschreibung |
| Start-URL |
| Teilstring-Übereinstimmung von URL/Linktext oder Glob mit |
Durchsucht in der Reihenfolge Sitemap → RSS/Atom → Links auf der Seite.
screenshot zum Aufnehmen von Screenshots
Parameter | Beschreibung |
| Ziel-URL (nur http/https) |
| Standard |
| Kachelbreite in px (Standard 1280) |
| Auflösungsskalierung 0,5–1,0 (Standard 1,0). Je kleiner, desto weniger Bild-Tokens |
Umgebungsvariablen
Variable | Standard | Beschreibung |
|
| Speicherort für Cache (SQLite + PNG) |
|
| Gültigkeitsdauer des Caches |
|
| Maximale Größe des abgerufenen Bodys |
Sicherheit
SSRF-Schutz: Lehnt andere Schemata als http/https ab (z. B.
file:,ftp:). Lehnt Verbindungen ab, deren DNS-Auflösung auf private / Loopback / Link-Local / reservierte Adressen führt. Gegen DNS-Rebinding (TOCTOU) wird die tatsächliche Verbindung auf die verifizierte IP festgelegt.Body-Größenlimit: Verhindert OOM durch riesige Antworten.
Bekannte Einschränkungen
Textextraktion ist auf Japanisch abgestimmt: Schrittweise Offenlegung, Cache und geringe Belastung sind sprachunabhängig und funktionieren auch bei nicht-japanischen Websites. Die Heuristiken zur Textextraktion sind jedoch auf japanische Seiten abgestimmt. Wenn bei nicht-japanischen Seiten der Haupttext fehlt, verwenden Sie
selectorodermode: "screenshot"für einen erneuten Abruf.Kein HTTP-Proxy:
HTTP_PROXY/HTTPS_PROXY-Umgebungsvariablen werden nicht berücksichtigt. Der Grund ist, dass das Design, Verbindungen auf verifizierte IPs zu fixieren (gegen DNS-Rebinding), nicht mit der Übergabe der Namensauflösung an einen Proxy vereinbar ist. In Netzwerken, die einen Upstream-Proxy erfordern, ist die Nutzung derzeit nicht möglich.Anti-Bot-Umgehung ist nicht implementiert: Abruf-Fehler durch robots.txt-Ablehnung oder Bot-Schutz sind beabsichtigt. Fehler werden unverändert gemeldet (siehe Geringe Belastung der Zielseiten).
Entwicklung
Nach dem Klonen einmalig den Pre-Commit-Hook für Geheimnisprüfung (gitleaks) aktivieren:
git config core.hooksPath githooksnpm run typecheck # strict 型チェック
npm test # vitest
npm run build # dist/ へビルドZitieren
Bitte verwenden Sie für Artikel oder Forschung die DOI von Zenodo. Die 10.5281/zenodo.21553636 im obigen Badge ist eine Concept-DOI, die für alle Versionen gilt und immer auf die neueste Version auflöst. Um eine bestimmte Version zu referenzieren, holen Sie die DOI dieser Version aus dem Zenodo-Eintrag.
Maschinenlesbare Zitierinformationen finden Sie in CITATION.cff (BibTeX / APA können über „Cite this repository“ auf GitHub generiert werden).
Lizenz
Available Tools
3 toolsfetchFetch a web page as MarkdownARead-only
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) |
TDQS
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.
linksList links from a page (sitemap/RSS-first)ARead-only
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 * |
TDQS
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.
screenshotCapture a tiled screenshot of a web pageARead-only
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) |
TDQS
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
v0.6.0- Changed
fetch2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
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)"
- Changed
links1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
screenshot1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
3 tool updates
v0.1.5- Changed
fetch7 fields changed- changed
Input 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" - changed
Input schema / properties / max_tokens / descriptionPrevious value: -"1ページの概算トークン上限(既定8000)"New value: +"Approximate token budget per page (default 8000)" - changed
Input schema / properties / mode / descriptionPrevious value: -"既定auto"New value: +"Default: auto" - changed
Input schema / properties / page / descriptionPrevious value: -"ページ番号(既定1)"New value: +"Page number (default 1)" - changed
Input schema / properties / section / descriptionPrevious value: -"outlineで得たsection ID。指定時はその節のMarkdownのみ返す"New value: +"Section ID obtained from outline mode; returns only that section's Markdown" - changed
Input schema / properties / selector / descriptionPrevious value: -"本文を絞り込むCSSセレクタ"New value: +"CSS selector to narrow the content" - changed
Input schema / properties / url / descriptionPrevious value: -"取得対象URL(http/httpsのみ。PDFも可)"New value: +"Target URL (http/https only; PDF supported)"
- Changed
links2 fields changed- changed
Input schema / properties / filter / descriptionPrevious value: -"URL/リンクテキストの部分一致、または*を使ったglob"New value: +"Substring match against URL/link text, or a glob using *" - changed
Input schema / properties / url / descriptionPrevious value: -"起点URL"New value: +"Starting URL"
- Changed
screenshot4 fields changed- changed
Input schema / properties / fullPage / descriptionPrevious value: -"既定true。falseの場合は最初のビューポート分(1タイル)のみ撮影する"New value: +"Default true. If false, captures only the first viewport (1 tile)" - changed
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" - changed
Input schema / properties / url / descriptionPrevious value: -"撮影対象のURL(http/httpsのみ)"New value: +"Target URL (http/https only)" - changed
Input schema / properties / width / descriptionPrevious value: -"タイル幅(px)。既定1280"New value: +"Tile width in px (default 1280)"
3 tool updates
- First observed
fetch - First observed
links - First observed
screenshot
TDQS
The 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.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
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.
Related MCP Servers
- AlicenseAqualityDmaintenanceA comprehensive MCP server providing 15 web tools including search, scraping, screenshots, SEO audits, and DNS/SSL checks through a single installation. It delivers clean, LLM-optimized outputs so AI agents can focus on reasoning rather than parsing raw HTML.1515MIT
- AlicenseAqualityAmaintenanceA token-efficient MCP server that gives AI agents structured access to the web, returning compact page summaries and targeted queries instead of full accessibility dumps.23463178MIT

Yutori MCPofficial
AlicenseAqualityBmaintenanceMCP server enabling web monitoring, deep research, and browser automation through Yutori's web agentic technology.1323Apache 2.0- AlicenseNot gradedqualityDmaintenanceMCP server for web scraping and browser automation, enabling AI agents to extract clean, token-efficient content from web pages.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rererr/amenbo'
If you have feedback or need assistance with the MCP directory API, please join our Discord server