Web search via Brave Search API; future extension requiring API key.
Web search via DuckDuckGo HTML search, no API key required.
Web search via SearXNG meta search engine, self-hosted or local.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@web-mcp search for MCP server setup guide"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Claude Code / Codex から利用する Web 検索・Web ページ取得用の MCP サーバーです。
開発は Windows でも行えますが、運用時は Docker 上の Ubuntu で動かす前提です。
Linux / Docker コンテナ内の想定:
npm install
npm run build
npm run devWindows 開発環境:
npm install
npm run build
npm run devDocker イメージで HTTP MCP サーバーとして起動:
docker build -t web-mcp .
docker run --rm -p 3000:3000 web-mcpDocker Compose で起動:
cd mcp
docker compose up -d --buildHTTP MCP endpoint:
http://localhost:3000/mcpstdio サーバーとして使う場合は、クライアントが node dist/index.js を起動します。
Docker で stdio として使う場合は、docker run -i --rm web-mcp node dist/index.js のように標準入力・標準出力をクライアントへ接続してください。
ビルド後、MCP クライアントからは以下のように起動できます。
{
"mcpServers": {
"web-mcp": {
"command": "node",
"args": ["/app/mcp/dist/index.js"],
"env": {
"WEB_MCP_DEFAULT_RENDER": "auto",
"WEB_MCP_FETCH_TIMEOUT_MS": "15000",
"WEB_MCP_USER_AGENT": "LocalLLM-WebMCP/0.1"
}
}
}
}Related MCP server: mcp-web-tools
web_search: DuckDuckGo HTML 検索で実検索し、検索結果一覧を返します。
web_fetch: http / https URL を取得し、HTML から本文・タイトル・リンクを抽出します。
web_find: web_fetch 相当の取得結果から指定文字列を検索します。
検索プロバイダーは無料で使えるものを優先します。
現在の実装:
DuckDuckGo HTML 検索: API キー不要で利用
将来候補:
SearxNG: 社内またはローカルで立てるメタ検索
Brave Search などの API キーが必要な provider は、無料枠が必要になった場合の拡張候補
環境変数で主な既定値を変更できます。
環境変数 | 既定値 | 用途 |
|
| MCP サーバー名 |
|
|
|
|
|
|
|
| 既定の render 指定 |
|
| 静的 fetch のタイムアウト |
|
| 将来のブラウザ取得用タイムアウト |
|
| 静的 fetch で送信する User-Agent |
| 未指定 |
|
|
| HTTP MCP サーバーの bind host |
|
| HTTP MCP サーバーの port |
実装済み:
MCP stdio server
MCP Streamable HTTP server
web_search / web_fetch / web_find の登録
DuckDuckGo HTML による実検索
web_search の time_range / include_domains / exclude_domains 対応
AbortController による静的 fetch timeout
設定値からの User-Agent 送信
redirect 後の final_url 返却
静的 HTML / XHTML / plain text fetch
Content-Type 判定と未対応形式の error レスポンス
Readability + Turndown による Markdown 風テキスト化
Readability が本文を十分に抽出できない場合の DOM fallback 抽出
max_chars / truncated 対応と Markdown 破損を抑える切り詰め
include_links 指定時のリンク抽出
fetch 失敗 / timeout の error レスポンス
未実装:
Playwright によるブラウザレンダリング取得
PDF テキスト抽出
取得済みページのキャッシュ
失敗時も MCP ツールとしては JSON を返し、error に原因を入れます。
{
"error": {
"code": "FETCH_TIMEOUT",
"message": "The operation was aborted.",
"url": "https://example.com",
"retryable": true
}
}主な code は FETCH_FAILED、FETCH_TIMEOUT、UNSUPPORTED_CONTENT_TYPE、BROWSER_RENDER_FAILED です。
PDF は現時点では UNSUPPORTED_CONTENT_TYPE として返します。
Fetch a URL with static HTTP and return readable Markdown-style page text.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to fetch. | |
| render | No | auto | |
| max_chars | No | ||
| timeout_ms | No | ||
| wait_until | No | networkidle | |
| include_code | No | ||
| include_links | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'static HTTP' but the input schema includes a 'render' parameter with options 'browser', implying dynamic rendering is possible. This contradiction misleads the agent. No mention of authentication, rate limits, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It is too brief to be self-sufficient and misses important details about parameters and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, 2 enums, and no output schema, the description is severely incomplete. It omits rendering behavior, output format, error handling, and performance considerations, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only 'url' has a description). The tool description adds no additional meaning to any parameter; it does not explain the crucial 'render' enum or other parameters. This fails to compensate for the sparse 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?
The description clearly states the tool fetches a URL and returns Markdown-style text, which is a specific verb-resource pair. However, it does not distinguish from sibling tools web_find and web_search, which likely search for content rather than fetch a specific URL.
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?
No explicit guidance on when to use this tool versus alternatives. There is no mention of when not to use it or any context hints about prerequisites or limitations relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL with static HTTP and find text within the extracted page text.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to search within. | |
| query | Yes | Text to find. | |
| render | No | auto | |
| timeout_ms | No | ||
| max_matches | No | ||
| context_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It mentions 'static HTTP' implying no JS execution, but omits details on error handling, auth, rate limits, or behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that quickly conveys the core function. It is front-loaded and efficient, though it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 2 required, no output schema, no annotations), the description is too sparse. It lacks explanations for essential configuration options and output behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the schema; it only implies the 'query' parameter's purpose. With 33% schema coverage, it fails to explain other parameters like render, timeout, or context_chars.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: fetch a URL using static HTTP and find text within the extracted page. It differentiates from siblings by focusing on text search within a single page, but could be more explicit about its niche.
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 no guidance on when to use this tool versus alternatives like web_fetch or web_search, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web and return a list of candidate pages. This scaffold returns mock results only.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query. | |
| region | No | jp | |
| language | No | ja | |
| time_range | No | any | |
| max_results | No | ||
| exclude_domains | No | ||
| include_domains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It discloses mock behavior, which is critical, but omits other behaviors like error handling or return format.
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?
Two sentences, extremely concise, front-loaded with key action and important caveat.
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 7 parameters, no output schema, and no annotations, the description is far too sparse to guide effective use. It fails entirely to cover parameter behavior or expected output.
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 14% (only 'query' described). Description adds no parameter info beyond the schema, leaving 6 parameters unexplained.
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 states it searches the web and returns candidate pages, which is clear. However, it does not differentiate from siblings web_fetch and web_find.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes mock results only, which guides against real use. But lacks guidance on when to choose this over siblings or other conditions.
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.1.0web_fetchweb_findweb_searchScored across 3 tools
web_fetch and web_find both involve fetching a URL, but one returns the full page text and the other finds specific text within it, making their purposes distinct with clear descriptions. web_search is entirely different.
All tools follow the consistent 'web_verb' pattern (fetch, find, search), indicating a predictable naming convention.
Three tools is an appropriate number for a web utility server, covering core operations without being too sparse or excessive.
The tools cover basic web tasks (fetch, find text, search) but lack advanced features like POST requests, pagination, or element extraction, which are notable gaps for a comprehensive web server.
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Fetch pages as markdown, search web and news, extract structured data. For AI agents.
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
