MCP Gateway: po co jest potrzebny między ChatGPT a twoimi usługami

1. Po co w ogóle kolejna warstwa?

Prawie wszyscy zaczynają tak samo: jest jeden serwer MCP, opisuje kilka narzędzi, ChatGPT łączy się z nim bezpośrednio przez HTTPS i wszystko wydaje się świetne. Umowna architektura wygląda tak:

ChatGPT  →  twój serwer MCP  →  baza / zewnętrzne API

Na etapie „pet project” to naprawdę sensowna opcja. Ale gdy tylko aplikacja zaczyna rozrastać się funkcjonalnie, a zespół — powiększać, bardzo szybko wypływają problemy.

Po pierwsze, serwer MCP zamienia się w „God object”. Mieszkają w nim jednocześnie narzędzia do doboru prezentów, checkout, analityka i jeszcze coś z serii „a może wrzućmy tu też raportowanie”. Różne części kodu mają różne SLA i różne wymagania bezpieczeństwa, ale są sklejone w jeden proces.

Po drugie, ChatGPT i inni klienci są zmuszeni znać topologię twoich usług. Jeśli za pół roku pojawi się kolejny serwer MCP dla commerce, będziesz musiał przepiąć klientów, zmienić konfiguracje i opisy. Zamiast „jednego punktu wejścia” dostajesz zoo adresów URL.

Po trzecie, staje się niejasne, gdzie realizować to, co wspólne dla wszystkich usług: uwierzytelnianie, logowanie, metryki, rate limiting, weryfikację tokenów, lokalizację i routing po regionach. Jeśli rozrzucisz to po wszystkich usługach MCP/Agent, otrzymasz dużo duplikacji i różne zachowanie w różnych serwisach.

Aby rozluźnić te powiązania i jednocześnie ukryć wewnętrzną złożoność przed ChatGPT, do gry wchodzi MCP Gateway — bramka sieciowa i pojedynczy punkt wejścia dla całego ruchu MCP.

2. Czym jest MCP Gateway w kontekście ChatGPT App

Formalnie MCP Gateway to warstwa proxy i pojedynczy punkt wejścia między klientami MCP (ChatGPT, MCP Jam, twoje wewnętrzne narzędzia) a zestawem twoich usług backendowych — zwykle REST/HTTP API, mikroserwisy, usługi Agents, commerce‑backend itd.

Gateway sam implementuje na zewnątrz protokół MCP (dla ChatGPT wygląda jak jeden serwer MCP), a w środku po prostu wywołuje zwykłe endpointy REST przez HTTP/gRPC.

Na zapytanie tools/list gateway nie proxuje wywołania dalej, tylko zwraca własną listę narzędzi: jest ona albo na sztywno opisana w kodzie, albo zbierana z konfiguracji. Każdy tool jest związany z konkretnym endpointem REST i schematem danych. Na zapytanie tools/call gateway bierze nazwę narzędzia, znajduje odpowiednią trasę REST i wywołuje ją przez klienta fetch/HTTP.

Schematycznie można to przedstawić tak:

flowchart LR
    ChatGPT["ChatGPT / model"] --> |MCP JSON-RPC| Gateway["MCP Gateway<br/>(jedyny serwer MCP)"]
    Gateway --> GiftAPI["Gift REST API<br/>/ mikrousługa prezentów"]
    Gateway --> CommerceAPI["Commerce REST API<br/>/ ACP / płatności"]
    Gateway --> AnalyticsAPI["Analytics Service<br/>/ zdarzenia i metryki"]

Dla ChatGPT to jeden serwer: jeden URL, jeden zestaw narzędzi, jeden strumień zdarzeń. Dla ciebie — elastyczny punkt routingu ruchu do różnych zimnych i gorących usług.

3. MCP Gateway w architekturze GiftGenius

Żeby mniej mówić abstrakcjami i pokazać gateway „w żywym systemie”, kontynuujmy nasz przykład GiftGenius — aplikacji, która dobiera prezenty i potrafi tworzyć zamówienia przez ACP/Instant Checkout.

