The ORZ MCP server provides web search and content fetching capabilities for AI assistants through two tools:
Web Search (web_search): Simultaneously queries multiple search engines (Brave, DuckDuckGo, Sogou), then merges, deduplicates, and filters out ads. Returns an array of { url, title, summary } objects. Accepts a query string and optional num_results (default: 8).
Web Fetch (web_fetch): Retrieves content from a specified URL. By default, strips unnecessary HTML and converts to clean Markdown (simplify: true). Supports a configurable max_char_size (default: 50,000 characters) and has a built-in 10-second timeout.
It can be run locally via stdio (with proxy support for international search engines) or connected to a remote deployment on Netlify. Compatible with Claude Desktop, Cursor, OpenCode, and other MCP clients.
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 等）能够搜索互联网和抓取网页内容。
同时查询 Brave、DuckDuckGo 两个搜索引擎，自动合并去重、过滤广告。
入参: query（搜索关键词）、num_results（返回数量，默认 8）
返回: { url, title, summary }[]
抓取指定 URL 的网页内容，默认简化为 Markdown 格式。
入参: url、max_char_size（最大字符数，默认 50000）、simplify（是否简化，默认 true）
返回: 纯文本字符串（Markdown 格式）
内置 10 秒超时
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 客户端配置中添加：
不需要代理：
{
"mcpServers": {
"orz": {
"type": "stdio",
"command": "npx",
"args": ["-y", "orz-mcp"]
}
}
}需要代理（国内用户）：
{
"mcpServers": {
"orz": {
"type": "stdio",
"command": "npx",
"args": ["-y", "orz-mcp", "--proxy", "http://127.0.0.1:7890"]
}
}
}将 http://127.0.0.1:7890 替换为你的代理地址。
无需本地安装任何东西，直接连接部署在 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 分支自动部署。
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.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
