사이트맵 Gateway는 여러 Model Context Protocol (MCP) 서버를 단일 게이트웨이에 연결하는 서버 집계 도구이며, 통합 검색, 기술 및 인터페이스를 통해 연결된 서버에서 모든 도구를 탐험하고 5 도구 만 노출합니다.

Context Limit 문제

클라이언트 (Claude Code, Opencode 등)를 여러 MCP 서버에 연결하면 각 서버는 모든 도구를 나열합니다. 10+ MCPs로 각 exposing 10-50 공구, 당신은 쉽게 체계 신속한에 있는 500+ 공구 묘사를 초과할 수 있습니다:

이 두 문제를 만듭니다:

1. ** 텍스트 과잉 **: 많은 LLMs는 어떤 대화의 앞에 그들의 상황에 한계를 명중합니다
2. **인지 과부하 **: LLMs는 선택권의 수백에서 적당한 공구를 선택하는 투쟁

게이트웨이 솔루션

사이트맵 Gateway는 모든 도구 스키마를 덤프 대신 tool search를 제공함으로써 이것을 해결합니다.

그것이 작동하는 방법

사이트맵 Gateway는 MCP 클라이언트(업스트림 서버 연결)과 MCP 서버(업스트림 클라이언트에 대한 도구 제공)로 동작합니다.

1. Gateway 시작 및 설정 읽기
2. 각 구성된 상류 서버를 위해, 게이트웨이는 stdio (local) 또는 HTTP/WebSocket (remote)를 통해 연결합니다
3. Gateway는 각 서버에서 도구 카탈로그를 fetches
4. 명세.

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