W prostej wersji mieliśmy jeden serwer MCP, który umiał i suggest_gifts, i checkout_start. Teraz, gdy aplikacja się rozrosła, rozdzielamy odpowiedzialności:

• Gift REST API — wyszukiwanie i rekomendacje prezentów, praca z katalogiem i feedem (zwykła usługa HTTP/REST).
• Commerce REST API — ACP, sesje checkout, statusy zamówień, integracja z dostawcą płatności.
• Analytics Service / REST API — zbieranie zdarzeń i metryk (jakie zestawienia są otwierane, co jest kupowane).
• Oddzielna usługa Agents (jeśli potrzebna) — złożone scenariusze wieloetapowe. Również dostępna przez HTTP/REST, a nie przez MCP.

MCP Gateway staje się jednym punktem wejścia dla wszystkich tych komponentów. On:

• na zapytanie tools/list zwraca wspólną listę tools, którą sam opisuje: każdy tool jest powiązany z konkretnym endpointem REST jednego z serwisów;
• na zapytanie tools/call patrzy na nazwę narzędzia (params.name), według tabeli routingu określa, do którego serwisu REST iść, i wywołuje odpowiednią metodę HTTP (przez fetch, axios itp.).

Jeśli przychodzi tools/call z nazwą suggest_gifts, gateway wywołuje odpowiedni endpoint REST w Gift REST API. Jeśli to checkout_start, zapytanie trafi do Commerce REST API.

Mały pseudokod w TypeScript w stylu Express może wyglądać tak:

// Bardzo uproszczony handler żądań MCP
app.post("/mcp", async (req, res) => {
  const mcpReq = req.body as { method: string; params?: any };
  const ctx = buildContextFromHeaders(req); // auth, locale itp.

  const toolName = mcpReq.params?.name;
  const backendRes = await callBackend(toolName, mcpReq, ctx);

  res.json(backendRes);
});

Wewnątrz pickBackend możesz oprzeć się na nazwie metody, nazwie narzędzia, locale użytkownika, a nawet na wersji usługi (dla wydań „kanarkowych” i blue/green, o których będziemy mówić później w module).

4. Obowiązki MCP Gateway: co dokładnie robi

Zobaczyliśmy, jak gateway wpisuje się w architekturę GiftGenius. Teraz jasno ustalmy, jakie ma obowiązki jako oddzielna warstwa, niezależnie od konkretnej aplikacji. Ważne jest, by postrzegać gateway jako warstwę sieciową i międzyserwisową. Jego zadanie — nie zajmować się logiką biznesową prezentów, ale rozwiązywać zadania infrastrukturalne wokół nich.

Routing żądań

Pierwsza rola — router. Gateway otrzymuje żądanie MCP i, opierając się na jego treści, kontekście użytkownika i swojej konfiguracji, wybiera docelową usługę.

Na przykład w GiftGenius można mieć prostą tabelę routingu:

const TOOL_ROUTES: Record<string, "gift" | "commerce" | "analytics"> = {
  suggest_gifts: "gift",
  get_similar_gifts: "gift",
  checkout_start: "commerce",
  get_order_status: "commerce",
  log_event: "analytics",
};

A następnie jej użyć:

function pickBackend(req: McpRequest, ctx: GatewayContext): Backend {
  if (req.method === "tools/list") return "aggregator";
  if (req.method === "tools/call") {
    const toolName = req.params?.name;
    const group = TOOL_ROUTES[toolName] ?? "gift";
    return group === "commerce" ? commerceBackend : giftBackend;
  }
  return giftBackend;
}

W naszym przypadku giftBackend, commerceBackend, analyticsBackend to zwykłe usługi REST: każda ma bazowy URL ("https://gift-api.internal", "https://commerce-api.internal", …). Gateway nie przesyła MCP do środka, tylko rozkłada wywołanie MCP na żądanie HTTP do właściwego endpointu REST.

