Provides web search capabilities using Baidu's search engine.
Provides web search capabilities using DuckDuckGo's search engine.
Click on "Install 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., "@MCP Web Server search for latest AI news and extract the first result"
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.
本项目是一个本地 MCP Server，提供免费网络访问能力，可接入 Claude Desktop / Claude Code 等 MCP 客户端。
http_request: 通用 HTTP 请求
web_search: 可配置搜索引擎（DuckDuckGo / Bing / 百度）
extract_webpage_content: 网页正文提取（含标题、列表、表格、代码块、引用）
fetch_json: 获取并解析 JSON
web_search_and_extract: 搜索 + 并发提取一体化
batch_http_request: 批量并发请求
screenshot_webpage（可选）: 网页截图并返回 Base64（需安装 Playwright）
Related MCP server: web-search-mcp
uv pip install -e .开发依赖：
uv pip install -e ".[dev]"uv run python run_server.pyclaude mcp add web-server -s local -- uv run --directory /path/to/your/project python run_server.py请参考仓库中的示例配置文件：claude_desktop_config.example.json。
使用前将
--directory路径改为你的本地项目路径。
uv pip install -e ".[dev]"
pytest变量名 | 说明 | 默认值 |
| 日志级别 |
|
| HTTP 代理 | 空 |
| HTTPS 代理 | 空 |
| 自定义 User-Agent | 内置 UA |
| 默认请求超时（秒） |
|
| 搜索引擎： |
|
| Bing 检索域名（可设 |
|
| 可选搜索 API Key（预留扩展） | 空 |
| 可选搜索 API Endpoint（预留扩展） | 空 |
|
|
|
|
|
|
|
|
|
| 非法 stdin 行处理策略： |
|
MCP_STDIN_INVALID_INPUT_POLICY 说明：
warn（默认）：忽略非法 JSON-RPC 行并记录 warning
ignore：忽略非法 JSON-RPC 行且不记录 warning
strict：收到非法 JSON-RPC 行即快速失败（便于定位客户端写入问题）
MCP_SEARCH_ENGINE 说明：
duckduckgo：默认选项，无 API Key；在部分网络环境下可能不可用。
bing：默认使用 www.bing.com 页面检索；可通过 MCP_BING_DOMAIN=cn.bing.com 切换大陆入口。
baidu：使用百度网页检索；中国大陆可用性通常较好。
可选 API Key 模式说明：
当前版本默认使用“网页检索”模式（无需 API Key）。
MCP_SEARCH_API_KEY / MCP_SEARCH_API_ENDPOINT 已预留，便于后续接入官方 API 或第三方聚合 API。
uv pip install -e ".[screenshot]"
playwright install chromium项目内提供了一个基于 Flask 的辅助配置界面（web_config.py / run_web_config.py），用于通过浏览器引导执行 claude mcp add：
uv pip install -e ".[web]"
uv run python run_web_config.py打开 http://localhost:5000 即可使用。
如果你只通过命令行配置 MCP，可忽略这两个文件。
flowchart TD
Client[MCP Client] --> Server[FastMCP Server]
Server --> Tools[Tools Layer]
Tools --> Search[web_search / web_search_and_extract]
Tools --> Http[http_request / batch_http_request / fetch_json]
Tools --> Extract[extract_webpage_content]
Tools --> Shot[screenshot_webpage optional]
Http --> AsyncClient[Shared httpx.AsyncClient]
Extract --> AsyncClient
Search --> DDGS[DuckDuckGo via asyncio.to_thread]
Search --> Bing[Bing HTML parsing]
Search --> Baidu[Baidu HTML parsing + redirect resolve]详见 CHANGELOG.md。
本项目采用 Apache License 2.0 许可证。
Copyright 2025 MCP Web Server Contributors
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| method | No | GET | |
| headers | No | ||
| timeout | No | ||
| max_concurrent | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| max_length | No | ||
| include_links | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| method | No | GET | |
| headers | No | ||
| timeout | No | ||
| json_data | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | y | |
| query | Yes | ||
| region | No | wt-wt | |
| num_results | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| region | No | wt-wt | |
| num_results | No | ||
| max_content_length | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Several tools have overlapping purposes: http_request and fetch_json both perform HTTP requests, and web_search and web_search_and_extract overlap in functionality. The distinctions between generic request and search/extract operations are unclear without detailed descriptions.
Tool names mix different patterns: some start with verbs (fetch_json, extract_webpage_content), while others are noun phrases (http_request, web_search) or compound verbs (web_search_and_extract). No consistent verb_noun convention is followed.
Six tools is a reasonable number for a web server utility, covering HTTP requests, JSON handling, batch operations, search, and extraction without being excessive or minimal.
The set covers core web operations: making requests, fetching JSON, batch processing, searching, and extracting content. Minor gaps exist, such as no explicit tool for HTML parsing beyond extraction, but the core surface is largely complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
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.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhaiy/local-webserver-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
