English | 中文
水面无痕地滑行 —— 一个面向日文网站的 MCP 服务器，以低影响、低 token 消耗的方式采集网页：通过 outline→section 渐进式披露和仅返回差异的重新获取，保持上下文精简。
amenbo（水黾 / water strider）是为 Claude Code、Codex 等编码代理设计的 MCP 服务器。如同水黾在水面滑行而不激起波澜，它不给采集目标增加负担，以少量 token 从 Web 收集信息。尤其针对日文网站进行了优化。在没有 MCP 客户端的 shell 环境中，也可以作为共享同一核心的 CLI 使用（参见作为 CLI 使用）。
许多通用的爬取工具是以英文网站为前提开发的，在日文网站上经常会出现以下遗漏。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）的实际对比测试，请参阅文章「代理获取网页，工具不同 token 消耗相差 5000 倍」。测试框架和原始日志位于 bench/。
Related MCP server: Charlotte
渐进式披露：先用 mode: outline 仅返回标题树和各节的 token 量，再通过 section 参数只获取需要的章节。不会将冗长页面整体一次性灌入
面向 CJK 的正文修剪：根据标点密度、字符类型比例、链接密度去除导航、广告和页脚
差异响应：重新获取已获取过的 URL 时，若无变更则返回 unchanged，若有变更则仅返回发生变化的章节
自动 Markdown/截图切换：仅对质量评分较低的页面进行截图，避免先读取损坏的 Markdown 再重新截图的往返浪费
按字符类型估算 token：日文、韩文、西里尔字母、表情符号等的 token 单价高于英文，因此按字符类别系数（基于实测校准）计算页面分割预算
两阶段获取：首先使用纯 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）仅需此即可运行。仅当需要使用浏览器（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）在进程内保持热状态，可将截图等图像直接返回对话。也能送达没有 shell 的主机上的代理（如 claude.ai）
CLI：适用于 shell 脚本、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） |
| 单页的估算 token 上限（默认 8000） |
| 设为 true 时禁用差异响应和固定区块去除（ |
links 枚举链接参数 | 说明 |
| 起始 URL |
| URL/链接文本的部分匹配，或使用 |
按 sitemap → RSS/Atom → 页面内链接的顺序进行探索。
screenshot 拍摄截图参数 | 说明 |
| 要拍摄的 URL（仅支持 http/https） |
| 默认 true。设为 false 仅拍摄首个视口区域 |
| 瓦片宽度 px（默认 1280） |
| 分辨率缩放 0.5〜1.0（默认 1.0）。越小图像 token 越少 |
变量 | 默认值 | 说明 |
|
| 缓存（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 等环境变量。原因在于将连接目标固定到已验证 IP 的设计（DNS rebinding 防护）与将域名解析委托给代理的方式无法并存。在必须使用上游代理的网络环境中目前无法使用
不实现 anti-bot 规避：因 robots.txt 拒绝或反爬机制导致的获取失败属于预期行为。失败会如实报告（参见对采集目标的低负载）
clone 后请先执行一次，启用秘密信息检查（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，始终解析到最新版本。如需引用特定版本，请从 Zenodo 记录获取该版本的 DOI。
机器可读的引用信息位于 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
