SearXNG MCPサーバー

SearXNGインスタンスと統合することでWeb検索機能を提供するModel Context Protocol (MCP) サーバーです。

機能

• Web検索: 複数のエンジンを横断した強力な集約検索を実行します。

• ディスカバリー: 利用可能なカテゴリやエンジンをプログラムで取得します。

• ステートレスHTTP: 標準的なJSON-RPCクライアントと互換性があります。

• 柔軟な設定: 環境変数およびコマンドライン引数をサポートしています。

Related MCP server: SearXNG MCP Server

SearXNGとMCPサーバーを実行するためのcompose.ymlの例

services:
 searxng:
 image: searxng/searxng:latest
 ports:
 - 8080:8080
 volumes:
 - ./searxng/etc/:/etc/searxng/
 - ./searxng/data/:/var/cache/searxng/
 restart: always

 searxng-mcp:
 image: ghcr.io/aicrafted/searxng-mcp:latest
 restart: unless-stopped
 depends_on:
 # Ensure SearXNG starts before the MCP server
 - searxng
 environment:
 SEARXNG_URL: http://searxng:8080
 MCP_HOST: 0.0.0.0
 MCP_PORT: 32123
 MCP_TRANSPORT: "http"
 ports:
 - "32123:32123"

MCPクライアント設定

HTTPトランスポート (推奨)

{
 "mcpServers": {
 "searxng": {
 "type": "http",
 "url": "http://localhost:32123/mcp"
 }
 }
}

SSEトランスポート

{
 "mcpServers": {
 "searxng": {
 "type": "sse",
 "url": "http://localhost:32123/sse"
 }
 }
}

注: SSEトランスポートは /mcp ではなく /sse エンドポイントを使用します。HTTPトランスポートは /mcp を使用します。

ソースから実行するための前提条件

• Python 3.10以上

• 実行中の SearXNG インスタンス

インストール

1. リポジトリをクローンし、ディレクトリに移動します。

2. 依存関係をインストールします:

   pip install -r requirements.txt

3. .env ファイルを設定します (オプション):

   SEARXNG_URL=http://your-searxng-instance:8080
   MCP_PORT=32123
   MCP_HOST=127.0.0.1

使用方法

uv または標準のpythonを使用してサーバーを実行します:

python searxng_mcp.py --transport http --port 32123 --searxng http://searx.lan

Dockerでの実行

1. イメージのビルド:

   docker build -t searxng-mcp .

2. コンテナの実行:

   docker run -d \
    -p 32123:32123 \
    -e SEARXNG_URL=http://your-searxng-instance:8080 \
    --name searxng-mcp \
    searxng-mcp

トランスポートオプション

• stdio: 標準入出力 (一部のMCPクライアントのデフォルト)。

• http: ステートレスHTTP (streamable-http)。

• sse: Server-Sent Events。

検索機能ガイド

SearXNGはさまざまなソースから結果を集約します。このガイドでは、web_search ツールを通じて利用可能な機能の概要を説明します。

検索カテゴリ

カテゴリは、コンテンツタイプによって検索を絞り込むのに役立ちます。これらは categories パラメータで使用します (カンマ区切り)。

サポートされているエンジン

SearXNGは130以上のエンジンをクエリできます。設定済みのエンジンには通常以下が含まれます:

• Web: Google, Brave, DuckDuckGo, Qwant, Startpage

• 知識: Wikipedia, Wikidata

• 開発: GitHub, StackOverflow, PyPI

• ソーシャル: Reddit, Twitter/X

高度な検索パラメータ

• categories: 特定のタイプでフィルタリングします (例: news,it)。

• engines: 特定のエンジンを強制します (例: google,wikipedia)。

• language: 検索言語を指定します (例: en, es, fr)。

• pageno: 複数の検索結果ページを移動します。

• time_range: 日付でフィルタリングします (day, month, year)。

• safesearch: コンテンツフィルタリングを制御します (0=なし, 1=中程度, 2=厳格)。

プログラムによるディスカバリー

web_search_info ツールを使用して、インスタンスで有効になっているカテゴリとエンジンのリストを動的に取得します。

Windowsのトラブルシューティング

Dockerコンテナ実行中にlocalhostに到達できない

症状: http://localhost:<port>/ が接続拒否を返すか、誤ったサービスにヒットするが、コンテナ内からの curl は正常に動作する。

根本原因: WSL2ポートリレーのゴースト

WSL2は、wslrelay.exe を使用してLinux VMからWindowsホストへ自動的にポートを転送します。WSL内のプロセスがポートをリッスンすると、WSLはWindows側で [::1]:<port> (IPv6ループバック) にバインドされたリレーを作成します。

そのWSLプロセスが停止しても、wslrelay.exe は ポートを解放しない ことがよくあります。リレーエントリは、[::1]:<port> 上のゾンビリスナーとして生き残ります。

その後、Dockerがコンテナを同じホストポートにマッピングすると、0.0.0.0:<port> に正しくバインドされますが、[::1]:<port> はすでに古いリレーによって占有されています。

Windowsでは、localhost は最初に ::1 (IPv6) に解決されます。そのため、ブラウザやcurlによる localhost:<port> へのリクエストは、Dockerコンテナではなくデッド状態の wslrelay.exe エントリにヒットし、接続エラーや予期しない応答が発生します。

明示的なIPv4アドレス 127.0.0.1:<port> を介して接続すると、リレーをバイパスしてDockerに正しく到達します。

診断方法:

# Check what is listening on the port
netstat -ano | findstr :<port>

# Identify the processes
Get-Process -Id <pid1>,<pid2> | Select-Object Id,Name

同じポートに対して2つのエントリ（1つは com.docker.backend が所有、もう1つは wslrelay が所有）が表示される場合、これが問題です。

回避策:

恒久的な修正:

wsl --shutdown を実行した後、Dockerコンテナを再起動します。リレーは存在しなくなり、WSL内で同じポートが再度使用されるまで localhost:<port> は正常に動作します。

予防策:

WSLとDockerの両方で同じポートでサービスを定期的に実行する場合は、以下のいずれかを推奨します:

• そのサービスには常にDockerを使用し、WSLを直接使用しない

• WSL開発インスタンスとDocker本番インスタンスで異なるポートを使用する

• docker-compose.yml に 127.0.0.1:<port>:<port> の明示的なバインディングを追加してIPv4を強制する

関連情報

• WSL2ネットワーキングドキュメント

• WSL GitHub issueトラッカー: wslrelay port leak で検索

Maintenance

Resources

• GitHub Repository
Need Help?Related Servers