Architektúra MCP: kompletný technický rozbor s diagramami

Architektúra MCP je základný súbor komponentov a komunikačných pravidiel, ktoré umožňujú fungovanie MCP (Model Context Protocol). MCP je open-source štandard a architektúra MCP je základná infraštruktúra, na ktorej beží.

Každá architektúra MCP obsahuje tri hlavné komponenty, okolo ktorých je postavená: hostiteľa, klienta a server. Komunikačný rámec MCP sa často opisuje ako zložený z dátovej vrstvy a transportnej vrstvy. Dátová vrstva je súbor pravidiel, ktoré určujú formát správ (požiadavky MCP sa odosielajú vo formáte JSON-RPC 2.0). Transportná vrstva tieto správy prenáša, pričom pre externé pripojenia využíva Streaming HTTP.

Architektúra MCP je serverový rámec, ktorý implementuje Model Context Protocol – otvorený štandard na prepojenie modelov AI s nástrojmi, zdrojmi, ako sú databázy, a promptmi, ktoré rozširujú vstupný kontext. Tieto prvky sa súhrnne nazývajú „primitíva“. Architektúra MCP v konečnom dôsledku umožňuje LLM zistiť, ktoré nástroje sú k dispozícii, a vykonávať pracovné postupy, a to bez potreby pravidelných aktualizácií na strane klienta.

Diagram architektúry MCP: aplikácia AI si vymieňa požiadavky so serverom MCP, ktorý poskytuje nástroje, zdroje a prompty.

Odkedy ju predstavila spoločnosť Anthropic, architektúra MCP sa začala široko využívať v pracovných postupoch AI. Je to najmä preto, že bez straty výkonu nahrádza systémy náročnejšie na údržbu, napríklad tie, ktoré sú postavené na viacerých pripojeniach API. Keďže všetky dostupné funkcie sa nachádzajú za serverom MCP, stačí jediné pripojenie a aktualizácie aj nové funkcie sú pre klientsku aplikáciu okamžite k dispozícii.

MCP poskytuje LLM spôsob, ako objavovať a volať nástroje, prompty a zdroje, ktoré majú k dispozícii buď v lokálnom systéme hostiteľskej aplikácie, alebo od externého poskytovateľa.

V prípade nástrojov, ktoré poskytujú prístup k externým funkciám, objavovanie spočíva v tom, že hostiteľ odošle serveru MCP volanie tools/list, aby zistil, ktoré nástroje sú k dispozícii. LLM (alebo v niektorých prípadoch hostiteľ) si potom môže prečítať popisy dostupných nástrojov a podľa potreby o ne požiadať. Prompty a zdroje využívajú podobný proces.

Diagram komponentov architektúry MCP: hostiteľ obsahujúci LLM, orchestrátor a klienta sa pripája k serveru MCP v dvoch krokoch – najprv objavovanie a potom požiadavky – a server MCP sprístupňuje nástroje, zdroje a prompty.

To je v kontraste s architektúrou založenou na API na mieru, ktorá bola vo vývoji softvéru bežnou normou a v ktorej sa funkcie mimo aplikácie museli volať cez vyhradené pripojenia s presne naformátovanými požiadavkami.

Hostiteľská aplikácia je centrálnou orchestračnou platformou a pripája sa k LLM. Známe nástroje ako Perplexity a Claude Desktop môžu v systéme MCP fungovať ako hostitelia.

V jednoduchom pracovnom postupe položí používateľ otázku cez rozhranie chatu. Orchestračný komponent hostiteľa potom k otázke pridá kontext a oznámi LLM, ktoré primitíva MCP sú k dispozícii, spolu s popisom ich schopností.

Klient je softvérový komponent v aplikácii AI. MCP poskytuje štandardné rozhranie, cez ktoré klient komunikuje s internými a externými servermi MCP na základe pokynov hostiteľa alebo LLM. Jeho úlohou je nadviazať pripojenie, formátovať správy JSON-RPC, odosielať požiadavky a prijímať odpovede.

Pojmy „hostiteľ MCP“ a „klient MCP“ sa niekedy používajú zameniteľne. Ide však o užitočné rozlíšenie, pretože hostiteľ, napríklad Perplexity, môže súčasne orchestrovať viacerých klientov MCP. Zložitý pracovný postup AI môže vyžadovať prístup k desiatkam či dokonca stovkám samostatných serverov MCP, pričom každý z nich bude využívať samostatné pripojenie.