Uwierzytelnianie i autoryzacja na perymetrze

Druga kluczowa funkcja — ochrona perymetru. Gateway to wygodne miejsce, by sprawdzić token, zrozumieć, kim jest użytkownik, z jakiej organizacji przyszedł i jakie ma uprawnienia.

Może na przykład przyjąć token OAuth od ChatGPT lub od twojego serwera MCP Auth, zwalidować go (najlepiej przy pomocy sprawdzonej biblioteki, a nie własnej kryptografii) i zamienić w porządny obiekt kontekstu:

type GatewayContext = {
  userId: string | null;
  tenantId: string | null;
  locale: string;
};

function buildContextFromHeaders(req: Request): GatewayContext {
  const token = req.headers["authorization"]; // "Bearer ..."
  const claims = token ? verifyJwt(token) : null;

  return {
    userId: claims?.sub ?? null,
    tenantId: claims?.tenant ?? null,
    locale: (req.headers["x-openai-locale"] as string) || "en-US",
  };
}

Wewnętrzne usługi backend/REST nie muszą wtedy martwić się o parsowanie surowych nagłówków HTTP i tokenów, tylko otrzymują już znormalizowany context z userId, tenantId i locale. Dokumentacja MCP wprost mówi: nie implementujcie walidacji tokenów „od zera”, używajcie sprawdzonych bibliotek i krótkotrwałych tokenów.

Logowanie, tracing i metryki

Trzecia rola — obserwowalność. Gateway widzi wszystkie przychodzące żądania MCP i wszystkie odpowiedzi, więc to idealne miejsce, by nadać correlation‑id, zalogować parametry narzędzi (bez danych wrażliwych), zapisać czas odpowiedzi i status.

Najprostszy pomysł:

app.use((req, res, next) => {
  const requestId = crypto.randomUUID();
  (req as any).requestId = requestId;

  const start = Date.now();
  res.on("finish", () => {
    const ms = Date.now() - start;
    console.log(
      `[${requestId}] ${req.method} ${req.url} -> ${res.statusCode} in ${ms}ms`
    );
  });

  next();
});

Później w module o obserwowalności będziecie mogli wysyłać te dane nie tylko do console.log, ale do magazynu danych strukturalnych i budować na nich dashboardy.

Podstawowa kontrola obciążenia

Czwarte, ale także ważne zadanie — wstępna kontrola obciążenia. Na gateway wygodnie postawić liczniki wywołań per użytkownik, organizację, narzędzie i endpoint, żeby nie pozwolić jednemu „szalonemu” klientowi spalić twojego klastra i budżetu na modele.

W tym module na razie tylko ustalamy ideę: rate limiting i kolejki żyją na poziomie gateway, szczegóły implementacji (Redis, token bucket, leaky bucket) będą omawiane w następnej lekcji o ochronie perymetru.

Wzbogacanie żądań kontekstem

I wreszcie, gateway to dobre miejsce, by zamienić surowy kontekst klienta MCP w porządne argumenty dla wewnętrznych narzędzi.

Na przykład ChatGPT może przekazywać locale użytkownika przez openai/locale i _meta["openai/userLocation"]. Gateway może:

• wybrać właściwą usługę regionalną (serwer ru, serwer en itd.);
• dodać locale do argumentów wywołania narzędzia, nawet jeśli samo narzędzie nie żąda go jawnie w JSON Schema (np. jako pole opcjonalne).

Umownie:

function enrichToolArgs(args: any, ctx: GatewayContext) {
  return {
    ...args,
    locale: args.locale ?? ctx.locale,
    tenantId: ctx.tenantId,
  };
}

W efekcie Gift API od razu dostaje „bogaty kontekst” i może np. pobrać opisy prezentów po rosyjsku dla "ru-RU" i po angielsku dla "en-US".

5. Czego MCP Gateway NIE powinien robić

