MCP Gateway

​

Co robi MCP gateway

• Jeden endpoint, jeden klucz. Klienty łączą się z https://your-gateway/mcp za pomocą klucza API GoModel. Nigdy nie przechowują danych uwierzytelniających do upstreamowych serwerów MCP; gateway sam dodaje nagłówki każdego serwera.
• Agregacja z przestrzeniami nazw. Narzędzia i prompty ze wszystkich skonfigurowanych serwerów pojawiają się w jednym katalogu jako {slug}_{name} (np. github_create_issue), w stałej, deterministycznej kolejności.
• Wykrywanie zgodne z zasadą najmniejszych uprawnień. Serwer można ograniczyć do user_paths i wykluczyć z niego część ścieżek przez disallowed_user_paths; ukryci wywołujący nie dostają jedynie błędów – narzędzia w ogóle nie pojawiają się w ich tools/list. Filtry allowed_tools / disallowed_tools na poziomie operatora przycinają rozbudowane serwery, dzięki czemu kontekst agenta pozostaje mały.
• Obserwowalność. Każde wywołanie narzędzia staje się wpisem użycia (serwer, narzędzie, czas trwania, rozmiary, flaga błędu, etykiety, ścieżka użytkownika), a requesty MCP pojawiają się w logu audytowym i logu requestów jak każdy inny ruch do modeli – opisane metodą JSON-RPC, a w przypadku wywołań także nazwą narzędzia lub promptu, więc wiersz tools/call pokazuje github_create_issue, a nie samą ścieżkę. Przy LOGGING_LOG_BODIES=true ramki requestu i odpowiedzi JSON-RPC są też zapisywane we wpisie audytowym (łącznie z argumentami i wynikami narzędzi), z takim samym limitem przechwytywania 1 MB jak w innych endpointach. Rate limity i budżety ścieżek użytkowników obejmują także requesty MCP.

​

Podłącz klienta

{
  "mcpServers": {
    "gomodel": {
      "type": "http",
      "url": "https://your-gateway/mcp",
      "headers": {
        "Authorization": "Bearer sk-your-gomodel-key"
      }
    }
  }
}

• /mcp – wszystko, co może zobaczyć ścieżka użytkownika klucza, z przestrzeniami nazw.
• /mcp/{slug} – pojedynczy serwer z oryginalnymi nazwami narzędzi.
• /mcp/{name} – serwer wirtualny: nazwany podzbiór serwerów, z przestrzeniami nazw.
• Nagłówek X-MCP-Servers: github,jira – podzbiór rozdzielony przecinkami na /mcp.

​

Grupuj serwery w serwery wirtualne

mcp:
  virtual_servers:
    coding:
      description: Code review tools
      servers: [github, linear, sentry]
      tool_discovery: search # opcjonalne; domyślnie: mcp.tool_discovery

• Wyłącznie zawęża. Każdy członek zachowuje swoje user_paths i filtry narzędzi, więc klucz, który nie widzi github, nie zobaczy go także przez coding. X-MCP-Servers dodatkowo zawęża serwer wirtualny.
• Nazwy współdzielą /mcp/{name} ze slugami serwerów. Uruchamianie kończy się błędem, jeśli serwer wirtualny w konfiguracji nosi nazwę serwera z konfiguracji, a dashboard odrzuca nowy serwer lub serwer wirtualny, którego nazwa jest już używana przez drugi rodzaj. Jeśli serwer i serwer wirtualny mimo to otrzymają tę samą nazwę (np. konfiguracja dodana po wpisie w dashboardzie), serwer zachowuje URL, a serwer wirtualny nie jest udostępniany; informują o tym log i dashboard.
• Wpisy z konfiguracji wygrywają. Serwer wirtualny zadeklarowany w konfiguracji ukrywa serwer z dashboardu o tej samej nazwie i jest w dashboardzie tylko do odczytu.
• Brakujący członkowie są pomijani. Dashboard oferuje tylko istniejące serwery, ale członek usunięty później lub wskazany w konfiguracji, zanim zaczął istnieć, jest pomijany z ostrzeżeniem i oznaczany na stronie MCP Servers.

