LLM gateway a MCP gateway: dvě brány, bez kterých se firemní AI neobejde

Každá produkční AI aplikace má dva kritické toky. Směrem k modelům tečou prompty a tokeny — a s nimi peníze. Směrem k nástrojům tečou akce — a s nimi přístupy k vašim datům a systémům. Oba toky začínají nevinně (jeden API klíč, jeden konfigurační soubor) a oba se při růstu zvrhnou v chaos klíčů, nákladů a bezpečnostních děr. Řešení je v obou případech stejné jako kdysi u mikroslužeb: postavit do cesty bránu. LLM gateway sjednotí poskytovatele modelů, pohlídá rozpočty a přežije výpadek; MCP gateway udrží pod kontrolou nástroje, tajemství a audit. V článku rozebereme obě do hloubky — co přesně dělají, jak vypadá průchod požadavku, jaká řešení jsou k dispozici a jak je poskládat dohromady.

Anatomie AI aplikace: mozek a ruce

Než se pustíme do bran, ujasněme si, co vlastně hlídají. Agentní aplikace je ve své podstatě smyčka, ve které jazykový model přemýšlí a volá nástroje. Z pohledu infrastruktury z ní vedou dva druhy odchozích spojení:

• Volání modelů (mozek). HTTP požadavky na inference API — OpenAI, Anthropic, Google, nebo vlastní vLLM cluster. Platí se za každý token, latence se počítá v sekundách a poskytovatelé mají výpadky, rate limity a zhruba půlroční životní cyklus modelů.
• Volání nástrojů (ruce). Akce ve vašich systémech: čtení databáze, zakládání ticketů, commity do repozitářů. Neplatí se za ně tokeny, ale mají vedlejší účinky — a proto úplně jinou kategorii rizik: co všechno smí agent udělat a čím se u toho prokazuje?

Dva toky, dva odlišné problémy — a proto dvě různé brány. Začneme mozkem.

Problém první: volání modelů se rozleze

První verze každé AI aplikace volá jednoho poskytovatele napřímo: OPENAI_API_KEY v proměnné prostředí a jede se. Potíže přicházejí postupně a známým rytmem:

• Druhý poskytovatel. Chcete zkusit Claude na úlohy, kde je lepší, nebo levný open-source model na klasifikaci. Jenže každý poskytovatel má jiné API (Chat Completions vs. Messages), jiné SDK, jinak řeší streaming, function calling i chybové kódy. V kódu začnou bujet if provider == ... větve.
• Klíče a útraty bez kontroly. Každý tým si založí vlastní účet, klíče kolují v .env souborech a nikdo neumí odpovědět na otázku „kolik nás stojí AI funkce X měsíčně?“. Faktura chodí jedna, za všechno dohromady.
• Spolehlivost. Výpadky poskytovatelů jsou realita, stejně jako HTTP 429 při špičkách. Bez failoveru na jiný deployment či jiného poskytovatele stojí s cizí infrastrukturou i vaše aplikace.
• Model churn. Modely zastarávají rychleji než knihovny — poskytovatelé vydávají nové verze každých pár měsíců a staré vypínají. Když je název modelu natvrdo zadrátovaný na dvaceti místech v kódu, je každá obměna malý projekt.

LLM gateway: jedno API nad všemi modely

LLM gateway (někdy AI gateway) je proxy, přes kterou jdou všechna volání modelů. Vaše aplikace mluví s jediným endpointem jednotným API — prakticky vždy ve formátu OpenAI Chat Completions, který se stal lingua franca — a gateway požadavek přeloží a doručí správnému poskytovateli. Kolem toho pak přidává vrstvy, kvůli kterým se celé cvičení dělá:

• Aliasy modelů a routing. Aplikace žádá o chytry-model nebo levny-model; na jaký konkrétní model a u koho se alias mapuje, je konfigurace gateway. Výměna modelu = změna jednoho YAML, žádný redeploy aplikací. Routovat jde i chytřeji: rozložení zátěže mezi více deploymentů, směrování podle latence nebo ceny.
• Fallbacky a retry. Když primární model vrátí 429 nebo 5xx, gateway transparentně zkusí další v pořadí — jiný region, jiného poskytovatele, případně levnější model jako degradovaný režim. Aplikace se nic nedozví, dostane odpověď.
• Virtuální klíče a rozpočty. Skutečné klíče poskytovatelů zná jen gateway. Týmy a aplikace dostávají virtuální klíče s vlastním rozpočtem (např. 200 USD měsíčně), rate limitem (požadavky i tokeny za minutu) a seznamem povolených modelů. Utracený rozpočet = HTTP 429, ne překvapení na faktuře.
• Cache. Exaktní (stejný prompt → stejná odpověď z cache) i semantická — cache hit i pro podobně formulované dotazy přes embedding podobnost. Na opakujících se úlohách (FAQ, klasifikace, moderace) uvádějí provozovatelé úspory 20–40 % nákladů.
• Observabilita nákladů. Každý požadavek zalogovaný s cenou, tokeny, latencí a virtuálním klíčem — takže poprvé jde odpovědět na otázku, kolik stojí konkrétní funkce, tým nebo zákazník. Export do Prometheu/OpenTelemetry, alerting na anomálie.
• Guardraily. Centrální místo pro maskování PII v promptech, detekci jailbreaků a filtrování obsahu — politika se vynucuje pro všechny aplikace stejně, ne podle toho, kdo si na ni vzpomněl.

Cena za to všechno? Jeden síťový skok navíc. Slušné gateway přidávají jednotky až nízké desítky milisekund — proti sekundám, které trvá samotná inference, je to zaokrouhlovací chyba.

LLM gateway v praxi: LiteLLM

Nejrozšířenější open-source volbou je LiteLLM — Python proxy, kterou si spustíte na vlastní infrastruktuře (typicky s PostgreSQL na evidenci útrat a Redis pro cache). Jádro konfigurace je mapování aliasů na konkrétní modely:

# config.yaml -- dva aliasy, tri modely, fallback a cache
model_list:
  - model_name: chytry-model
    litellm_params:
      model: openai/gpt-4.1
      api_key: os.environ/OPENAI_API_KEY
  - model_name: chytry-model            # stejny alias podruhe = load balancing
    litellm_params:
      model: anthropic/claude-sonnet-4-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: levny-model
    litellm_params:
      model: hosted_vllm/llama-3.3-70b
      api_base: http://vllm.interni.firma.cz/v1

litellm_settings:
  cache: true
  fallbacks:
    - chytry-model: ["levny-model"]     # kdyz oba chytre selzou, degraduj

router_settings:
  routing_strategy: latency-based-routing

Týmům se pak nerozdávají klíče od OpenAI, ale virtuální klíče s rozpočtem a povolenými modely:

$ curl -X POST http://litellm.firma.cz:4000/key/generate \
    -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
    -d '{
      "team_id": "podpora",
      "models": ["chytry-model", "levny-model"],
      "max_budget": 200,
      "budget_duration": "30d",
      "rpm_limit": 100
    }'

A protože gateway mluví OpenAI formátem, aplikace nepotřebují žádnou novou knihovnu — jen jiný base_url:

from openai import OpenAI

client = OpenAI(
    base_url="http://litellm.firma.cz:4000",
    api_key="sk-virtualni-klic-tymu-podpora",
)

odpoved = client.chat.completions.create(
    model="chytry-model",   # alias -- co je za nim, resi gateway
    messages=[{"role": "user", "content": "Shrn otevrene tickety za dnesek."}],
)

Všimněte si, co se právě stalo s migracemi: až příště poskytovatel ohlásí konec životnosti modelu, změníte jeden řádek v config.yaml — a všechny aplikace ve firmě jedou dál.

Kdo je kdo mezi LLM gateway

Praktické vodítko: pro rychlý prototyp bez infrastruktury OpenRouter; pro firemní provoz s plnou kontrolou nad daty self-hosted LiteLLM (případně Portkey, potřebujete-li compliance a guardraily z krabice); a pokud už provozujete API gateway, zvažte její AI rozšíření, než přidáte další komponentu.