Diagram hostiteľa MCP, napríklad Perplexity, ktorý orchestruje troch klientov MCP, z ktorých je každý pripojený k vlastnému serveru MCP, napríklad k databáze, súborom alebo externému API.

Server sprístupňuje všetky nástroje, ktoré môže nástroj založený na AI používať. Z hľadiska architektúry server MCP interpretuje prichádzajúcu požiadavku a v prípade potreby sa pripojí k požadovaným primitívam.

Servery MCP môžu poskytovať prístup k trom kategóriám primitív:

Nástroje: Ide v podstate o externé softvérové funkcie. Pri tradičnom prístupe založenom na API môže aplikácia na webovú analytiku získavať údaje pomocou naformátovanej požiadavky na externý server. V architektúre MCP sú všetky funkcie tretej strany od daného poskytovateľa dostupné cez jediné pripojenie a požiadavky sa vytvárajú podľa štandardných pravidiel formátovania.
Zdroje: Zdroje sú zdroje údajov, ktoré poskytujú kontext len na čítanie. Dobrým príkladom sú databázové schémy. Server MCP sprístupňuje hostiteľovi rôzne dostupné zdroje informácií. Ak hostiteľ databázu dopytuje, napríklad pomocou vyhľadávania SQL vygenerovaného LLM, považuje sa to za požiadavku na nástroj.
Prompty: Ide o opakovane použiteľné šablóny promptov, ktoré pomáhajú LLM vykonávať konkrétne úlohy. Používateľ alebo hostiteľ zavolá namiesto nástroja prompt, pretože na dokončenie úlohy potrebuje vopred pripravené pokyny. Prednastavené úlohy v hostiteľskej aplikácii, napríklad možnosť „skontrolovať kód“ alebo „analyzovať údaje“, sú často uložené ako prompty, ktoré si používateľ môže vybrať.

Za zmienku tiež stojí, že MCP a API nie sú navzájom sa vylučujúce technológie. Server MCP môže sprístupňovať volania API, ktoré sú k dispozícii v odpovedi na požiadavku na objavovanie. Podstatné je, že ich údržba je na poskytovateľovi MCP, nie na klientovi.

Dátová vrstva v architektúre MCP je súbor pravidiel, ktoré určujú formát požiadaviek, odpovedí a oznámení. Štandardným jazykom správ je JSON-RPC.

Každá architektúra MCP sa riadi základným procesom: (1) inicializácia a objavovanie zo strany hostiteľa, (2) odpoveď servera MCP a (3) volanie zo strany hostiteľa (o ktorom niekedy rozhoduje LLM), pričom každá fáza predstavuje samostatnú správu JSON.

Diagram dátovej vrstvy MCP: používateľ odošle prompt hostiteľskej aplikácii, v ktorej LLM spolupracuje s klientom MCP; klient odošle požiadavku serveru MCP (nástroje, zdroje, prompty) a dostane výsledok a hostiteľ vráti používateľovi odpoveď.

Pozrime sa na dvoch príkladoch, ako funguje objavovanie nástrojov (rovnako to môže platiť pre zdroje alebo prompty):

Objavenie nástrojov pred generovaním odpovede LLM: Hostiteľ spustí klienta MCP, ktorý odošle požiadavku tools/list (zoznam nástrojov dostupných na serveri MCP). LLM ho počas procesu generovania preskúma a určí, či je potrebný konkrétny nástroj, zdroj alebo prompt.
Poskytnutie možnosti spustiť vyhľadávanie pre LLM: V agentickom systéme hostiteľ pridá do vstupného kontextu možnosť objavovania, napríklad search-tools, a LLM môže v prípade potreby požiadať o vyhľadávanie.

Nástroje, ktoré sú prevažne funkciami externých aplikácií, zvyčajne vyberá LLM alebo hostiteľ. Zdroje a prompty sa zvyčajne vyžadujú na podnet používateľa alebo hostiteľa.

Takto vyzerá požiadavka tools/list na server MCP z vymyslenej aplikácie na poznámky:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

V tomto príklade “id”:101 identifikuje požiadavku pomocou ID, aby klient mohol priradiť odpovede, a pole “params” obsahuje ďalšie informácie o klientovi, napríklad názov klienta (notes-app-client) a jeho schopnosti.

