Wuxing Search MCP は、SearXNG をベースに構築された強力な無制限検索サーバーです。モデルコンテキストプロトコル（MCP）を通じて Claude Code とシームレスに統合され、100 以上の検索エンジンの結果を統合することで、無料かつ無制限の検索機能を提供します。
従来の検索 API には以下のような制限があります：
❌ レート制限とクォータ
❌ 高額な API コスト
❌ 単一ソースの結果
Wuxing Search はこれらすべての問題を解決します：
✅ 完全無料 - SearXNG をセルフホストするため、API コストはゼロ
✅ 無制限検索 - レート制限を無効化し、高頻度の検索をサポート
✅ マルチソース統合 - Google、Bing、DuckDuckGo、Brave など 100 以上のエンジン
✅ プライバシー重視 - 追跡なし、ログ記録なし
✅ MCP 統合 - Claude Code ワークフローに最適
Related MCP server: SearXNG MCP Server
┌─────────────┐ ┌──────────────┐ ┌─────────────┐ ┌─────────────┐
│ 你 │ ───▶ │ Claude Code │ ───▶ │ Wuxing │ ───▶ │ SearXNG │
│ (用户) │ │ (MCP 客户端) │ │ Search MCP │ │ (Docker) │
└─────────────┘ └──────────────┘ │ (Node.js) │ │ (Python) │
└──────────────┘ └─────────────┘
│
▼
┌───────────────────────────┐
│ 搜索引擎聚合 (13+) │
│ 通用: Google, Bing... │
│ 代码: GitHub, HuggingFace│
│ 问答: StackOverflow │
│ 包: npm, PyPI │
│ 学术: arXiv │
│ 社区: HN, Reddit │
│ 以及 100+ 更多... │
└───────────────────────────┘🔍 無制限の Web 検索
API レート制限やクォータなし
高頻度の検索をサポート
結果数を設定可能（1-100）
🌐 マルチソース統合
一般：Google、Bing、DuckDuckGo、Baidu
コード：GitHub、Hugging Face、GitLab
Q&A：Stack Overflow
パッケージ：npm、PyPI、crates.io、Docker Hub
学術：arXiv、Google Scholar、Semantic Scholar、PubMed
コミュニティ：HackerNews、Reddit、Mastodon
ドキュメント：MDN
ニュース：Google News
100 以上の検索エンジンをサポート
📊 高度な検索オプション
時間範囲フィルタ（日、週、月、年）
カテゴリフィルタ（一般、画像、動画、ニュース、IT、科学、ファイル、ソーシャル）
言語フィルタ
セーフサーチレベル
🔌 MCP 統合
Claude Code とのシームレスな統合
stdio 通信（MCP はネットワークポートを必要としません）
JSON-RPC 2.0 プロトコル
🐳 簡単なデプロイ
Docker ベースの SearXNG デプロイ
ワンクリックインストール
クロスプラットフォーム対応（Windows、macOS、Linux）
🔒 プライバシー優先
追跡なし、ログ記録なし
セルフホスト型で、データはマシンから外部へ流出しません
SearXNG を介した匿名検索
4 つの簡単なステップで開始できます：
git clone https://github.com/MaesHughes/wuxing-search-mcp.git
cd wuxing-search-mcpnpm install方法 A：Docker コマンドを使用（推奨）
docker run -d \
--name wuxing-searxng \
--restart unless-stopped \
-p 18080:8080 \
-v "$(pwd)/searxng/config:/etc/searxng/" \
-v "$(pwd)/searxng/data:/var/cache/searxng/" \
searxng/searxng:latest方法 B：Docker Compose を使用
docker-compose up -dClaude Code の設定ファイルを見つけます：
Windows:
%APPDATA%\Claude\claude_desktop_config.jsonmacOS / Linux:
~/.config/Claude/claude_desktop_config.jsonプロジェクトディレクトリで以下のコマンドを実行し、絶対パスを取得します：
Windows (PowerShell):
Resolve-Path src\index.jsWindows (Git Bash / Bash):
pwd -W && echo "/src/index.js"
# 或手动拼接：$(pwd -W)/src/index.jsmacOS / Linux:
pwd && echo "/src/index.js"
# 或手动拼接：$(pwd)/src/index.js設定ファイルに以下の設定を追加します。⚠️ YOUR_FULL_PATH_HERE を前のステップで取得した実際のパスに必ず置き換えてください：
{
"mcpServers": {
"wuxing-search": {
"type": "stdio",
"command": "cmd",
"args": [
"/c",
"node",
"D:\\\\path\\\\to\\\\wuxing-search-mcp\\\\src\\\\index.js"
],
"env": {
"SEARXNG_URL": "http://localhost:18080",
"MAX_RESULTS": "20",
"TIMEOUT": "30000"
}
}
}
}{
"mcpServers": {
"wuxing-search": {
"type": "stdio",
"command": "node",
"args": [
"/home/username/wuxing-search-mcp/src/index.js"
],
"env": {
"SEARXNG_URL": "http://localhost:18080",
"MAX_RESULTS": "20",
"TIMEOUT": "30000"
}
}
}
}設定の説明：
設定項目 | Windows | macOS/Linux | 説明 |
|
|
| 通信プロトコルの種類 |
|
|
| Windows は cmd ラッパーを使用 |
|
|
| パスは絶対パスである必要があります |
| SearXNG サービスアドレス | - | デフォルト |
| デフォルトの検索結果数 | - | デフォルト 20、範囲 1-100 |
| リクエストタイムアウト（ミリ秒） | - | デフォルト 30000 |
⚠️ 重要な注意点：
Windows パスのバックスラッシュはダブルバックスラッシュ \\ にエスケープする必要があります（JSON 形式の要件）
または、フォワードスラッシュ / を使用してください（Windows もサポートしています）
パスは絶対パスである必要があり、相対パスは機能しません
設定を変更した後は、Claude Code を完全に再起動する必要があります
Claude Code を完全に終了し、再度開きます。
Claude Code で直接入力します：
请搜索最新的 AI 编程工具パラメータを指定することもできます：
请搜索最近一周的 React 教程，返回 10 条结果Web 検索を実行し、結果を返します。
パラメータ | 説明 | 必須 | デフォルト値 |
| 検索キーワード | はい | - |
| 結果数（1-100） | いいえ | 20 |
| 検索カテゴリ | いいえ | general |
| 言語コード | いいえ | all |
| 時間範囲フィルタ | いいえ | none |
| セーフサーチレベル（0-2） | いいえ | 1 |
カテゴリオプション：
general - 一般検索
images - 画像検索
videos - 動画検索
news - ニュース検索
it - IT 技術
science - 科学
files - ファイル
social - ソーシャルメディア
時間範囲オプション：
day - 過去 24 時間
week - 過去 1 週間
month - 過去 1 ヶ月
year - 過去 1 年
none - フィルタなし
検索サーバーのステータス情報を取得します。パラメータなし。
请搜索 GitHub 上热门的 AI agent 项目在 Stack Overflow 上搜索 MCP 连接错误的解决方案请搜索 arXiv 上关于多智能体协作的最新论文在 PyPI 上搜索 LangChain agents 相关的包请搜索 HackerNews 上关于 AI 编程的讨论查询搜索服务器状态# 查看 SearXNG 状态
npm run status:searxng
# 查看 SearXNG 日志
npm run logs:searxng
# 重启 SearXNG
npm run restart:searxng
# 停止 SearXNG
npm run stop:searxng
# 启动 SearXNG
npm run start:searxng
# 测试搜索服务
npm run test:searxng# 查看容器状态
docker ps | grep wuxing-searxng
# 查看实时日志
docker logs -f wuxing-searxng
# 重启服务
docker restart wuxing-searxng
# 停止服务
docker stop wuxing-searxng
# 启动服务
docker start wuxing-searxng
# 删除并重建
docker stop wuxing-searxng && docker rm wuxing-searxng
# 然后重新运行启动命令環境変数を通じて MCP サーバーを設定します：
変数 | 説明 | デフォルト値 |
| SearXNG サービスアドレス | |
| デフォルトの検索結果数 | 20 |
| リクエストタイムアウト（ミリ秒） | 30000 |
Claude Code 設定の env フィールドにこれらの変数を追加して動作をカスタマイズします。
チェックリスト：
✅ SearXNG コンテナは実行中ですか？
docker ps | grep wuxing-searxng✅ SearXNG サービスは正常ですか？
curl http://localhost:18080✅ 設定ファイルのパスは正しいですか（絶対パスを使用）？
✅ Node.js のバージョンは 18 以上ですか？
node --version✅ Claude Code は再起動しましたか？
チェック：
ポート 18080 が使用されていませんか？
# Windows
netstat -ano | findstr :18080
# Linux/Mac
lsof -ti:18080Docker サービスは実行中ですか？
コンテナログを確認：
docker logs wuxing-searxng解決策：
# 删除旧容器并重新创建
docker stop wuxing-searxng && docker rm wuxing-searxng
# 然后重新运行启动命令原因: SearXNG サービスが完全に起動していない
解決策：
# 等待 5-10 秒后重试
# 或重启 SearXNG
docker restart wuxing-searxng原因: 時間フィルタは検索エンジンのサポートに依存します
解決策：
より短い時間範囲を使用する（week ではなく day）
クエリに明確な時間キーワードを追加する（例：2025年1月）
組み合わせて使用：
请搜索 2025年1月的 React 新特性ファイル：src/index.js
依存関係：@modelcontextprotocol/sdk, axios
通信：stdio（標準入出力）
役割：MCP プロトコルの実装、SearXNG へのリクエスト転送
イメージ：searxng/searxng:latest
ポート：18080（ホスト）→ 8080（コンテナ）
設定：searxng/config/settings.yml
データ：searxng/data/（キャッシュ）
役割：100 以上の検索エンジンの統合
用户输入
→ Claude Code
→ MCP Server (stdio)
→ HTTP 请求到 SearXNG
→ 并发请求到各搜索引擎
→ 聚合结果
→ 返回给用户wuxing-search-mcp/
├── src/ # MCP Server 源码
│ └── index.js # MCP Server 主实现
├── searxng/ # SearXNG 配置
│ ├── config/ # SearXNG settings.yml
│ └── data/ # SearXNG 缓存（自动创建）
├── assets/ # 文档图片
│ └── banner.png # 项目横幅
├── package.json # NPM 包配置
├── docker-compose.yml # Docker Compose 配置
├── install.sh # Linux/Mac 安装脚本
├── install.ps1 # Windows 安装脚本
├── README.md # 英文版
├── README.zh-CN.md # 中文版（本文件）
└── INSTALL.md # 详细安装指南A: SearXNG は Python プロジェクトであり、50 以上の Python パッケージに依存しています。Docker は以下を提供します：
複雑な手動依存関係インストールの回避
環境の分離
デプロイと更新の簡素化
A: 理論上は可能ですが、推奨されません。以下の作業が必要です：
Python 3.14 のインストール
50 以上の Python 依存関係の手動インストール
Python 環境の設定
Docker ソリューションの方がシンプルで信頼性が高いです。
A: ありません！これが本プロジェクトの核心的な利点です：
完全セルフホスト
API 呼び出し制限なし
リクエストレート制限なし
A: SearXNG は 245 の検索エンジンをサポートしており、デフォルトで 89 が有効になっています。
現在有効な 21 のエンジン：
カテゴリ | 検索エンジン |
一般検索 | Google, Bing, DuckDuckGo, Baidu |
コードリポジトリ | GitHub, Hugging Face, GitLab |
技術 Q&A | Stack Overflow |
パッケージマネージャ | npm, PyPI, crates.io, Docker Hub |
学術論文 | arXiv, Google Scholar, Semantic Scholar, PubMed |
開発者コミュニティ | HackerNews, Reddit, Mastodon |
開発ドキュメント | MDN Web Docs |
ニュースソース | Google News |
その他の利用可能なエンジン（設定で有効化可能）：
コード：Bitbucket, Codeberg, Gitea, SourceHut
パッケージ管理：RubyGems, Go, Hex, Packagist
ソーシャル：Lemmy
動画：YouTube, Vimeo, Bilibili
など...
A: 有効にした検索エンジンに依存します。デフォルト設定には主要な検索エンジンが含まれており、品質は良好です。調整が必要な場合は searxng/config/settings.yml を編集してください。
コミュニティからの貢献を歓迎します！以下のように協力いただけます：
Fork 本リポジトリ
機能ブランチを作成（git checkout -b feature/amazing-feature）
変更をコミット（git commit -m 'Add amazing feature'）
ブランチにプッシュ（git push origin feature/amazing-feature）
Pull Request を作成
検索エンジン設定の改善
MCP サーバーへの新機能追加
バグや問題の報告
新機能の提案
ドキュメントの改善
フィードバックの共有
インストールガイド - 詳細なインストール手順
SearXNG ドキュメント - SearXNG 公式ドキュメント
MCP 仕様 - モデルコンテキストプロトコル
Wuxing Codes ブログ - 最新の更新とチュートリアル
GitHub Issues - 問題の報告
GitHub Discussions - 質問
MIT License - 詳細は LICENSE ファイルを参照してください。
オープンソースプロジェクト SearXNG をベースに構築
Claude Code コミュニティのために作成
Wuxing Codes エコシステムの一部
Wuxing チームが ❤️ を込めて作成
⭐ GitHub でスターを付けてください —— 私たちの大きな励みになります！
获取搜索服务器信息，包括服务状态、版本等。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information (implying read-only behavior) and lists examples of what information is included (service status, version). However, it doesn't disclose important behavioral traits like whether this requires authentication, has rate limits, returns structured or unstructured data, or has any side effects. For a tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that states the purpose and provides examples of what information is included. There's no wasted language or unnecessary elaboration. While it could be slightly more structured by separating purpose from examples, it's appropriately sized for a simple tool.
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 simplicity (no parameters, no output schema, no annotations), the description provides adequate coverage of what the tool does. It explains the purpose and gives examples of returned information. However, without annotations or output schema, it should ideally provide more behavioral context (like authentication requirements or response format) to be fully complete. The description is minimally viable but has clear gaps in behavioral transparency.
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 tool has zero parameters, and schema description coverage is 100% (empty schema is fully documented). With no parameters to explain, the description appropriately doesn't discuss parameters. It focuses on what information is retrieved rather than how to call the tool, which is correct for a parameterless tool. The baseline for zero parameters with high schema coverage is 4.
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 as '获取搜索服务器信息，包括服务状态、版本等' (Get search server information, including service status, version, etc.), which specifies the verb ('获取' - get) and resource ('搜索服务器信息' - search server information). It distinguishes from the sibling tool 'web_search' by focusing on server metadata rather than performing searches. However, it doesn't explicitly differentiate from potential other server-related tools beyond the single sibling.
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. It doesn't mention the sibling tool 'web_search' or explain that this is for server diagnostics while 'web_search' is for content retrieval. There's no context about prerequisites, timing, or use cases beyond the basic purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行网页搜索，返回搜索结果列表。
用途：
搜索技术文档、教程、博客等内容
用于课程开发时收集参考资料
支持任意关键词搜索
参数说明：
query: 搜索关键词（必需）
max_results: 返回结果数量，默认 20，最大 100
category: 搜索类别，可选值：general, images, videos, files, it, map, music, science, social, news
language: 搜索语言，默认 zh-CN
time_range: 时间范围，可选值：day, week, month, year, none（默认）
safesearch: 安全搜索级别，可选值：0, 1, 2（默认 1）
返回格式：
title: 结果标题
url: 结果链接
content: 结果摘要
engine: 搜索引擎来源
score: 相关性评分
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词 | |
| max_results | No | 返回结果数量（1-100） | |
| category | No | 搜索类别 | general |
| language | No | 搜索语言代码（如：zh、en、all） | all |
| time_range | No | 时间范围 | none |
| safesearch | No | 安全搜索级别（0=关闭, 1=中等, 2=严格） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return format (title, url, content, engine, score) which is valuable, but doesn't mention important behavioral aspects like rate limits, authentication requirements, pagination behavior, or whether this is a read-only operation. The description adequately covers what the tool does but lacks operational 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 well-structured with clear sections (用途, 参数说明, 返回格式) and every sentence earns its place. It's appropriately sized for a 6-parameter tool with no annotations, providing necessary information without redundancy. The information is front-loaded with the core purpose stated first.
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 search tool with 6 parameters, no annotations, and no output schema, the description does a good job covering the essentials. It explains the tool's purpose, provides usage examples, documents all parameters with their semantics, and describes the return format. The main gap is the lack of behavioral constraints (rate limits, authentication, etc.) that would be important for production 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?
With 100% schema description coverage, the baseline is 3. The description adds meaningful context by explaining the purpose of each parameter beyond what's in the schema (e.g., '用于课程开发时收集参考资料' provides context for the query parameter, and the category parameter explanation gives practical use cases). However, it doesn't provide examples or edge case guidance that would elevate it to a 5.
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 a specific verb ('执行网页搜索' - perform web search) and resource ('搜索结果列表' - search results list). It distinguishes this general web search tool from the only sibling tool (get_server_info) by focusing on external content discovery rather than server information retrieval.
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 usage contexts with three specific examples (searching technical documentation/tutorials/blogs, collecting reference materials for course development, and supporting arbitrary keyword searches). However, it doesn't explicitly state when NOT to use this tool or mention alternatives for different types of searches beyond the category parameter.
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.0get_server_infoweb_searchScored across 2 tools
The two tools have completely distinct purposes: get_server_info retrieves server metadata, while web_search performs actual web searches. There is no overlap or ambiguity between them, making it easy for an agent to select the correct tool based on the task.
Both tools follow a consistent verb_noun naming pattern (get_server_info and web_search). The naming is clear, predictable, and adheres to the same convention throughout, with no mixing of styles or deviations.
With only 2 tools, the server feels under-scoped for its stated purpose of supporting web search for tasks like collecting references for course development. While the tools are functional, the count is too low to provide comprehensive coverage, lacking operations like advanced search filtering or result management.
The server covers basic search functionality with web_search and server status with get_server_info, but there are notable gaps. For example, it lacks tools for saving, organizing, or analyzing search results, which would be useful for the described use cases like course development. The surface is functional but incomplete for sustained workflows.
Web search for AI agents — one tool across 6 engines, routed to the cheapest + cached.
The best web search for your AI Agent
Agent-native search engine with live web research optimized for AI agents.
Google, Bing, DuckDuckGo and Google Maps search results, free without an API key.