Gdy deweloper dostaje „magiczne miejsce, przez które przechodzi wszystko”, pojawia się naturalna pokusa, by wcisnąć tam wszystko, co wcześniej było w oddzielnych usługach. Tak gateway grozi przemianą w potwora.

Jest kilka rzeczy, które z reguły nie powinny żyć w tej warstwie.

Po pierwsze, złożona logika biznesowa. Dobór prezentów, zasady rabatów, wyliczanie kosztu dostawy, logika ACP — to wszystko powinno pozostać wewnątrz wyspecjalizowanych usług backend/commerce. Gateway może co najwyżej zrobić lekką wstępną walidację (np. sprawdzić, że cena nie jest ujemna), ale nie wybierać SKU i nie liczyć podatku według regionów.

Po drugie, długotrwały stan użytkownika. Gateway to typowa usługa stateless. Powinien skalować się horyzontalnie, nie polegać na lokalnej pamięci i restartować się bez konsekwencji. Jeśli zaczniesz przechowywać w nim np. stan kreatora checkout lub tymczasową zawartość koszyka, szybko pojawi się ból z synchronizacją między instancjami.

Po trzecie, funkcje specyficzne, które logiczniej umieścić wewnątrz samych usług backendowych (Gift API, Commerce API). Na przykład jeśli backend Gift chce cache’ować wynik wyszukiwania prezentów, niech robi to sam, być może używając Redisa. Gateway nie musi znać tej wewnętrznej optymalizacji. Osobno będziemy jeszcze mówić o ochronie perymetru i tam podkreślamy: bramka jest od funkcji sieciowych i międzyserwisowych, a nie od zasad biznesowych rekomendacji.

Po czwarte, ciężkie obliczenia. Jeśli w gateway zaczniesz odpalać modele LLM, robić złożone transformacje i agregacje, przestanie być „lekkim” frontem i zmieni się w kolejny gruby backend, który trudno skalować i debugować.

6. Gateway, lokalizacja i wersje usług

Omówiliśmy podstawowe obowiązki gateway oraz to, czego do niego lepiej nie wkładać. Teraz spójrzmy na parę typowych „zaawansowanych” zadań, które wygodnie rozwiązywać właśnie na tej warstwie: lokalizację i wersjonowanie usług. Kolejna ciekawa rola gateway — inteligentny routing po locale i wersjach usług.

Kiedy ChatGPT wywołuje twój App, ma już informację o języku użytkownika (openai/locale) i często o jego geolokalizacji (_meta["openai/userLocation"]). Gateway może użyć tych danych, aby kierować żądania do właściwych usług backendowych.

Na przykład można zbudować architekturę „jeden gateway — wiele backendów jednojęzycznych”:

• ru‑Gift API — tylko rosyjski katalog prezentów i treści.
• en‑Gift API — tylko angielski.
• jp‑Gift API — japoński (kiedy postanowicie podbić świat).

Gateway w tym przypadku występuje jako serwer MCP dla ChatGPT i po locale oraz userLocation wybiera odpowiednią usługę wewnętrzną.

Umownie:

function pickGiftBackendByLocale(ctx: GatewayContext): Backend {
  if (ctx.locale.startsWith("ru")) return giftRuBackend;
  if (ctx.locale.startsWith("ja")) return giftJpBackend;
  return giftEnBackend;
}

Tam też wygodnie realizować najprostszy routing kanarkowy. W tym module o architekturze produkcyjnej sugerujemy użyć gateway, by część ruchu wysyłać do nowego klastra usługi, a resztę — do starego.

Przykład bardzo zgrubnego „kanarka”:

function pickGiftBackendCanary(ctx: GatewayContext): Backend {
  const hash = hashUser(ctx.userId ?? "anonymous");
  const bucket = hash % 100;
  return bucket < 5 ? giftBackendV2 : giftBackendV1; // 5% ruchu idzie na v2
}

Tak można bezpiecznie wdrażać nową wersję Gift API, patrząc na metryki i błędy, bez psucia całej produkcji naraz.

7. Typowe architektury: od „wszystko w jednym” do Gateway