​

Wyszukuj narzędzia zamiast je listować

• search_tools przyjmuje słowa kluczowe (lub dokładną nazwę narzędzia) i zwraca pasujące narzędzia z ich opisami i schematami wejścia.
• call_tool uruchamia znalezione narzędzie po name z jego arguments.

mcp:
  tool_discovery: search # env: MCP_TOOL_DISCOVERY; domyślnie: off

{
  "mcpServers": {
    "gomodel": {
      "type": "http",
      "url": "https://your-gateway/mcp",
      "headers": {
        "Authorization": "Bearer sk-your-gomodel-key",
        "X-MCP-Tool-Discovery": "search"
      }
    }
  }
}

​

Deklaruj serwery

​

Dodaj serwer z dashboardu

• Name – nazwa dla ludzi; możesz ją później zmienić.
• Transport – http (streamable HTTP, domyślnie) lub sse (starszy).
• URL – upstreamowy endpoint MCP.
• Headers – dane uwierzytelniające do upstreamu (np. Authorization: Bearer …); zapisane wartości są potem wyświetlane w zamaskowanej postaci.
• Tools – zaznacz narzędzia, z których mogą korzystać klienty; zobacz Wybierz, które narzędzia udostępnia każdy serwer.
• Opcjonalnie user paths i excluded user paths w sekcji Advanced; zobacz Ogranicz, kto widzi serwer.

• Name jest nazwą dla ludzi, akceptuje Unicode i można ją później edytować.
• Slug jest domyślnie wyprowadzany z nazwy. Składa się z małych liter ASCII, cyfr, myślników i podkreśleń i można go dostosować podczas tworzenia serwera. Po utworzeniu staje się niezmienny, ponieważ jest używany w /mcp/{slug}, X-MCP-Servers i zagregowanych nazwach narzędzi.

mcp:
  enabled: true # domyślnie; MCP_ENABLED=false wyłącza endpointy
  servers:
    github:
      url: https://api.githubcopilot.com/mcp
      headers:
        Authorization: "Bearer ${GITHUB_PAT}"
      user_paths: ["/engineering"] # opcjonalny zakres widoczności
      disallowed_user_paths: ["/engineering/contractors"] # wyłączenie; wygrywa z user_paths
      disallowed_tools: ["delete_repo"]
    local-files:
      transport: stdio # tylko deklaratywnie; zobacz uwagi dotyczące bezpieczeństwa
      command: npx
      args: ["-y", "@modelcontextprotocol/server-filesystem", "/data"]

MCP_SERVERS='{"github":{"url":"https://api.githubcopilot.com/mcp","headers":{"Authorization":"Bearer ${GITHUB_PAT}"}}}'

​

Uruchamiaj serwery stdio z Dockerem

services:
  mcp-files:
    image: supercorp/supergateway
    command:
      - --stdio
      - npx -y @modelcontextprotocol/server-filesystem /data
      - --outputTransport
      - streamableHttp
      - --port
      - "8000"
    volumes:
      - ./files:/data

  gomodel:
    image: enterpilot/gomodel
    ports: ["8080:8080"]
    environment:
      GOMODEL_MASTER_KEY: change-me
      MCP_SERVERS: '{"files":{"url":"http://mcp-files:8000/mcp"}}'
    depends_on: [mcp-files]

FROM node:22-slim
COPY --from=enterpilot/gomodel /gomodel /gomodel
COPY --from=enterpilot/gomodel /app /app
RUN chown -R node:node /app
USER node
WORKDIR /app
EXPOSE 8080
ENTRYPOINT ["/gomodel"]

​

Stan i cykl życia

​

Wybierz, które narzędzia udostępnia każdy serwer

mcp:
  servers:
    github:
      url: https://api.githubcopilot.com/mcp
      disallowed_tools: ["delete_repository", "merge_pull_request"]

