This server gives AI assistants two web tools: searching the internet and fetching web page content.
web_search — Searches the web via multiple engines (Brave, Sogou, DuckDuckGo) in parallel, deduplicating results and filtering ads; takes query (required) and num_results (default 8), returns {url, title, summary}[].
web_fetch — Retrieves a URL's content with a 10-second timeout; takes url (required), max_char_size (default 50000), and simplify (default true, strips useless HTML and converts to Markdown); returns plain text/Markdown, errors clearly on non-text types like PDFs or images, and (in the HTTP version) blocks SSRF to loopback/private/link-local addresses.
Enables web search capabilities by querying the Brave search engine to retrieve results that are automatically deduplicated and filtered for ads.
Provides web search functionality by querying DuckDuckGo to retrieve results that are automatically deduplicated and filtered for ads.
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., "@ORZ MCP search for the latest news on Claude 3.5 Sonnet and summarize it"
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.
一个提供 web_search 和 web_fetch 能力的 MCP (Model Context Protocol) 服务器。
让你的 AI 助手（Claude、Cursor、OpenCode 等）能够搜索互联网和抓取网页内容。
通过 DuckDuckGo 搜索网页，自动去重、过滤广告。
入参: query（搜索关键词）、num_results（返回数量，默认 8）
返回: { url, title, summary }[]
抓取指定 URL 的网页内容，默认简化为 Markdown 格式。
入参: url、max_char_size（最大字符数，默认 50000）、simplify（是否简化，默认 true）
返回: 纯文本字符串（Markdown 格式）
内置 10 秒超时（覆盖重定向、<meta refresh> 跳转和读取正文）
支持表格（GFM）、保留代码块换行；PDF、图片等非文本类型会明确报错，不返回乱码
Streamable HTTP 版内置 SSRF 防护：拒绝回环、内网、链路本地（如云元数据 169.254.169.254）等地址，每次重定向都会重新校验
Related MCP server: Web Search MCP Server
ORZ MCP 提供 stdio 和 Streamable HTTP 两种 MCP 传输协议的实现，功能完全一致，根据你的需求选择其中一种即可。
stdio | Streamable HTTP | |
运行方式 | 通过 npx 本地启动 | 远程 HTTP 服务（Netlify Functions） |
适用场景 | 本地运行，支持代理 | 开箱即用，支持云端部署、住宅代理 |
代理支持 | 支持 | 支持环境变量 |
依赖 | Node.js >= 18 | 无 |
无需安装，直接通过 npx 运行。
在你的 MCP 客户端配置中添加：
1. 配置住宅代理（或科学上网代理）：
{
"mcpServers": {
"orz": {
"type": "stdio",
"command": "npx",
"args": ["-y", "orz-mcp", "--proxy", "http://user:pass@proxy-host:port"]
}
}
}无需本地安装任何东西，直接连接部署在 Netlify 上的远程服务。
{
"mcpServers": {
"orz": {
"type": "http",
"url": "https://<your-netlify-domain>/mcp"
}
}
}如果你的 MCP 客户端不支持直接 URL 连接，可以通过 mcp-remote 桥接：
{
"mcpServers": {
"orz": {
"command": "npx",
"args": ["mcp-remote@next", "https://<your-netlify-domain>/mcp"]
}
}
}不同的 MCP 客户端配置文件位置不同：
Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS)
Cursor: Settings > MCP Servers
OpenCode: .opencode/config.json 或通过 /mcp 命令添加
orz-mcp/
├── stdio/ # stdio 传输协议 (npm 包)
│ ├── client.mjs # 入口文件
│ └── package.json # npm 发布配置（依赖: mcp sdk, turndown, undici）
├── streamable-http/ # Streamable HTTP 传输协议 (Netlify Functions)
│ ├── netlify/
│ │ ├── mcp-server/
│ │ │ └── index.ts # MCP Server 定义（工具注册与业务逻辑）
│ │ └── functions/
│ │ └── hono-mcp-server.ts # Hono HTTP handler (Netlify Function)
│ ├── public/
│ │ └── index.html # 静态首页
│ ├── netlify.toml # Netlify 构建配置
│ └── package.json # 服务端依赖（依赖: mcp sdk, hono, zod, turndown）
└── README.mdcd stdio
npm install
node client.mjs
node client.mjs --proxy http://127.0.0.1:7890
node client.mjs --help
# 用 MCP Inspector 调试
npx @modelcontextprotocol/inspector node client.mjscd streamable-http
npm install
# 启动本地开发服务器（需要 Netlify CLI）
netlify dev
# 用 MCP Inspector 测试（在 UI 中选择 Streamable HTTP，填入 URL）
npx @modelcontextprotocol/inspector --url http://localhost:8888/mcpcd streamable-http
# 安装 Netlify CLI
npm install -g netlify-cli
# 登录
netlify login
# 初始化并关联站点
netlify init
# 部署
netlify deploy --prod或者通过 GitHub 连接 Netlify，push 到 main 分支自动部署。
变量 | 说明 |
| 出站代理（如住宅 IP 代理）。配置后域名由代理解析，SSRF 防护只校验 IP 字面量和 |
| 逗号分隔的主机名/IP 白名单，允许 |
MIT
Fetch a web page and return its content. When simplify is enabled (default), removes useless HTML tags and converts to Markdown. Has a 10-second timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to fetch | |
| max_char_size | No | Maximum character size of the returned content (default: 50000) | |
| simplify | No | Whether to simplify the content by removing useless tags and converting to Markdown (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses key behavioral traits: it describes the transformation behavior (removing useless HTML tags, converting to Markdown when simplify is enabled), timeout constraint (10 seconds), and default settings (simplify enabled by default). This provides essential operational context beyond basic functionality.
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 appropriately sized and front-loaded: the first sentence states the core purpose, and subsequent sentences efficiently add crucial behavioral details (simplification behavior, timeout). Every sentence earns its place with no wasted words or redundancy.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is largely complete: it covers purpose, key behavior, and constraints. However, it doesn't describe the return format (e.g., structure of the content) or error handling, which would be helpful given the lack of output schema.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning the simplify parameter's effect, but doesn't provide additional syntax, format details, or usage examples. This meets the baseline for high schema coverage.
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 with specific verbs ('fetch a web page', 'return its content') and distinguishes it from sibling tools by focusing on direct URL fetching rather than searching. It specifies the resource (web page) and transformation behavior (simplification to Markdown).
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 clear context for when to use this tool (fetching web pages with optional simplification) but does not explicitly mention when not to use it or name alternatives. It implies usage for direct URL access rather than search-based retrieval, though it doesn't contrast with the sibling 'web_search' tool by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web using multiple search engines (Brave, Sogou, DuckDuckGo) simultaneously. Results are deduplicated and ads are filtered out. Returns an array of search results with url, title, and summary.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keywords separated by spaces | |
| num_results | No | Number of results to return (default: 8) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it uses multiple search engines (Brave, Sogou, DuckDuckGo), performs deduplication, filters out ads, and describes the return format. However, it doesn't mention rate limits, authentication needs, or error handling.
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 perfectly concise and front-loaded: two sentences that efficiently cover purpose, implementation details, and output without any wasted words. Every sentence adds essential value to the tool's understanding.
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 moderate complexity, no annotations, and no output schema, the description is mostly complete—it covers what the tool does, how it works, and what it returns. However, it lacks details on error cases, rate limits, or example usage, which would enhance completeness for a search tool.
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 schema description coverage is 100%, so the input schema already fully documents both parameters ('query' and 'num_results'). The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced coverage.
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 specific action ('Search the web') with precise details on implementation ('using multiple search engines simultaneously'), resource scope ('the web'), and output format ('array of search results'). It distinguishes from the sibling tool 'web_fetch' by focusing on search rather than fetching specific URLs.
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 clear context for when to use this tool (web searching with deduplication and ad filtering), but it doesn't explicitly state when not to use it or mention the sibling tool 'web_fetch' as an alternative for specific use cases. The guidance is implicit rather than explicit.
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.
v1.0.0web_fetchweb_searchScored across 2 tools
The two tools have clearly distinct purposes: web_fetch retrieves and processes the content of a specific URL, while web_search queries multiple search engines to find relevant web pages. There is no overlap in functionality, making it easy for an agent to choose the right tool for the task.
Both tools follow a consistent 'web_' prefix and snake_case naming pattern (web_fetch and web_search). The naming is predictable and aligns with their web-related functions, providing clear and uniform conventions.
With only two tools, the server feels thin for a web-related domain. While the tools cover fetching and searching, there are obvious gaps such as navigation, form handling, or API interactions that could enhance completeness, making the count insufficient for robust web operations.
The tool set is severely incomplete for web-related tasks. It lacks essential operations like navigating between pages, handling cookies or sessions, interacting with forms, or accessing APIs. This will likely cause agent failures when trying to perform common web automation or data extraction workflows.
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Unblocking and fresh web data for agents: URL to Markdown, YouTube, Maps, Amazon, jobs. Pay per call
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