Wcześniej w kursie widzieliście już kilka wariantów architektury produkcyjnej ChatGPT App. W tym module wyróżniamy trzy podstawowe topologie, które w 90% przypadków wystarczają.

Pierwsza — „wszystko w jednym”. Widżet App (Next.js), serwer MCP, logika Agents i prosty commerce‑backend żyją w jednej usłudze, często w jednym repozytorium, a nawet w jednej aplikacji Vercel. Plus takiego podejścia — prawie brak DevOps, prosty deploy, minimalne opóźnienia. Minus — trudno skalować poszczególne części, jedna „gorąca” funkcja może położyć całą aplikację, a granice między komponentami są rozmyte.

Druga — App + MCP Gateway + kilka usług backendowych. Tutaj widżet Next.js żyje osobno (np. na Vercelu), a cały ruch MCP idzie przez Gateway, który kieruje żądania do Gift REST API, Commerce REST API, usługi Agents, ACP‑backendu i innych. To właśnie schemat, który omawiamy teraz w ramach GiftGenius i który pasuje do 90% realnych przypadków produkcyjnych.

Trzecia — to samo, ale w wielu regionach (multi‑region), z globalnym load balancerem przed gateway. Wtedy użytkownik z Europy trafia do klastra eu, z USA — do klastra us, a każdy region jest budowany według schematu „Gateway + kilka usług backendowych”. To już historia dla dość dużych projektów z globalną publicznością.

Dla nas ważne jest teraz nie tyle zapamiętanie wszystkich wariantów, co nawyk myślenia o gateway jako o oddzielnym komponencie logicznym architektury, nawet jeśli na pierwszych etapach jego rolę pełni np. jeden monolityczny MCP lub backend twojego App.

8. Gdzie fizycznie „żyje” MCP Gateway

Dobra wiadomość: MCP Gateway to niekoniecznie ogromna oddzielna usługa na Kubernetesie. Najczęściej przechodzi kilka etapów dojrzewania.

W najmniejszej skali rolę gateway może pełnić sam serwer MCP. W takim przypadku wystarczy starannie ustrukturyzować kod: wynieść routing, uwierzytelnianie i logowanie do jednego modułu, a logikę narzędzi — do innych. W tym module wprost zaznaczamy, że w małych systemach funkcje gateway mogą być wewnątrz serwera MCP lub części backendowej App (np. w Next.js API route).

Kolejny krok — osobna usługa Node/TypeScript. Może to być aplikacja Express/Fastify, która nasłuchuje "/mcp" i chodzi do środka do kilku usług HTTP. Dla wielu zespołów to wygodna opcja: dobrze wpisuje się w znane narzędzia DevOps.

Najprostszy szkielet takiej usługi:

const app = express();
app.use(express.json());

app.post("/mcp", handleMcpRequest); // tutaj dzieje się cała magia gateway

app.listen(4000, () => {
  console.log("MCP Gateway listening on :4000");
});

Na jeszcze dojrzalszym etapie gateway można zaimplementować na bazie rozwiązań zarządzanych: AWS API Gateway, Cloudflare Workers/Routes, NGINX/Envoy z konfiguracją routingu i skryptami Lua/JS. Ważne, że to zmiana implementacji, a nie koncepcji. Architektonicznie ChatGPT wciąż trafia w jeden punkt, a wszystkie szczegóły rozwiązuje gateway.

9. Mini‑przykład: prosty MCP Gateway dla GiftGenius

Już osobno spojrzeliśmy na routing, kontekst i obsługę tools/list. Teraz złóżmy wszystko w jeden zwięzły, ale mały przykład. Załóżmy, że mamy dwie wewnętrzne usługi REST:

• GIFT_API_BASE = "https://gift-api.internal";
• COMMERCE_API_BASE = "https://commerce-api.internal".

I jeden gateway, do którego ChatGPT będzie się zgłaszać pod adresem "https://gateway.giftgenius.com/mcp".

