This server provides AI coding agents with real-time web search and webpage content extraction through a local CLIProxyAI (CPA) instance, using multiple AI/search backends without extra API keys.
Perform web searches via the cpa_search tool across configurable engines: gemini, glm, grok, duckduckgo, or auto failover.
Get up-to-date facts, docs, and technical news with structured summaries and authoritative sources.
Fetch and extract webpage content as clean, readable text using the fetch_webpage tool.
Use different search backends for global tech coverage (Gemini), Chinese/local tech research (GLM), real-time knowledge (Grok), or live public web scraping (DuckDuckGo/Bing).
Automatically fail over across engines with the auto mode for reliable results.
Work seamlessly with MCP clients such as Claude Code, Cursor, Codex, Windsurf, and Trae.
Reuse existing local credentials and CPA instance with zero setup, zero extra cost, and zero npm dependencies.
Respect proxy settings for live-web fetches, with automatic proxy resolution and direct local connections.
Provides free public web search as an engine option without requiring API keys.
Provides real-time web search and fact verification using Google's Gemini model, including deep web search.
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., "@CPA Search MCP Server search for latest TypeScript 5.7 release notes"
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.
English | 中文说明
A lightweight, zero-dependency Model Context Protocol (MCP) server for real-time web search and webpage content extraction.
It seamlessly reuses your existing local CLIProxyAPI (CPA) instance (http://127.0.0.1:8317) and authorized Google Gemini, xAI Grok, Zhipu GLM accounts to perform structured web research for AI coding agents (Claude Code, Cursor, Codex, Windsurf, Trae).
⚡ Zero Setup & Zero Extra Cost: Directly uses your existing local CPA and Google/Grok/GLM credentials.
🎯 Multi-Engine Support:
gemini: Structured research summaries via Google Gemini (fast, strong global tech coverage — model knowledge, not a live crawl).
glm: Chinese & local tech research via Zhipu GLM-5.3 (fresher knowledge, deep-reasoning model; slower).
grok: xAI Grok knowledge with a real-time bias.
duckduckgo: True live-web engine — scrapes DuckDuckGo HTML and automatically falls back to Bing when bot-challenged. No API keys.
auto: gemini → glm → live-web automatic failover.
🛡️ Proxy-aware networking: live-web fetches (DuckDuckGo/Bing/fetch_webpage) tunnel through your HTTP proxy via zero-dependency CONNECT, trying CPA_SEARCH_PROXY → HTTPS_PROXY/HTTP_PROXY/ALL_PROXY → http://127.0.0.1:7897 → direct.
🌐 Webpage Content Extraction: Includes a built-in fetch_webpage tool to fetch and strip raw HTML into clean readable text.
🔌 Universal Compatibility: Works with Claude Code, Cursor, Codex, Windsurf, Trae, and any standard MCP client.
🚀 Zero Dependencies: Pure Node.js ESM standard library implementation. Instant startup and minimal memory footprint.
Related MCP server: DuckDuckGo MCP Server
Run the following command in your terminal:
claude mcp add --scope user cpa-search node "C:/Users/aa182/Documents/Codex/2026-08-22/new-chat-2/repositories/cpa-search-mcp/index.mjs"Verify status:
claude mcp listAdd the following to your MCP configuration file (e.g. claude_desktop_config.json or Cursor MCP settings):
{
"mcpServers": {
"cpa-search": {
"command": "node",
"args": [
"C:/Users/aa182/Documents/Codex/2026-08-22/new-chat-2/repositories/cpa-search-mcp/index.mjs"
]
}
}
}cpa_searchSearch the web for up-to-date facts, documentation, and technical news.
Parameters:
query (string, required): The search query or research topic.
engine (string, optional): gemini | glm | grok | duckduckgo | auto.
fetch_webpageFetch and extract clean text from any URL.
Parameters:
url (string, required): The webpage URL (http/https).
Variable | Default | Description |
|
| Local CPA proxy address |
| (Built-in Local Key) | CPA authentication key |
|
| Model used by the |
|
| Model used by the |
| (see chain below) | Explicit outbound proxy for live-web fetches; set to an empty string to force direct connection |
| falls back to | Outbound proxy for live-web fetches ( |
Proxy resolution order for live-web fetches:
CPA_SEARCH_PROXY→HTTPS_PROXY/HTTP_PROXY/ALL_PROXY→ local Clash/mihomo default (http://127.0.0.1:7897) → direct connection. Local addresses (CPA itself) always go direct.
Run the automated end-to-end test suite:
node test.mjsMIT License © 2026 ffffhx
使用本地已登录的 Gemini / Grok / GLM 账号进行实时全网搜索，获取最新技术动态、文档与事实总结，并附带权威来源。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词或想要查询的最新信息 | |
| engine | No | 指定搜索引擎后端：gemini (Google 检索，默认推荐)、glm (智谱中文检索)、grok (xAI实时检索)、duckduckgo (公共搜索)、auto (默认自动智能选择) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses a key prerequisite (using locally logged-in accounts) and notes real-time retrieval with authoritative sources. However, it does not mention potential failures (e.g., no logged-in accounts), rate limits, or result formatting, leaving gaps.
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 front-loads the core function (real-time web search) and adds relevant context (accounts, sources) without extraneous words. It is optimally sized.
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?
Despite lacking an output schema, the description hints at return content (tech trends, documents, fact summaries, sources) and the prerequisite of logged-in accounts. It does not explain error handling or pagination, but these are less critical for a simple search tool. Overall, it provides sufficient context for an agent to call it 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?
Schema description coverage is 100%, and the description does not add significant meaning beyond the schema. It mentions using logged-in accounts, which links to the 'engine' parameter, but the schema already explains each backend option. The description adds minimal value for parameters.
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 explicitly states the tool performs real-time web-wide search ('实时全网搜索'), retrieves latest tech trends, documents, and fact summaries with authoritative sources. This clearly distinguishes it from the sibling 'fetch_webpage', which fetches a specific page.
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 implies usage for searching rather than fetching specific pages, but it does not explicitly state when to use this tool over 'fetch_webpage' or provide exclusion criteria. The context of 'search' vs 'fetch' is implicit but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
直接抓取指定 URL 网页的完整正文内容并转换为易读的文本
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 需要抓取的完整网页网址（例如 https://docs.example.com） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It mentions fetching the 'complete main content' and converting to text, but omits any mention of handling dynamic content, authentication, timeouts, or error cases. This is a significant gap for a web-fetching tool.
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 with no unnecessary words. It is concise and gets to the point, though it could slightly benefit from structuring key constraints more explicitly.
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?
For a tool with a single parameter and no output schema, the description should cover potential failure modes and limitations. It lacks any mention of what happens on failure, unsupported URL types, or rate limits. Given the lack of annotations, this is incomplete for safe agent use.
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 url parameter is already well-documented. The description does not add extra semantic meaning beyond what the schema provides, matching 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 verb 'fetch' and the resource 'webpage', and adds that it converts content to readable text. It is specific enough, though it doesn't explicitly contrast with sibling tool cpa_search, which appears to be a different operation.
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 guidance is given on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description simply states what it does, leaving the agent to infer when it is appropriate.
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.0cpa_searchfetch_webpageScored across 2 tools
两个工具功能明确分离：cpa_search用于搜索并返回结果，fetch_webpage用于抓取特定URL的内容。没有重叠或模糊边界，代理可以轻松区分何时使用哪个工具。
两个工具均使用snake_case，且都包含动作词（search, fetch），但cpa_search以名词cpa开头，而fetch_webpage以动词开头，存在轻微不一致。不过整体模式简单且可预测，不影响理解。
仅2个工具对于搜索服务器而言显得单薄，但结合其功能（搜索+网页抓取）已覆盖核心需求。未超出合理范围，但处于评分的下限。
搜索和网页抓取共同构成完成查询-获取详情的基本流程，没有明显缺失的关键操作。但缺少如历史记录、批量处理等扩展功能，仍有小幅度提升空间。
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
Web search for AI agents — one tool across 6 engines, routed to the cheapest + cached.
Fetch pages as markdown, search web and news, extract structured data. For AI agents.