Tím máme pod kontrolou mozek. Jenže agentní aplikace mají i ruce — a tam teče úplně jiný provoz.

Problém druhý: nástroje

V článku o AI agentech jsme rozebrali tool calling: model dostane v promptu JSON schémata dostupných nástrojů a místo textové odpovědi může vrátit požadavek „zavolej nástroj X s argumenty Y“. Aplikace nástroj spustí, výsledek vrátí do konverzace a smyčka pokračuje. Funguje to skvěle — ale všimněte si, co všechno zůstává na autorovi aplikace: napsat implementaci každého nástroje, spravovat její závislosti a přístupové klíče, a to celé znovu pro každou aplikaci a každého poskytovatele modelu.

Výsledkem byl ekosystém na jedno použití: konektor na Jiru napsaný pro interní chatbot nešel použít v IDE, konektor z IDE nešel použít v CLI agentovi. Přesně tuhle fragmentaci řeší MCP.

Co je Model Context Protocol

MCP je otevřený protokol, který v listopadu 2024 zveřejnil Anthropic; během roku 2025 ho adoptovaly OpenAI, Google, Microsoft i prakticky všechny agentní frameworky, čímž se stal de facto standardem. Bývá popisován jako „USB-C pro AI“: definuje jednotnou zásuvku, do které jde zapojit libovolný nástroj, a jednotnou zástrčku, kterou umí každý AI klient.

Architektura má tři role:

• Host — aplikace s LLM (Claude Desktop, IDE, vlastní agent).
• MCP klient — komponenta hosta, která drží spojení 1:1 s jedním serverem.
• MCP server — program vystavující schopnosti: tools (funkce, které smí model volat), resources (data ke čtení — soubory, záznamy) a prompts (šablony připravené k použití).

Komunikuje se přes JSON-RPC 2.0, a to buď stdio transportem (server běží jako lokální proces, typické pro vývoj), nebo přes streamable HTTP (vzdálený server, typické pro produkci). Klient se při startu serveru zeptá, co umí (tools/list), a schémata nástrojů předá modelu — od té chvíle je může model volat (tools/call), aniž by aplikace o nástrojích cokoli věděla předem.

Napsat MCP server je otázka pár řádků — v Pythonu se o všechen protokolový balast postará oficiální SDK a jeho třída FastMCP:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("firemni-nastroje")

@mcp.tool()
def stav_objednavky(cislo: str) -> str:
    """Vrati aktualni stav objednavky podle jejiho cisla."""
    objednavka = crm.najdi_objednavku(cislo)
    return f"Objednavka {cislo}: {objednavka.stav}, doruceni {objednavka.termin}"

@mcp.tool()
def zaloz_ticket(nazev: str, popis: str, priorita: str = "stredni") -> str:
    """Zalozi novy ticket v service desku a vrati jeho ID."""
    ticket = servicedesk.vytvor(nazev, popis, priorita)
    return f"Zalozen ticket {ticket.id}"

if __name__ == "__main__":
    mcp.run()   # stdio transport

A klient (třeba IDE) se k němu připojí deklarativně, konfigurací:

{
  "mcpServers": {
    "firemni-nastroje": {
      "command": "python",
      "args": ["firemni_nastroje.py"],
      "env": { "CRM_API_KEY": "sk-live-..." }
    }
  }
}

Elegantní. Jenže přesně v téhle konfiguraci už je zaseté semínko budoucích problémů — vidíte ho? Produkční API klíč leží v plaintextu v konfiguračním souboru na notebooku vývojáře.

Co se pokazí, když MCP nasadíte naivně

Dokud jde o jednoho vývojáře a dva servery, je všechno v pořádku. Ve firmě s desítkami lidí, několika AI klienty (IDE, chatbot, CI agenti) a rostoucím katalogem interních i veřejných serverů se objeví čtyři kategorie problémů:

• Kombinatorická exploze konfigurace. Každý klient × každý server × každý stroj = ručně udržované JSON soubory všude. Aktualizace serveru nebo rotace klíče znamená obejít všechny instalace.
• Tajemství bez správy. API klíče v konfiguračních souborech a proměnných prostředí, často s plnými právy, bez expirace a bez přehledu, kdo je vlastně má.
• Nulová viditelnost. Který agent zavolal který nástroj s jakými argumenty? Bez centrálního bodu neexistuje audit log — a compliance oddělení má zlé sny.
• Nový útočný povrch. MCP server je kód třetí strany, který spouštíte s vašimi přístupy. Hrozí tool poisoning (popis nástroje obsahuje skryté instrukce pro model), rug pull (server po aktualizaci změní chování) a hlavně prompt injection: útočník vloží instrukce do dat, která agent legitimně čte — třeba do GitHub issue — a agent je pak s oprávněními svého uživatele vykoná. Přesně takhle fungoval známý GitHub MCP data heist: injektovaná issue v public repozitáři přiměla agenta vynést data z privátních repozitářů, ke kterým měl tentýž token přístup.

Všimněte si zásadního rozdílu proti volání modelů: u mozku šlo hlavně o peníze a spolehlivost, tady jde o oprávnění a vedlejší účinky. Proto MCP gateway vypadá jinak než LLM gateway — míň se zabývá cenou tokenu a víc tím, kdo smí co spustit.

MCP gateway: jedna brána místo N×M drátů

MCP gateway je server, který stojí mezi všemi klienty a všemi MCP servery. Navenek se tváří jako jeden velký MCP server (klienti se konfigurují jednou, proti jedné adrese), dovnitř funguje jako reverse proxy s registrem: ví, které servery existují, kdo k nim smí, spouští je, předává jim požadavky a všechno zaznamenává.

Co konkrétně gateway přidává:

• Registr a katalog — seznam schválených serverů včetně verzí a původu. Vývojář si nástroj „objedná“ z katalogu, místo aby instaloval náhodný balíček z internetu.
• Autentizace a autorizace — klienti se prokazují gateway (OAuth, JWT), gateway se prokazuje serverům. RBAC určuje, který tým vidí které nástroje; profily zužují sadu nástrojů na to, co daný agent skutečně potřebuje.
• Správa tajemství — API klíče žijí v trezoru gateway a injektují se do serverů až za běhu. Z notebooků vývojářů zmizí.
• Guardraily a interceptory — programovatelné háčky před a po každém volání nástroje: validace argumentů, blokace podezřelých vzorů, maskování PII v odpovědích.
• Audit a observabilita — každé volání zalogované s identitou, argumenty a výsledkem; metriky a tracing (OpenTelemetry) pro ladění i compliance.
• Izolace a životní cyklus — gateway servery spouští (typicky v kontejnerech s ořezanými právy), restartuje, škáluje a vypíná.

Kdo je kdo mezi MCP gateway

Prakticky: MCP gateway za pět minut

Nejrychlejší start nabízí Docker MCP Gateway. Servery vyberete z katalogu, gateway je při prvním volání spustí jako izolované kontejnery a klientům vystaví jediný endpoint:

# povol vybrane servery z katalogu
$ docker mcp server enable github-official duckduckgo

# API klice do trezoru, ne do configu
$ docker mcp secret set github.personal_access_token=ghp_...

# spust gateway pro vice klientu pres HTTP
$ docker mcp gateway run --transport streaming --port 8080

Všichni klienti (IDE, Claude Desktop, vlastní agent) se pak konfigurují stejně — jedním záznamem místo N:

{
  "mcpServers": {
    "brana": { "url": "http://localhost:8080/mcp" }
  }
}

A tady se vracíme ke GitHub data heistu. Obrana proti němu je u gateway jednořádková politika: interceptor, který před každým voláním zkontroluje, že agent nesahá mimo povolený repozitář:

# interceptor "before": shell skript dostane JSON volani na stdin;
# kdyz argumenty miri do jineho nez povoleneho repozitare, volani zablokuje
$ docker mcp gateway run --transport streaming --port 8080 \
    --interceptor "before:exec:/policies/cross-repo-blocker.sh" \
    --interceptor "after:exec:/policies/audit-logger.sh"

Enterprise scénář (stovky uživatelů, týmy, RBAC) pak pokrývá ContextForge — běží jako běžná webová služba, v produkci typicky na Kubernetes:

$ docker run -d --name mcpgateway -p 4444:4444 \
    -e AUTH_REQUIRED=true \
    -e JWT_SECRET_KEY=dlouhy-nahodny-retezec \
    -e PLATFORM_ADMIN_EMAIL=admin@firma.cz \
    -e PLATFORM_ADMIN_PASSWORD=zmen-me \
    ghcr.io/ibm/mcp-context-forge:latest

Vedlejší bonus: méně nástrojů v kontextu

MCP gateway nepomáhá jen bezpečnosti. Každý nástroj, který agentovi nabídnete, zabírá místo v kontextovém okně (schéma + popis klidně stovky tokenů) — a s desítkami serverů se agent snadno dostane na tisíce tokenů jen v definicích nástrojů, které nikdy nepoužije. Modely navíc s rostoucím počtem nástrojů vybírají hůř; je to obdoba problémů, které známe z článku o U-křivce. Profily na gateway tohle řeší systémově: každý agent dostane jen výsek katalogu relevantní pro jeho práci, případně gateway nabídne dynamické vyhledávání nástrojů (agent si nástroj najde, až když ho potřebuje) — místo aby všech 200 definic viselo v každém promptu.

Mozek a ruce dohromady: referenční architektura

Jak to celé vypadá pohromadě? Agentní aplikace stojí uprostřed a obě brány jsou její jediné odchozí cesty: prompty jdou doleva přes LLM gateway k modelům, volání nástrojů doprava přes MCP gateway k systémům. Aplikace sama nezná jediný skutečný API klíč.

Souhrnně, protože se ty dva pojmy pletou i v marketingu dodavatelů:

A aby to nebylo příliš přehledné: obě kategorie k sobě konvergují. LiteLLM umí kromě modelů zprostředkovat i MCP servery, Portkey nabízí MCP gateway jako samostatný produkt a ContextForge zase směrem k modelům routuje agenty přes A2A protokol. Menší firma tak může začít s jednou bránou pro obojí — důležité je, aby oba toky nějakou bránou procházely, ne kolik kontejnerů na to běží.

Co s tím v praxi

Pro volání modelů

• Aliasy od prvního dne: žádný natvrdo zadaný název modelu v kódu. Výměna modelu má být změna konfigurace, ne release.
• Virtuální klíče s rozpočty pro každý tým a aplikaci; skutečné klíče poskytovatelů zná jen gateway. Rozpočet nastavte dřív, než přijde první přestřelená faktura.
• Fallback na jiného poskytovatele otestujte dřív, než ho budete potřebovat — včetně toho, že váš kód přežije drobné rozdíly v chování modelů.
• Zapněte cache a měřte hit rate: u opakujících se úloh je to nejlevnější optimalizace, jakou máte k dispozici.
• Sledujte cenu per feature, ne jen celkovou útratu — teprve rozpad podle virtuálních klíčů ukáže, která funkce si na sebe vydělá.

Pro nástroje a MCP

• Gateway nasaďte dřív, než ji budete potřebovat. Migrace deseti vývojářů z ručních konfigurací je snadná; migrace stovky s rozlezlými klíči je projekt na kvartál.
• Nejmenší možná práva: tokeny pro MCP servery omezte na čtení, kde zápis není nutný, a na konkrétní repozitáře/projekty. Prompt injection nezastavíte v modelu — zastavíte ji tím, že ukradené oprávnění nemá kam sáhnout.
• Profily podle rolí: agent pro podporu nepotřebuje nástroje na deployment. Méně nástrojů = menší útočný povrch i lepší výběr nástroje modelem.
• Katalog jen z ověřených zdrojů — podepsané obrazy, verzování, žádné npx náhodného balíčku z README. S neověřenými servery nepomůže ani gateway.
• Logujte a čtěte logy: audit trail je k ničemu, když se na něj nikdo nedívá. Alespoň alerting na anomálie (nezvyklé nástroje, objemy, cílové domény).
• Interní API vystavujte přes gateway (REST→MCP převod v ContextForge), místo psaní vlastního MCP serveru pro každou službu.

← Zpět na všechny články