​

Ogranicz, kto widzi serwer

​

Sprawdź katalog serwera

​

Uwagi dotyczące bezpieczeństwa

• Granica danych uwierzytelniających. Specyfikacja MCP zabrania przekazywania tokenów dalej; GoModel kończy obsługę bearer tokena klienta i dodaje dane uwierzytelniające danego serwera z konfiguracji. Klucze klientów nigdy nie docierają do upstreamu, a skonfigurowane nagłówki upstreamu nie są wysyłane przy przekierowaniach między originami.
• Originy przeglądarek są domyślnie blokowane. Klienty MCP nie są stronami internetowymi, więc /mcp odrzuca każdy request zawierający metadane fetch przeglądarki (Origin lub Sec-Fetch-Site), chyba że pochodzi z originu wymienionego w mcp.allowed_origins (MCP_ALLOWED_ORIGINS). Wpisuj wartości tak, jak serializuje je przeglądarka – https://console.example.com, bez końcowego ukośnika, porty domyślne opcjonalne. Origin z allowlisty dostaje całą sesję, łącznie ze strumieniem powiadomień GET, który przeglądarki wysyłają bez nagłówka Origin. To właśnie blokuje DNS rebinding z poziomu przeglądarki: rebinding zmienia tylko adres, na który rozwiązuje się nazwa hosta, więc Origin i Host strony po rebindingu nadal są ze sobą zgodne, a przeglądarka nadal raportuje Sec-Fetch-Site: same-origin – ich porównanie niczego nie dowodzi i tylko jawna allowlista odróżnia Twój origin od originu atakującego. Ustawiaj allowed_origins tylko wtedy, gdy udostępniasz webowego klienta MCP ze znanego originu; "*" ufa każdemu originowi, wyłącza tę ochronę i generuje ostrzeżenie przy starcie.
• stdio tylko deklaratywnie. Serwery stdio uruchamiają podprocesy na hoście gatewaya, więc można je deklarować tylko w config.yaml / MCP_SERVERS. Admin API i dashboard je odrzucają – logowanie do dashboardu nigdy nie może być równoznaczne z wykonaniem kodu na gatewayu.
• Podprocesy stdio dostają minimalne środowisko. Dziedziczone są tylko PATH, HOME, TMPDIR, USER i LANG – nigdy klucze API providerów ani master key gatewaya. Wszystko inne przekaż jawnie przez mapę env: serwera (wartości obsługują ${VAR}).
• Dane uwierzytelniające zarządzane z dashboardu są przechowywane w bazie danych gatewaya. Nagłówki serwerów utworzonych przez administratora są zapisywane w skonfigurowanym backendzie storage (maskowane są tylko w warstwie API/UI). Jeśli Twój model zagrożeń wyklucza sekrety w bazie danych, zadeklaruj te serwery zamiast tego w config.yaml / MCP_SERVERS – referencje ${ENV} utrzymują sekret w środowisku, a serwery deklaratywne nigdy nie trafiają do storage.
• Zdalne URL-e to ruch wychodzący z serwera. Serwery HTTP/SSE zarządzane z dashboardu celowo obsługują endpointy prywatne i loopback. Chroń dostęp do zapisu w panelu administracyjnym i egzekwuj politykę ruchu wychodzącego swojego wdrożenia, aby niezaufani operatorzy nie mogli używać gatewaya do skanowania usług wewnętrznych.
• Sesje to nie uwierzytelnianie. Każdy request jest uwierzytelniany bearer tokenem, a sesja jest dodatkowo powiązana z tożsamością zarządzanego klucza, ścieżką użytkownika i przypiętym endpointem, które ją zainicjowały; przedstawienie wykradzionego ID sesji pod inną tożsamością zwraca 404.
• Wartości nagłówków z sekretami są wyświetlane zamaskowane (***) w Admin API i dashboardzie; zapisanie formularza z *** zachowuje zapisany sekret.

​

Zakres obsługi protokołu