MCP

MCP Gateway 사용 전 가이드: 여러 MCP 서버와 REST API를 고정 도구 표면으로 묶기(비상업 라이선스)

여러 MCP 서버와 REST API의 도구 정의로 컨텍스트가 채워지는 상황에 가장 적합합니다. 단일 Rust 바이너리가 모든 백엔드를 14~16개의 고정 메타 도구로 묶고, gateway_search_tools로 검색하고 gateway_invoke로 호출합니다. 사용 전 가장 중요한 전제는 기본 라이선스가 개인과 비상업 용도만 포함하며 상업 운영에는 상업 라이선스가 필요하다는 점입니다.

Official source · GitHub - MikkoParkkola/mcp-gateway

Install

brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run

여러 MCP 서버와 REST API를 같은 AI 클라이언트에 연결하면, 도구 정의 자체가 컨텍스트를 가득 채운다는 사실을 금세 알게 됩니다. MCP Gateway의 접근 방식은 클라이언트와 모든 도구 사이에 단일 Rust 바이너리를 두는 것입니다. 여러 백엔드를 그 뒤에 붙이면, 에이전트에게 보이는 것은 각 백엔드의 전체 정의가 아니라 14~16개 도구로 이루어진 컴팩트한 메타 표면입니다. 컨텍스트 속 도구 정의가 많아질수록 실제 작업에 남는 예산은 줄어듭니다. 이를 하나의 고정된 작은 표면으로 수렴시키는 것이 바로 이 프로젝트가 해결하려는 문제입니다. 시작하기 전에 전제 하나를 확인하세요. 기본적으로 비상업 라이선스로 제공되며, 개인 및 비상업 용도(전체 게이트웨이 실행 포함)는 무료이고, 상업 운영에는 상업 라이선스가 필요합니다.

누구에게 적합한가

  • 이미 여러 MCP 서버와 REST API를 연결했거나 연결을 계획 중이면서 도구 목록 크기를 안정적으로 유지하고 싶은 사용자에게 적합합니다. 뒤에 백엔드를 몇 개 붙이든, 에이전트가 마주하는 것은 고정된 소수의 메타 도구이지 모든 백엔드 정의의 합이 아닙니다.
  • 자신의 머신에서 상시 서비스를 하나 돌릴 수 있는 사람에게 적합합니다. 게이트웨이는 로컬 HTTP 서비스로 실행되며, 클라이언트는 로컬 엔드포인트를 통해 연결합니다.
  • 상업 환경에서 바로 사용하기에는 부적합합니다. 상업 운영에는 상업 라이선스가 필요하며, 이는 채택 전에 반드시 해결해야 할 전제입니다. 범용 빌딩 블록으로 이루어진 작은 MIT 코어만 MIT 라이선스로 공개되어 있습니다.
  • 백엔드가 적고 도구 목록이 원래 짧다면 집계의 가치는 제한적입니다. 소규모 시나리오에서의 구체적 이득에 대해서는 근거가 비교 데이터를 제공하지 않습니다.
  • 지원 클라이언트 목록, 원격 배포, 인증 방식은 근거에 제시되지 않은 미확인 항목이므로 임의로 가정하지 마십시오.

3분 만에 첫 시도 끝내기

  • 전제: Homebrew를 사용할 수 있는 환경. 공식 설치 경로는 Homebrew tap이며, 다른 설치 방식은 근거에 없습니다.
  • 공식 메인 경로의 세 가지 명령을 순서대로 실행합니다:
brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run
  • 2단계의 setup wizard는 기존 서버를 가져와 클라이언트를 연결해 줍니다. 주의할 점은 이것이 로컬 상태에 대한 쓰기라는 사실입니다. 게이트웨이와 클라이언트의 로컬 설정을 다시 쓰는 읽기 전용이 아닌 작업이며, 어떤 파일에 무엇을 어떻게 저장하는지는 근거에 항목별 설명이 없습니다.
  • 3단계를 실행하면 게이트웨이는 로컬 HTTP 서비스로 동작합니다. 클라이언트 쪽은 공식이 제공한 설정 스니펫대로 연결합니다. 스니펫은 gateway라는 이름의 서비스를 http 타입으로 선언하고, 로컬 39400 포트의 /mcp 경로를 가리킵니다:
{
  "mcpServers": {
    "gateway": {
      "type": "http",
      "url": "http://localhost:39400/mcp"
    }
  }
}
  • 성공 신호: 클라이언트가 http://localhost:39400/mcp 에 연결되면 도구 목록이 고정된 소규모 집합으로 수렴합니다. 이때 gateway_search_tools를 한 번 호출해 보세요. 공식 설명에 따르면 백엔드 도구를 검색하는 도구입니다. 연결한 백엔드의 도구가 검색 결과로 돌아오면 클라이언트에서 게이트웨이로 가는 경로가 연결된 것입니다. 이 도구에 readOnlyHint 표시가 있는지는 근거에 명시되지 않아 읽기 전용 여부는 미확인입니다. 첫 시도는 검색만 수행하고 쓰기 유형 작업은 실행하지 마세요. 이 시점에 에이전트가 로드하는 것은 모든 백엔드 정의가 아니라 고정된 소수의 메타 도구입니다.

사용 사례

  • 사례 1: 다중 서버 도구 스택 다이어트. 상황: 클라이언트에 여러 MCP 서버가 연결되어 있고 각 백엔드의 도구 정의가 컨텍스트를 소모합니다. 방법: 기존 서버를 마법사로 가져오게 하고, 클라이언트에는 http://localhost:39400/mcp 이 하나의 엔드포인트로 남기만 합니다. 예상: 에이전트의 도구 표면은 14~16개 수준으로 고정되고 모든 백엔드 정의의 합이 아닙니다. 특정 기능이 필요하면 먼저 gateway_search_tools로 검색해 위치를 찾습니다. 판단 기준: 클라이언트에 표시되는 도구 수가 연결한 백엔드의 도구 총수보다 명확히 적은지 여부.
  • 사례 2: 검색 후 실제 도구를 한 번 호출. 상황: 연결된 백엔드(MCP 서버 또는 REST API)가 제공하는 기능을 실행하고 싶습니다. 방법: 먼저 gateway_search_tools로 대상 도구를 찾고, 이어서 gateway_invoke로 호출합니다. 공식이 설명하는 사용법은 바로 검색과 호출이라는 두 메타 도구입니다. 예상: 호출은 해당 백엔드로 전달되어 그 결과를 반환합니다. 구체적인 출력은 어떤 백엔드를 연결했는지에 따라 달라지며, 근거에는 고정된 예시 출력이 없습니다. 검색에서 예상한 도구가 나오지 않으면 해당 백엔드가 마법사로 가져와졌는지 먼저 확인하고 검색을 다시 시도하세요.

사용 경계

  • 라이선스와 제한: 개인 및 비상업 용도는 무료이며 전체 게이트웨이 실행도 포함됩니다. 상업 운영에는 상업 라이선스가 필요하고, 범용 빌딩 블록으로 이루어진 작은 MIT 코어만 MIT로 공개됩니다. 이 항목이 사용 가능 여부와 범위를 결정하므로 모든 판단에 앞서 둡니다.
  • 읽기/쓰기 성격과 부작용: 게이트웨이 자체는 로컬 상주 서비스입니다. 마법사는 로컬 설정을 쓰고, gateway_invoke는 백엔드 도구를 실제로 구동합니다. 부작용은 호출된 백엔드에 따라 달라지므로 실행 전에 대상 작업의 성격과 확인 지점을 확인하세요.
  • 의존성: 설치는 Homebrew에 의존합니다. 기존 서버 연결은 마법사 가져오기로 수행됩니다.
  • 미확인 항목: 지원 클라이언트 목록, REST API 연결을 위한 구체적 설정 형식, localhost 외부로의 배포 방식, 인증 메커니즘, 그리고 각 메타 도구가 readOnlyHint를 표시하는지 여부는 근거에 모두 명시되지 않았습니다. 게이트웨이 자체의 접근 제어 유무와 로그 기록 방식도 마찬가지로 명시되지 않았습니다. 설명을 찾지 못했다고 위험이 없는 것은 아닙니다. 채택 전에는 공식 저장소의 현재 문서를 기준으로 삼으세요.