Shared MCP Gateway
Shared MCP Gateway
複数の共有型MCPサーバーを1つのHTTPゲートウェイに集約し、安定した観測可能で再利用可能なMCPアクセス層を外部に提供します。これにより、Codex、OpenCode、Claude Code、OpenClawなどのクライアントで共通利用が可能になります。
プロジェクトが解決する課題
複数のクライアントやMCPサーバーを並行して使用するシナリオでは、通常以下のような問題が発生します。
各クライアントで個別にMCP設定を管理する必要があり、重複作業が多い。
同じツールチェーンでもクライアントごとに設定が異なり、「このクライアントでは使えるが、あちらでは使えない」といった問題が発生しやすい。
下流のMCPサーバーで異常が発生した際、調査窓口が分散しており、ログの一元管理、自己診断、サーキットブレーカー処理が困難。
MCPサーバーの追加や入れ替えのたびに複数の設定ファイルを修正する必要があり、変更コストが高い。
shared-mcp-gateway の目的は、これらの共有機能を一元管理することです。
レジストリの一元管理:
registry.toml/registry.compose.tomlを通じて下流のMCPを一元管理。機能の一元公開:1つのHTTP MCPエンドポイントを通じて複数の下流サービスを集約。
運用管理の一元化:ヘルスチェック、構造化ログ、障害隔離、最小限のサーキットブレーカーを統合。
クライアント設定の自動生成:Codex / OpenCode / OpenClaw 用の接続設定スニペットを自動生成。
Related MCP server: MCPHubs
プロジェクトでできること
本プロジェクトは現在以下をサポートしています:
複数のstdioベースの下流MCPサーバーの集約。
下流ツールを
namespace.tool_name形式で統一的に公開。クライアントごとに
caller識別子を自動付与し、ログ追跡を容易化。/healthzヘルスチェックインターフェースを提供し、接続済みサービス、失敗サービス、サーキットブレーカーの状態を確認可能。構造化された
logfmtログを提供し、grep、CLS、Lokiなどのシステムでの検索を容易化。下流で異常が発生した際に最小限の隔離を行い、単一のMCPサーバーの停止が全体に影響するのを防止。
クライアント設定ファイルの生成:
Codex:
generated/codex-mcp.tomlOpenCode:
generated/opencode-mcp.jsoncOpenClaw:
generated/openclaw-mcp.json
scripts/self_check.pyを通じた接続性、自己診断ツール、主要機能の生存確認。
適用シナリオ
以下のようなシナリオでの利用に適しています:
同一のMCP機能を複数のAIクライアントで再利用したい場合。
「共有機能」と「ホスト固有の特殊機能」を階層的に管理したい場合。
ログ、自己診断、ヘルスチェック、障害隔離を一元化したい場合。
新しい共有MCPを追加する際に、レジストリ設定を1箇所修正するだけで済ませたい場合。
プロジェクト構造
shared-mcp-gateway/
├── Dockerfile # 网关镜像构建文件
├── docker-compose.yml # 当前本地落地用 Compose 编排
├── registry.toml # 宿主机直跑配置
├── registry.compose.toml # 容器内运行配置
├── requirements.txt # Python 依赖
├── docs/
│ └── mcp-topology.md # 哪些 MCP 进入网关、哪些保留本地特例
├── generated/ # 自动生成的客户端配置文件
├── templates/ # 可复制的配置模板
│ ├── docker-compose.template.yml # Compose 配置模板
│ ├── registry.compose.template.toml # 容器内注册表模板
│ └── registry.template.toml # 宿主机注册表模板
├── scripts/
│ ├── render_client_configs.py # 生成客户端配置片段
│ └── self_check.py # 健康检查与关键工具自检
├── shared_mcp_gateway/
│ ├── config.py # 注册表解析
│ ├── gateway.py # HTTP MCP 聚合网关主程序
│ ├── logging_utils.py # 结构化日志输出
│ ├── render.py # 客户端配置渲染
│ └── stdio_bridge.py # stdio 客户端到 HTTP MCP 的桥接コアとなる仕組み
flowchart LR
A["Codex / OpenCode / OpenClaw"] --> B["stdio_bridge / HTTP Client"]
B --> C["Shared MCP Gateway"]
C --> D["mempalace"]
C --> E["mysql-db"]
C --> F["obsidian-kb"]
C --> G["tencent-cls"]実行フローの説明
MCPリクエストが共有ゲートウェイに入った後の主要なパスは以下の通りです:
クライアントが
stdio_bridge.pyを経由、または直接HTTPで共有ゲートウェイにアクセス。RequestLoggingMiddlewareがcaller、request_id、アクセスログのコンテキストを注入。SharedMcpGatewayがツール名 / リソースURI / プロンプト名に基づいてターゲットの下流サービスを特定。対象の下流サービスがサーキットブレーカー状態であれば、リクエストは即座に拒否され、異常サービスへの継続的な負荷を回避。
転送が許可される場合、リクエストは
DownstreamConnectionに入り、単一セッションロックを通じて下流のMCPにシリアルアクセス。呼び出し完了後、メトリクス、失敗回数、サーキットブレーカーを更新し、heartbeat / healthz に同期。
主要モジュールの役割は以下の通りです:
shared_mcp_gateway/config.py:レジストリの解析と型安全な設定オブジェクト。shared_mcp_gateway/gateway.py:統合インデックス、リクエスト転送、サーキットブレーカー、ヘルスチェック、ハートビートログ。shared_mcp_gateway/stdio_bridge.py:stdioのみをサポートするクライアント向けにHTTPゲートウェイブリッジ層を提供。shared_mcp_gateway/render.py:統合レジストリを各クライアントの接続設定にレンダリング。scripts/self_check.py:ヘルスインターフェースと実際のMCP呼び出しの両面から接続性を自己診断。
リクエストシーケンス図
以下の図は、コードを読む際に全体像を把握するのに役立ちます:
sequenceDiagram
participant Client as "MCP Client"
participant Bridge as "stdio_bridge / HTTP Client"
participant Middleware as "RequestLoggingMiddleware"
participant Gateway as "SharedMcpGateway"
participant Breaker as "CircuitBreaker"
participant Downstream as "DownstreamConnection"
participant Server as "Downstream MCP Server"
Client->>Bridge: 发起 list_tools / call_tool / read_resource
Bridge->>Middleware: HTTP 请求进入网关
Middleware->>Gateway: 注入 caller / request_id 后转发
Gateway->>Breaker: 检查目标下游是否允许访问
alt breaker open
Breaker-->>Gateway: reject
Gateway-->>Client: 快速失败 / 返回熔断提示
else breaker closed
Gateway->>Downstream: 按 namespace 路由请求
Downstream->>Server: 串行发起 MCP 调用
Server-->>Downstream: 返回结果或异常
Downstream-->>Gateway: 返回标准 MCP 响应
Gateway->>Gateway: 更新 metrics / failure streak / breaker
Gateway-->>Client: 返回聚合后的 MCP 响应
endコードリーディングのヒント
メインフローを素早く理解するには、以下の順序で読むことをお勧めします:
shared_mcp_gateway/config.py:レジストリ構造を理解する。shared_mcp_gateway/render.py:クライアント接続設定がどのように生成されるかを理解する。shared_mcp_gateway/stdio_bridge.py:stdioクライアントがどのようにHTTPゲートウェイに接続するかを理解する。shared_mcp_gateway/gateway.py:SharedMcpGateway、DownstreamConnection、RequestLoggingMiddlewareを重点的に確認する。scripts/self_check.py:デプロイ後に「インターフェースが生きているか」と「実際の機能が利用可能か」を検証する方法を理解する。
クイックスタート
1. 依存関係のインストール
cd /path/to/shared-mcp-gateway
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt2. 設定の準備
テンプレートファイルを直接参考にしてください:
templates/registry.template.tomltemplates/registry.compose.template.tomltemplates/docker-compose.template.yml
最も一般的な手順は以下の通りです:
cp templates/registry.template.toml registry.local.toml
cp templates/registry.compose.template.toml registry.compose.local.toml
cp templates/docker-compose.template.yml docker-compose.local.ymlその後、テンプレート内のパス、ポート、下流サービスのコマンドを実際の環境に合わせて書き換えてください。
3. ローカルでの直接起動
python3 shared_mcp_gateway/gateway.py --registry registry.toml --log-level INFO起動後、デフォルトで以下にアクセス可能です:
MCPエンドポイント:
http://127.0.0.1:8787/mcpヘルスチェック:
http://127.0.0.1:8787/healthz
4. Docker Compose での起動
docker compose up -d --build
docker compose ps
curl http://127.0.0.1:8787/healthz停止:
docker compose down設定方法:コア設定の説明
プロジェクトの主要な設定ファイルは registry.toml で、主に5つのセクションで構成されています:
1. リッスン設定
[listen]
host = "127.0.0.1"
port = 8787
path = "/mcp"意味:
host:ゲートウェイのリッスンアドレスport:ゲートウェイのリッスンポートpath:MCP HTTPパス
2. ゲートウェイメタ情報
[gateway]
name = "shared-gateway"
namespace_separator = "."
description = "Shared MCP gateway for Codex, OpenCode and OpenClaw."意味:
name:外部に公開するゲートウェイ名namespace_separator:名前空間の区切り文字(デフォルトは.)description:ゲートウェイの説明情報
3. 下流MCPサーバー設定
[[servers]]
key = "mysql-db"
enabled = true
namespace = "mysql_db"
command = "/bin/bash"
args = ["-lc", "cd /opt/mcps/mysql-connector && ./.venv/bin/python server.py"]意味:
key:下流サービスのユニーク識別子enabled:有効化するかどうかnamespace:ツール名のプレフィックス名前空間command:起動コマンドargs:起動引数env:オプション、当該サービスに個別に注入する環境変数
4. ローカル例外の説明
[local_exceptions.openclaw]
keep_local = ["openspace"]
reason = "OpenSpace 强依赖宿主上下文,保留本地直连。"
endpoint = "http://127.0.0.1:8081/mcp"共有ゲートウェイを通さず、ローカル直結を維持する機能を記録するために使用します。
5. クライアント設定パスのメタ情報(オプション)
[clients.codex]
config_path = "~/.codex/config.toml"意味:
clients.*は主にターゲットクライアントの設定ファイルの場所を記録するために使用します。本プロジェクトはデフォルトではこれらのパスに自動書き込みを行いません。
scripts/render_client_configs.pyを実行し、生成結果を各クライアントの設定にコピーすることを推奨します。
設定方法:事例
事例 1:ホストマシンでの直接実行設定
以下はそのまま参考にできる最小構成の例です:
[listen]
host = "127.0.0.1"
port = 8787
path = "/mcp"
[gateway]
name = "shared-gateway"
namespace_separator = "."
description = "Shared MCP gateway for local development."
[[servers]]
key = "mempalace"
enabled = true
namespace = "mempalace"
command = "/opt/mempalace/.venv/bin/python"
args = ["-m", "mempalace.mcp_server"]
env = { PYTHONPATH = "/opt/mempalace" }
[[servers]]
key = "mysql-db"
enabled = true
namespace = "mysql_db"
command = "/bin/bash"
args = ["-lc", "cd /opt/mcps/mysql-connector && ./.venv/bin/python server.py"]
[local_exceptions.shared_gateway]
managed = ["mempalace", "mysql_db"]
reason = "共享能力统一由 shared-gateway 纳管。"事例 2:Docker Compose での設定の考え方
コンテナ内でゲートウェイを一元的に実行したい場合は、以下の考え方を参考にしてください:
services:
shared-mcp-gateway:
build:
context: .
dockerfile: Dockerfile
container_name: shared-mcp-gateway
restart: unless-stopped
ports:
- "127.0.0.1:8787:8787"
environment:
OBSIDIAN_VAULT_PATH: /workspace/openclaw-workspace
PYTHONPATH: /workspace/mempalace
volumes:
- /opt/mcps:/workspace/mcps:ro
- /opt/mempalace:/workspace/mempalace:ro
- /opt/openclaw-workspace:/workspace/openclaw-workspace:rw
- /opt/mempalace-data:/root/.mempalace:rw適したケース:
複数のMCPランタイム依存関係を同じコンテナコンテキストにマウントする場合。
読み取り専用マウントを通じて下流コードディレクトリの安定性を確保する場合。
コンテナ内の
registry.compose.tomlを統一して使用する場合。
設定テンプレートファイル
導入を容易にするため、プロジェクトにはコピー可能なテンプレートファイルが用意されています:
1. レジストリテンプレート
ファイル:templates/registry.template.toml
用途:
新環境の初期化時にコピーしてパスを書き換える。
ホストマシンでの直接実行の起点設定として適している。
listen、gateway、servers、clients、local_exceptionsの完全な構造を保持。
推奨される使用方法:
cp templates/registry.template.toml registry.local.toml2. コンテナ内レジストリテンプレート
ファイル:templates/registry.compose.template.toml
用途:
Docker / Compose シナリオ向けに、コンテナ内パスバージョンのレジストリテンプレートを提供。
ホストマシンの絶対パスがコンテナ設定に混入するのを防ぐ。
registry.compose.tomlのコピー元として適している。
推奨される使用方法:
cp templates/registry.compose.template.toml registry.compose.local.toml3. Compose テンプレート
ファイル:templates/docker-compose.template.yml
用途:
新しいマシンや環境でのComposeオーケストレーションの迅速な準備。
本番環境や現在のマシン専用の
docker-compose.ymlを直接修正するのを避ける。マウントパスや環境変数をチームの規約に合わせて変更しやすくする。
推奨される使用方法:
cp templates/docker-compose.template.yml docker-compose.local.ymlクライアント接続例
推奨される接続フロー:
まず shared-gateway を起動し、
http://127.0.0.1:8787/healthzが正常であることを確認する。python3 scripts/render_client_configs.pyを実行し、現在の環境用のクライアント設定スニペットを生成する。generated/ディレクトリ内の実際の生成物を優先的にコピーし、環境依存のパスを手書きしない。
Codex 接続例
generated/codex-mcp.toml を直接使用することを推奨します。構造は概ね以下の通りです:
[mcp_servers.shared-gateway]
command = "/bin/bash"
args = ["-lc", "python3 /absolute/path/to/shared_mcp_gateway/stdio_bridge.py --url http://127.0.0.1:8787/mcp --caller codex"]
enabled = trueOpenCode 接続例
generated/opencode-mcp.jsonc を直接使用することを推奨します。構造は概ね以下の通りです:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"shared-gateway": {
"type": "local",
"enabled": true,
"command": [
"/bin/bash",
"-lc",
"python3 /absolute/path/to/shared_mcp_gateway/stdio_bridge.py --url http://127.0.0.1:8787/mcp --caller opencode"
]
}
}
}OpenClaw 接続例
OpenClaw は直接HTTP MCPを利用可能です。generated/openclaw-mcp.json の使用を推奨します:
{
"mcpServers": {
"shared-gateway": {
"url": "http://127.0.0.1:8787/mcp",
"transport": "streamable-http",
"connectionTimeoutMs": 10000,
"disabled": false
}
}
}Claude Code 接続の考え方
本プロジェクトは stdio_bridge.py を通じて claude-code に呼び出し元識別子を注入することをサポートしています。基本的な考え方は、ブリッジをローカルのstdio MCPコマンドとして使用することです:
python3 /absolute/path/to/shared_mcp_gateway/stdio_bridge.py --url http://127.0.0.1:8787/mcp --caller claude-codeクライアントの設定体系がカスタムstdio MCPコマンドを許可している場合、このブリッジコマンドをそのまま再利用できます。
設定導入のヒント
環境問題を減らすため、以下の順序で導入することをお勧めします:
テンプレートファイルをコピーし、プロジェクト内の既存サンプルを直接修正しない。
各下流MCPサーバーが個別に起動できることを確認する。
下流サービスを1つずつ
registry.tomlまたはregistry.compose.tomlに書き込む。ゲートウェイ起動後、
/healthzを確認し、scripts/self_check.pyを実行する。最後に
scripts/render_client_configs.pyを実行し、クライアント接続設定を同期する。
以下の3種類のファイルを使い分けることを推奨します:
registry.toml:ホストマシン直接実行用設定registry.compose.toml:コンテナ内実行用設定templates/*.template.*:新環境初期化用テンプレート
よく使うコマンド
クライアント設定の生成
python3 scripts/render_client_configs.pyこのスクリプトは以下を行います:
registry.tomlを読み込むCodex / OpenCode / OpenClaw の設定スニペットを一括生成する
ブリッジ起動コマンドを手動コピーする際の設定ドリフトを防ぐ
生成結果は以下に保存されます:
generated/codex-mcp.tomlgenerated/opencode-mcp.jsoncgenerated/openclaw-mcp.json
ヘルスチェックの実行
python3 scripts/self_check.py
python3 scripts/self_check.py --jsonデフォルトで2種類のチェックを実行します:
healthz:ゲートウェイが正常に公開されているか、下流が欠落していないか、サーキットブレーカーが開いていないかを確認。gateway_tools:MCPクライアントとしてゲートウェイに接続し、主要ツールが存在するかを確認し、副作用のない生存確認を実行。
ログの確認
docker compose logs -f shared-mcp-gateway現在接続されている共有型MCP
mempalacemysql-dbobsidian-kbtencent-cls
トポロジーの詳細は /path/to/shared-mcp-gateway/docs/mcp-topology.md を参照してください。
今後の推奨事項
本プロジェクトをさらに拡張する場合は、以下の順序で進めることをお勧めします:
registry.tomlに新しい[[servers]]を追加する。そのMCPが単独で起動できるかをローカルで検証する。
ゲートウェイ起動後に
/healthzを確認する。scripts/self_check.pyを実行し、主要機能が正常か確認する。scripts/render_client_configs.pyを再実行し、クライアント設定を同期する。
本プロジェクトでドキュメント、テンプレート、またはデフォルト設定を継続的にメンテナンスする場合は、以下を優先してください:
README.mdtemplates/registry.template.tomltemplates/registry.compose.template.tomltemplates/docker-compose.template.ymldocs/mcp-topology.md
This server cannot be installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Servers
- AlicenseNot gradedqualityNot gradedmaintenanceA unified gateway and dashboard that aggregates multiple MCP servers into a single endpoint for streamlined management by AI clients. It features a centralized YAML configuration, a web-based monitoring dashboard, and hot-reload support for managing filesystem, GitHub, and database tools.
- AlicenseNot gradedqualityCmaintenanceA unified gateway and web dashboard that aggregates multiple MCP servers into a single Streamable HTTP endpoint. It supports stdio, SSE, and HTTP protocols, featuring optimized tool exposure modes to reduce token consumption for AI clients.5MIT
- AlicenseNot gradedqualityDmaintenanceMCPGate aggregates multiple MCP servers into a single unified endpoint, enabling centralized tool management with granular filtering, automatic namespacing, and observability. Features a real-time web dashboard and optional PostgreSQL-backed audit trails for monitoring and controlling AI tool access across local and remote deployments.17Apache 2.0
- AlicenseNot gradedqualityCmaintenanceA universal MCP server that acts as a unified gateway for dynamically connecting and managing multiple MCP servers via a single HTTP endpoint.106MIT
Related MCP Connectors
MCP Hub: AI service discovery, per-user OAuth, and multi-service workflow orchestration
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xfn-jjw/shared-mcp-gateway'
If you have feedback or need assistance with the MCP directory API, please join our Discord server