Server MCP v odpovedi vráti definície nástrojov, ktoré obsahujú názvy dostupných nástrojov a súvisiace podrobnosti. Zoznam môže napríklad obsahovať nástroj add-task, ktorý aplikácii na poznámky umožňuje vytvárať úlohy v pripojenej aplikácii na správu úloh alebo v kalendári, pričom každej úlohe priradí názov a prioritu.

Takto by mohla vyzerať požiadavka:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Pole “method” oznamuje serveru MCP, že ide o volanie nástroja, “name” určuje, ktorý nástroj sa má zavolať, a “arguments” poskytuje požadované vstupy.

Ak je dátová vrstva odpoveďou na otázku čo v spojení medzi klientom a serverom MCP, transportná vrstva je odpoveďou na otázku ako. Určuje spôsob, akým sa správy prenášajú: konkrétny kanál a pravidlá, ktoré určujú, ako sa doručujú požiadavky a odpovede.

MCP má dve transportné cesty:

Štandardný vstup/výstup: Používa sa, keď server MCP beží v rovnakom lokálnom prostredí ako hostiteľská aplikácia. Klient zapíše požiadavku JSON na štandardný vstup servera. Server ju prečíta, vykoná požadovanú operáciu a zapíše odpoveď na štandardný výstup.
Streamable HTTP: Keď server MCP beží mimo hostiteľskej aplikácie, klient MCP odosiela serveru požiadavky pomocou HTTP POST. Server odpovedá buď jedinou správou JSON, alebo streamom Server-Sent Events (SSE) – trvalým „načúvajúcim“ kanálom, ktorý mu umožňuje postupne vracať viacero správ.

Viacnájomnícka (multi-tenant) architektúra MCP je typ implementácie, ktorá dokáže súčasne obsluhovať viacerých používateľov (nájomníkov).

Nájomníkom tu môže byť jednotlivec, skupina jednotlivcov alebo organizácia. Implementácia môže zahŕňať prevádzku samostatného servera MCP pre každého nájomníka, poskytovanie prístupu k jedinému zdieľanému serveru alebo umiestnenie skupiny serverov za centrálnu bránu. Ak sa použije brána, smeruje požiadavky na správne koncové body na základe identity používateľa alebo povahy požiadavky.

Funguje na rovnakom základnom princípe ako štandardná architektúra MCP, ale požiadavky jednotlivých používateľov sa spracúvajú v ich vlastnom pracovnom priestore (aj keď to zahŕňa zdieľané zdroje) a overujú sa samostatne. Bežne sa používa v podnikových scenároch a zdieľané zdroje sa často uprednostňujú, pretože prevádzka viacerých serverov MCP by bola zbytočne nákladná.

Ako v praxi vyzerá požiadavka MCP od začiatku do konca? Existuje osem hlavných fáz, z ktorých každá zahŕňa iný komponent architektúry.

Vývojový diagram požiadavky MCP od začiatku do konca v ôsmich krokoch: objavenie nástrojov, vstup používateľa, spracovanie modelom, výber nástroja, požiadavka, vykonanie nástroja, výsledok a generovanie odpovede.

Takto vyzerá volanie nástroja MCP v praxi na predchádzajúcom príklade aplikácie na poznámky pripojenej k službe na správu úloh:

Objavenie nástrojov: Aplikácia na poznámky (hostiteľ) pomocou svojho klienta MCP požiada o nástroje dostupné na serveri prostredníctvom požiadavky tools/list. Server vráti ich názvy, popisy a očakávané vstupy vrátane tých pre nástroj add-task. Môže sa to stať ešte predtým, ako odošlete prompt.
Vstup používateľa: Prostredníctvom chatbota v aplikácii odošlete požiadavku aplikácii na poznámky založenej na LLM, napríklad: „Vytvor v mojom kalendári úlohu skontrolovať môj nový koncept so strednou prioritou.“
Spracovanie modelom: Hostiteľ odošle vašu požiadavku a príslušné definície nástrojov LLM.
Výber nástroja: LLM vygeneruje štruktúrovanú požiadavku na nástroj, v ktorej určí nástroj a jeho vstupy: add-task s parametrami title: Skontrolovať koncept a priority: Medium. Hostiteľ overí, či je akcia povolená, a odovzdá požiadavku klientovi MCP, ktorý odošle správu JSON-RPC.
Požiadavka: Klient MCP odošle svojmu serveru MCP požiadavku tools/call.
Vykonanie nástroja: Server MCP zavolá API aplikácie na správu úloh a vytvorí novú úlohu so zadaným názvom a prioritou.
Vrátenie výsledku: Server odošle výsledok späť klientovi MCP, ktorý ho odovzdá hostiteľovi. Hostiteľ ho pridá k informáciám poskytnutým LLM.
Generovanie odpovede: LLM na základe výsledku vygeneruje odpoveď pre používateľa, napríklad: „Vytvoril som úlohu skontrolovať koncept so strednou prioritou.“

