MCPの特長 ゲートウェイは、複数のモデルコンテキストプロトコル(MCP)サーバーを単一のゲートウェイに接続し、接続されたサーバーからすべてのツールを統一された検索、説明、および呼び出されたインタフェースを介してすべてを公開し、唯一の5つのツールを公開するサーバー集計ツールです。

コンテキスト制限の問題

クライアント(Claude Code、Opencodeなど)を複数のMCPサーバーに接続すると、各サーバーはすべてのツールをリストします。 10 + MCP で 10-50 ツールを露出します。, 簡単にシステム プロンプトで 500 + ツールの説明を超えることができます。:

これは2つの問題を作成します。

1. コンテキストオーバーフロー: どんな会話が起こる前に、多くのLMがコンテキスト制限を打つ 2.認知過負荷:LLMは何百ものオプションから正しいツールを選ぶのに苦労します

ゲートウェイソリューション

MCPの特長 Gateway は、すべてのツールスキーマをダンプするのではなく、tool search を提供することでこれを解決します。

使い方

MCPの特長 ゲートウェイは、MCP クライアント (上流サーバーに接続) と MCP サーバー (下流クライアントにツールを公開) の両方で動作します。

1. ゲートウェイが起動し、設定を読み込む 2。 設定された上流サーバーごとに、ゲートウェイはstdio(ローカル)またはHTTP/WebSocket(リモート)を介して接続します。
2. ゲートウェイは、各サーバーからツールカタログを取得

MCP Gateway

MCP Gateway is a server aggregation tool that connects multiple Model Context Protocol (MCP) servers into a single gateway, exposing all tools from connected servers through unified search, describe, and invoke interfaces and it exposes only 5 tools.

The Context Limit Problem

When connecting an client (Claude Code, Opencode, etc.) to multiple MCP servers, each server lists all its tools. With 10+ MCPs each exposing 10-50 tools, you can easily exceed 500+ tool descriptions in the system prompt:

10 servers × 20 tools each = 200+ tool descriptions
Each tool: 200-500 chars → 40KB-100KB of description just for tool schemas!

This creates two problems:

1. Context overflow: Many LLMs hit their context limit before any conversation happens
2. Cognitive overload: LLMs struggle to choose the right tool from hundreds of options

The Gateway Solution

MCP Gateway solves this by providing tool search instead of dumping all tool schemas:

┌─────────────┐    gateway.search    ┌─────────────────┐    kubernetes::pods_list    ┌──────────────────┐
│  AI Client  │ ───────────────────► │   MCP Gateway   │ ─────────────────────────►  │  Kubernetes MCP  │
│             │                      │                 │                             │                  │
│             │ ◄────────────────────│                 │ ◄─────────────────────────  │                  │
└─────────────┘   pods_list schema   └─────────────────┘         pods output         └──────────────────┘

How It Works

MCP Gateway operates as both an MCP client (connecting to upstream servers) and an MCP server (exposing tools to downstream clients):

┌──────────────┐      MCP       ┌─────────────────┐      MCP       ┌──────────────────┐
│  AI Client   │ ◄────────────  │   MCP Gateway   │ ◄────────────  │  Upstream Server │
│ (Claude, etc)│                │  (this gateway) │                │  (playwright,    │
└──────────────┘                └─────────────────┘                │   kubernetes...) │
                                                                   └──────────────────┘

1. Gateway starts and reads configuration
2. For each configured upstream server, Gateway connects via stdio (local) or HTTP/WebSocket (remote)
3. Gateway fetches the tool catalog from each server
4. All tools are indexed in a unified catalog with search capabilities
5. AI clients connect to Gateway and use gateway.search to find relevant tools
6. Only the tools the client actually needs are invoked