Najpierw zdefiniujmy kilka typów:

type Backend = "gift" | "commerce";

type ToolRoute = {
  backend: Backend;
  method: "GET" | "POST";
  path: string;
};

const TOOL_ROUTES: Record<string, ToolRoute> = {
  suggest_gifts: {
    backend: "gift",
    method: "POST",
    path: "/api/gifts/suggest",
  },
  checkout_start: {
    backend: "commerce",
    method: "POST",
    path: "/api/checkout/start",
  },
  get_order_status: {
    backend: "commerce",
    method: "GET",
    path: "/api/orders/status",
  },
};

Następnie zaimplementujemy wybór backendu i wywołanie:

async function callBackend(toolName: string, mcpReq: McpRequest, ctx: GatewayContext) {
  const route = TOOL_ROUTES[toolName];
  if (!route) {
    throw new Error(`Unknown tool: ${toolName}`);
  }

  const base =
    route.backend === "gift" ? GIFT_API_BASE : COMMERCE_API_BASE;

  const url = base + route.path;

  // args, które przyszły w wywołaniu MCP tools/call
  const args = {
    ...(mcpReq.params?.arguments ?? {}),
    locale: ctx.locale,
  };

  const res = await fetch(url, {
    method: route.method,
    headers: { "content-type": "application/json" },
    body: route.method === "POST" ? JSON.stringify(args) : undefined,
  });

  const data = await res.json();

  // Opakowujemy odpowiedź usługi REST w odpowiedź MCP
  return {
    result: data,
  } satisfies McpResponse;
}

I wreszcie główny handler, który:

1. Buduje kontekst z nagłówków (auth, locale).
2. Wybiera backend.
3. Albo agreguje tools/list, albo proxuje tools/call.

app.post("/mcp", async (req, res) => {
  const mcpReq = req.body as McpRequest;
  const ctx = buildContextFromHeaders(req);

  if (mcpReq.method === "tools/list") {
    // Gateway sam deklaruje narzędzia i ich schematy
    const tools = [
      {
        name: "suggest_gifts",
        description: "Dobiera prezenty według budżetu i zainteresowań.",
        inputSchema: { /* ... JSON Schema ... */ },
      },
      {
        name: "checkout_start",
        description: "Tworzy szkic zamówienia i uruchamia checkout.",
        inputSchema: { /* ... */ },
      },
      // ...
    ];

    return res.json({ result: { tools } });
  }

  if (mcpReq.method === "tools/call") {
    const toolName = mcpReq.params?.name;
    const backendRes = await callBackend(toolName, mcpReq, ctx);
    return res.json(backendRes);
  }

  res.status(400).json({ error: { message: "Unsupported MCP method" } });
});

To oczywiście uproszczony schemat, ale już pokazuje kluczowe idee:

• gateway nie wie, jak dokładnie Gift API dobiera prezenty;
• on jedynie starannie routuje, wzbogaca argumenty i — w razie potrzeby — loguje oraz limituje wywołania.

10. Jak to wszystko łączy się z kolejnymi tematami modułu

MCP Gateway to fundamentalna część wszystkiego, co będziemy omawiać w pozostałych lekcjach modułu:

• W następnym temacie będziemy mówić o ochronie perymetru: rate limiting, kolejkach i backpressure. To wszystko żyje przede wszystkim na poziomie gateway, ponieważ to on widzi cały ruch przychodzący i może „odciąć nadmiar” zanim żądania zasypią backend.
• Dalej omówimy odporność: timeouts, circuit breakers, bulkheads. Gateway to punkt, w którym wygodnie centralnie ustawiać timeouty na wywołania zewnętrzne i włączać/wyłączać problematyczne usługi (np. tymczasowo „odciąć” Commerce API, jeśli zaczyna sypać błędami).
• I wreszcie, przy rozmowie o skalowaniu i wdrażaniu będziemy patrzeć na gateway jak na oddzielny klaster, który można balansować, wdrażać według schematów blue/green i canary oraz cofać niezależnie od wewnętrznych usług MCP.