MCP a tradičná architektúra API sa často zamieňajú, no ide o vzájomne sa dopĺňajúce technológie. MCP bol navrhnutý špeciálne pre aplikácie založené na AI. Odbúrava vysokú náročnosť na údržbu, ktorú prináša implementácia a správa viacerých pevne naprogramovaných pripojení API.

Keďže MCP poskytuje hostiteľskej aplikácii jediné pripojenie na každého poskytovateľa funkcií alebo interný zdroj, pomáha riešiť problém nafúknutého vstupného kontextu (s výpisom všetkých API) alebo obmedzených aplikačných skriptov založených na API.

Servery MCP namiesto toho môžu sprístupňovať API (alebo skôr funkcie, ktoré API volajú) ako súčasť svojho zoznamu nástrojov. Vždy, keď poskytovateľ aktualizuje svoju aplikáciu a pribudne nové API alebo sa zmení dokumentácia, jednoducho aktualizuje server MCP. Na strane hostiteľskej aplikácie nie sú potrebné žiadne zmeny kódu.

Bezpečnosť MCP je od jeho uvedenia predmetom mnohých diskusií. Hoci sa vo všeobecnosti považuje za bezpečnú technológiu, existuje niekoľko bezpečnostných rizík, z ktorých mnohé sa výraznejšie prejavujú v zložitých implementáciách architektúry.

Architektúra MCP má tieto potenciálne slabé miesta:

Prompt injection: Používateľ vloží do externých údajov škodlivý prompt, ktorý model AI nesprávne interpretuje ako pokyn.
Prístup s nadmernými oprávneniami: Servery MCP môžu potenciálne sprístupniť modelu AI veľké množstvo nástrojov, čo môže zvýšiť riziko bezpečnostných problémov (tzv. blast radius, teda rozsah možného dopadu).
Náhodné úniky údajov: Pri nesprávne nakonfigurovaných implementáciách sa môže stať, že sa citlivé informácie, napríklad kľúče API alebo prihlasovacie údaje k databáze, dostanú k LLM.
Manipulácia s lokálnym systémom: Lokálne servery MCP sú voči problémom lokálneho systému, napríklad škodlivým skriptom, rovnako zraniteľné ako akékoľvek iné aplikácie, pričom navyše môžu mať následné škodlivé dopady na agentické systémy AI.

Žiadny z týchto problémov nie je neprekonateľný. Na zaistenie bezpečnosti systému často stačia zavedené opatrenia. Opatrenia, ako je zapojenie človeka do procesu, presadzovanie prísnych kontrol citlivých údajov a ochrana pred útokmi na server, patria k bežným postupom.

MCP sa osvedčil ako užitočný a obľúbený otvorený štandard pre vývojárov. Prekonáva mnohé problémy pevne naprogramovaných API v aplikáciách založených na LLM a výrazne znižuje programátorskú záťaž vývojárov.

Základná architektúra hostiteľov a serverov MCP takmer určite zostane aj v budúcnosti rovnaká. Budúce inovácie sa budú sústreďovať na pokročilé agentické schopnosti vo viacstupňových pracovných postupoch.

Okrem toho bude s implementáciou týchto agentických funkcií potrebné silnejšie bezpečnostné zabezpečenie a s rastúcim rozsahom a zložitosťou systémov AI aj škálovateľná architektúra, najmä v transportnej vrstve.

Čo je architektúra MCP?

Komponenty architektúry MCP: hostitelia, klienti a servery

Hostiteľ

Klient

Server

Čo je dátová vrstva v architektúre MCP?

Čo je transportná vrstva v architektúre MCP?

Čo je viacnájomnícka architektúra MCP?

Diagram architektúry MCP: podrobný postup krok za krokom

Čím sa architektúra MCP líši od tradičnej architektúry API?

Je architektúra MCP bezpečná?

Aká je budúcnosť architektúry MCP?