Vlastní MCP servery – jak naučit AI rozumět vašemu softwaru

Když dnes nasazuju AI do vývojářského workflow, nejčastější bariéra není model. Je to kontext. Coding agent zná veřejný internet do data tréninku, ale nezná váš interní systém – vaše API, vaše datové modely, vaše business pravidla. Generickým promptováním to lepíte ručně, znova a znova, a stejně se trefíte z poloviny. Tady přichází na řadu MCP server.

V tomhle textu vysvětluju, co MCP server je, proč se vyplatí postavit si vlastní místo spoléhání na prompt, a hlavně kde jsou hranice – co AI dělat smí a co ne.

Co je MCP server, bez hype

MCP (Model Context Protocol) je standardizovaný protokol, kterým se coding agent připojí k externímu zdroji. Berte to jako most mezi AI a vaším systémem – vaším API, databází, interní dokumentací, deploy pipeline.

Místo aby AI hádala, jak vaše aplikace funguje, dostane jasně definovanou sadu nástrojů (tools): „tohle umíš zavolat, tady jsou parametry, tohle dostaneš zpátky“. Žádná magie. Je to RPC vrstva s popisem, kterému model rozumí.

Důležité je, co MCP server není: není to model, není to „agent“, není to náhrada za vaši logiku. Je to adaptér. Veškerá chytrost zůstává tam, kde byla – ve vašem kódu a ve vašem návrhu nástrojů.

Proč vlastní server poráží generické promptování

Generický prompt typu „naše API má endpoint /orders, vrací JSON s poli...“ má tři problémy. Je křehký (formát se rozjede), je drahý na tokeny (kontext nacpaný popisem) a hlavně je nedeterministický – AI si to interpretuje pokaždé trochu jinak.

Vlastní MCP server tohle řeší tím, že dává AI deterministický, bezpečný přístup k vašemu kontextu:

• Determinismus – nástroj get_order(id) vrátí strukturovaná data ve stejném tvaru pokaždé. Model nehádá schéma, dostane ho.
• Bezpečnost – vy definujete, co je vystavené. AI nevidí celou databázi, vidí jen to, co jste jí dali jako tool.
• Úspora kontextu – popis nástroje je krátký a jednoznačný. Nemusíte do každého promptu lepit dokumentaci.
• Auditovatelnost – každé volání projde vaším serverem, takže ho můžete logovat, omezovat a kontrolovat.

V praxi dělám to, že business znalost, kterou bych jinak opakoval v promptu, zapouzdřím jednou do nástroje. Tím se z software engineeringu posouvám do context engineeringu – práce není napsat víc kódu, ale dát AI správně tvarovaný, ohraničený kontext.

Konkrétní případy použití

Kde se mi vlastní MCP server reálně vyplatí:

• Ovládání vlastních aplikací – AI umí spustit deploy, založit feature flag nebo vyčíst stav prostředí přes nástroje, které jste schválili. Ne přes shell, kde může cokoliv.
• Rychlejší změny – když agent ví, jak vypadají vaše entity a jak se validují, generuje úpravy, které sednou napoprvé. Méně kol revize.
• Čtení interních zdrojů – interní wiki, ADR záznamy, schéma databáze, runbooky. AI dostane odpověď z vašeho zdroje pravdy, ne ze své paměti.

Společný jmenovatel: AI přestává hádat a začíná pracovat s vaším skutečným systémem.

Jak vypadá definice nástroje

Tady je ilustrativní (generická, ne z reálného produktu) definice jednoho read-only nástroje. Záměrně jednoduchá:

tool:
  name: get_order_status
  description: Vrátí aktuální stav objednávky podle ID. Read-only.
  input:
    order_id:
      type: string
      required: true
  returns:
    status: enum[new, paid, shipped, cancelled]
    updated_at: datetime
  permissions:
    scope: read
    rate_limit: 60/min

Klíčové je, že nástroj má úzký kontrakt: jeden účel, jasné vstupy, jasné výstupy, explicitní oprávnění. Žádné generické run_query(sql), kterým by AI mohla sáhnout kamkoliv.

Bezpečnost a hranice – co AI nesmí

Tohle je část, kterou nepřeskakujte. MCP server dává AI ruce ve vašem systému, takže hranice (mantinely) jsou součást návrhu, ne dodatek.

Moje pravidla, kterých se držím:

• Default je read-only. Zápisové a destruktivní operace jsou samostatné nástroje s explicitním schválením, ideálně s human-in-the-loop potvrzením.
• Žádné generické „spusť cokoliv“. Nevystavujte raw SQL, raw shell ani volný HTTP. Každá schopnost je pojmenovaný nástroj s úzkým kontraktem.
• Princip nejmenšího oprávnění. Server běží pod identitou, která vidí jen to, co opravdu potřebuje. Ne pod admin tokenem.
• Logujte a rate-limitujte. Každé volání auditovatelné. Když se něco zvrtne, chcete vědět co a kdy.
• Citlivá data nepouštějte ven. Server je místo, kde maskujete PII a tajemství dřív, než se dostanou do kontextu modelu.

Cíl se dá shrnout heslem: deterministicky, rychle, bezpečně. Determinismus dává tvar, rychlost přichází z toho, že AI nehádá, a bezpečnost z toho, že hranice jsou tvrdě v kódu serveru – ne v naději, že prompt model udrží.

Pokud řešíte regulaci, tohle není navíc: auditovatelnost volání a omezení rozsahu jsou přesně to, co se vám hodí při argumentaci kolem EU AI Act i při interním compliance.

Závěrem

Vlastní MCP server není módní vlna. Je to praktická vrstva, která mění AI z chytrého hádače na nástroj s deterministickým, ohraničeným přístupem k vašemu systému. Nemusíte stavět deset serverů hned – začněte jedním read-only nástrojem nad zdrojem, který vaši lidé nejčastěji potřebují, a hranice si pohlídejte od prvního commitu. Vyplatí se víc investovat do návrhu nástrojů a mantinelů než do delších promptů. Tam je ta skutečná práce context engineeringu.