W gruncie rzeczy, jeśli wcześniej myślałeś „mam App i serwer MCP”, to teraz schemat rozszerza się do „mam App, MCP Gateway, kilka klastrów backend/Agents i commerce‑backend”. I to właśnie gateway pozwala przy tym nie komplikować konfiguracji dla ChatGPT — on nadal widzi jeden punkt MCP.

11. Typowe błędy przy pracy z MCP Gateway

Błąd nr 1: zamienianie gateway w „potwora biznesowego”.
Częsta pułapka: skoro przez gateway przechodzi wszystko, to czemu nie dodać tam wyliczania rabatów, doboru SKU, złożonych zasad kategorii czy walidacji kodów promocyjnych. W efekcie dostajesz ociężałą usługę, którą trudno skalować i zmieniać, i tracisz sens podziału na Gift API, Commerce API i inne wyspecjalizowane komponenty. Lepiej trzymać gateway jako cienką warstwę sieciową, a wszystko domenowo‑specyficzne zostawić wewnątrz usług profilowych.

Błąd nr 2: przechowywanie w gateway długotrwałego stanu użytkownika.
Pomysł „zapiszmy koszyk użytkownika w pamięci gateway” brzmi kusząco, dopóki masz jedną instancję. Gdy tylko pojawi się druga, zaczyna się ból: gdzie jest prawdziwy koszyk — w instancji A czy B? Co będzie po restarcie? Gateway powinien pozostać stateless: co najwyżej mały cache handshake’ów lub konfiguracji, a cały stan sesji i zamówień trzymany jest w bazie danych lub w wyspecjalizowanych usługach.

Błąd nr 3: uświadamianie ChatGPT o wewnętrznej topologii usług.
Jeśli zaczynasz przekazywać do ChatGPT kilka serwerów API (osobno Gift API, osobno Commerce API), a gateway używać „miejscami”, tracisz główną zaletę: jeden punkt wejścia i scentralizowaną kontrolę. Przy zmianie topologii trzeba będzie zmieniać konfigurację w kilku miejscach. Znacznie prościej raz skonfigurować MCP Gateway jako oficjalny endpoint dla App i ukryć za nim wszystkie wewnętrzne zmiany.

Błąd nr 4: duplikowanie logiki międzyserwisowej we wszystkich backendach.
Czasem zespoły próbują implementować uwierzytelnianie, rate limiting, logowanie i lokalizację w każdej usłudze REST oddzielnie. W efekcie polityka uprawnień i limitów w Gift API jest jedna, w Commerce API — inna, a zachowanie App staje się nieprzewidywalne. Gateway jest właśnie po to, by te rzeczy scentralizować: sprawdzić token, określić tenant i locale, zalogować wywołanie, zastosować limity, a potem iść do konkretnej usługi.

Błąd nr 5: przeciążanie gateway ciężkimi obliczeniami i wywołaniami LLM.
Technicznie nic nie stoi na przeszkodzie, by z gateway wywołać kolejną LLM, robić złożone agregacje lub długie operacje wsadowe. Ale to szybko zmieni go w kolejny ciężki backend, którego nie da się sensownie skalować i izolować. Gateway powinien pozostać szybki i przewidywalny: co najwyżej lekka transformacja i routing. Wszystko ciężkie — do usług REST lub do kolejek/workerów, o których powiemy dalej w module.

Błąd nr 6: zbyt wczesne komplikowanie infrastruktury.
Skrajność odwrotna — od razu budować osobny klaster Kubernetes, stos NGINX, Cloudflare Workers i mnóstwo skomplikowanych konfiguracji dla małego, szkoleniowego App. Nie ma to sensu, dopóki nie ma realnego obciążenia i wymagań niezawodności. Całkowicie w porządku jest zacząć od jednego monolitu MCP lub prostego Node‑gateway, a dopiero potem, wraz z rozwojem, wynosić komponenty do klastrów i usług zarządzanych.