Architektura MCP: Kompletní technický rozbor s diagramy

Architektura MCP je základní soubor komponent a komunikačních pravidel, které umožňují fungování MCP (Model Context Protocol). MCP je open-source standard a architektura MCP je infrastruktura, na které tento standard běží.

Každá architektura MCP obsahuje tři základní komponenty, kolem nichž je postavena: hostitele, klienta a server. Komunikační rámec MCP se často popisuje jako složený z datové vrstvy a transportní vrstvy. Datová vrstva je soubor pravidel určujících formát zpráv (požadavky MCP se odesílají ve formátu JSON-RPC 2.0). Transportní vrstva tyto zprávy přenáší a pro externí připojení využívá Streaming HTTP.

Architektura MCP je serverový rámec, který implementuje Model Context Protocol – otevřený standard pro propojení modelů AI s nástroji, se zdroji, jako jsou databáze, a s prompty, které rozšiřují vstupní kontext. Souhrnně se označují jako „primitiva“. Architektura MCP v konečném důsledku umožňuje LLM zjistit, které nástroje jsou k dispozici, a spouštět pracovní postupy, a to bez nutnosti pravidelných aktualizací na straně klienta.

Diagram architektury MCP: aplikace AI si vyměňuje požadavky se serverem MCP, který poskytuje nástroje, zdroje a prompty.

Od doby, kdy ji představila společnost Anthropic, se architektura MCP v pracovních postupech AI široce rozšířila. Je to dáno především tím, že nahrazuje systémy náročnější na údržbu, například systémy postavené na několika připojeních přes API, aniž by se snížil výkon. Protože veškerá dostupná funkcionalita se nachází za serverem MCP, stačí jediné připojení a aktualizace i nové funkce jsou klientské aplikaci okamžitě k dispozici.

MCP poskytuje LLM způsob, jak zjišťovat a volat nástroje, prompty a zdroje, které mají k dispozici buď v lokálním systému hostitelské aplikace, nebo od externího poskytovatele.

V případě nástrojů, které poskytují přístup k externí funkcionalitě, spočívá zjišťování v tom, že hostitel zavolá na serveru MCP tools/list, aby zjistil, které nástroje jsou k dispozici. LLM (nebo v některých případech hostitel) si pak může přečíst popisy dostupných nástrojů a podle potřeby si je vyžádat. Prompty a zdroje používají podobný postup.

Diagram komponent architektury MCP: hostitel obsahující LLM, orchestrátor a klienta se připojuje k serveru MCP ve dvou krocích – nejprve zjišťování, poté požadavky – a server MCP zpřístupňuje nástroje, zdroje a prompty.

To je v kontrastu s architekturou založenou na API na míru, která byla ve vývoji softwaru normou a v níž se funkce mimo aplikaci musely volat přes vyhrazená připojení s přesně formátovanými požadavky.

Hostitelská aplikace je centrální orchestrační platforma a připojuje se k LLM. Jako hostitelé v systému MCP mohou fungovat známé nástroje, jako je Perplexity a Claude Desktop.

V jednoduchém pracovním postupu položí uživatel otázku prostřednictvím chatovacího rozhraní. Orchestrační komponenta hostitele pak k otázce přidá kontext a sdělí LLM, která primitiva MCP jsou k dispozici, spolu s popisem jejich schopností.

Klient je softwarová komponenta v aplikaci AI. MCP poskytuje standardní rozhraní, přes které klient komunikuje s interními i externími servery MCP na základě pokynů hostitele nebo LLM. Jeho úkolem je navázat připojení, formátovat zprávy JSON-RPC, odesílat požadavky a přijímat odpovědi.

Pojmy „hostitel MCP“ a „klient MCP“ se někdy používají zaměnitelně. Rozlišovat je je však užitečné, protože hostitel, jako je Perplexity, může současně orchestrovat více klientů MCP. Složitý pracovní postup AI může vyžadovat přístup k desítkám, nebo dokonce stovkám samostatných serverů MCP a každý z nich bude používat samostatné připojení.

Diagram hostitele MCP, jako je Perplexity, který orchestruje tři klienty MCP, z nichž každý je připojen k vlastnímu serveru MCP, například k databázi, souborům nebo externímu API.

Server zpřístupňuje všechny nástroje, které může nástroj založený na AI používat. Z hlediska architektury server MCP interpretuje příchozí požadavek a v případě potřeby se připojí k požadovaným primitivům.

Servery MCP mohou poskytovat přístup ke třem kategoriím primitiv:

Nástroje: Jde v podstatě o externí softwarové funkce. Vezměme si tradiční přístup založený na API: aplikace pro webovou analytiku může načítat data pomocí formátovaného požadavku na externí server. V architektuře MCP je veškerá funkcionalita třetí strany od daného poskytovatele dostupná přes jediné připojení a požadavky se vytvářejí podle standardních pravidel formátování.
Zdroje: Zdroje jsou datové zdroje, které poskytují kontext určený pouze pro čtení. Dobrým příkladem jsou databázová schémata. Server MCP zpřístupňuje hostiteli různé dostupné zdroje informací. Pokud hostitel odešle do databáze dotaz, například pomocí vyhledávání SQL vygenerovaného LLM, považuje se to za požadavek na nástroj.
Prompty: Jde o opakovaně použitelné šablony promptů, které LLM pomáhají provádět konkrétní úkoly. Uživatel nebo hostitel zavolá prompt místo nástroje, protože k dokončení úkolu potřebuje předpřipravené pokyny. Přednastavené úkoly v hostitelské aplikaci, například možnost „zkontrolovat kód“ nebo „analyzovat data“, jsou často uloženy jako prompty, které si uživatel může vybrat.

Za zmínku také stojí, že MCP a API nejsou vzájemně se vylučující technologie. Server MCP může zpřístupňovat volání API, která jsou k dispozici v reakci na požadavek na zjišťování. Klíčové je, že jejich údržba je na poskytovateli MCP, nikoli na klientovi.

Datová vrstva v architektuře MCP je soubor pravidel, která definují formát požadavků, odpovědí a oznámení. Standardním jazykem zpráv je JSON-RPC.

Každá architektura MCP se řídí základním postupem: (1) inicializace a zjišťování ze strany hostitele, (2) odpověď serveru MCP a (3) volání ze strany hostitele (o kterém někdy rozhoduje LLM), přičemž každá fáze představuje samostatnou zprávu JSON.

Diagram datové vrstvy MCP: uživatel odešle prompt hostitelské aplikaci, v níž LLM spolupracuje s klientem MCP; klient odešle požadavek serveru MCP (nástroje, zdroje, prompty) a obdrží výsledek a hostitel vrátí uživateli odpověď.

Podívejme se na dvou příkladech, jak funguje zjišťování nástrojů (stejně to může platit i pro zdroje nebo prompty):

Zjištění nástrojů před generováním LLM: Hostitel spustí klienta MCP, který odešle požadavek tools/list (seznam dostupných nástrojů serveru MCP). LLM tento seznam během procesu generování prověří a určí, zda je potřeba konkrétní nástroj, zdroj nebo prompt.
Umožnění LLM spustit vyhledávání: V agentním systému přidá hostitel do vstupního kontextu možnost zjišťování, například search-tools, a LLM si může v případě potřeby vyžádat vyhledávání.

Nástroje, které jsou povětšinou funkcemi externích aplikací, obvykle vybírá LLM nebo hostitel. Zdroje a prompty se obvykle vyžadují na pokyn uživatele nebo je vyžaduje hostitel.

Takto vypadá požadavek tools/list na server MCP z vymyšlené aplikace pro 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 příkladu “id”:101 identifikuje požadavek pomocí ID, aby klient mohl přiřadit odpovědi, a pole “params” obsahuje další informace o klientovi, například název klienta (notes-app-client) a jeho schopnosti.

V odpovědi server MCP vrátí definice nástrojů, které obsahují názvy dostupných nástrojů a související podrobnosti. Seznam může například obsahovat nástroj add-task, který aplikaci pro poznámky umožňuje vytvářet úkoly v připojené aplikaci pro správu úkolů nebo v kalendáři a přiřadit každému úkolu název a prioritu.

Takto může vypadat požadavek:

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” sděluje serveru MCP, že jde o volání nástroje, “name” určuje, který nástroj se má zavolat, a “arguments” dodává požadované vstupy.

Pokud datová vrstva představuje co spojení mezi klientem a serverem MCP, transportní vrstva představuje jak. Definuje způsob, jakým se zprávy přenášejí: konkrétní kanál a pravidla, jimiž se řídí doručování požadavků a odpovědí.

MCP má dvě transportní cesty:

Standardní vstup/výstup: Používá se, když server MCP běží ve stejném lokálním prostředí jako hostitelská aplikace. Klient zapíše požadavek JSON na standardní vstup serveru. Server ho přečte, provede požadovanou operaci a zapíše odpověď na standardní výstup.
Streamable HTTP: Když server MCP běží mimo hostitelskou aplikaci, klient MCP odesílá požadavky na server pomocí HTTP POST. Server odpoví buď jedinou zprávou JSON, nebo streamem Server-Sent Events (SSE) – trvalým „naslouchacím“ kanálem, který mu umožňuje vracet v průběhu času více zpráv.

Multitenantní architektura MCP je typ implementace, který dokáže současně obsluhovat více uživatelů (tenantů).

Tenantem zde může být jednotlivec, skupina jednotlivců nebo organizace. Implementace může spočívat ve spuštění samostatného serveru MCP pro každého tenanta, v poskytnutí přístupu k jednomu sdílenému serveru nebo v umístění sady serverů za centrální bránu. Pokud se použije brána, směruje požadavky na správné koncové body podle identity uživatele nebo povahy požadavku.

Funguje na stejném základním principu jako standardní architektura MCP, ale jednotlivé požadavky uživatelů probíhají ve vlastním pracovním prostoru (i když to znamená sdílené zdroje) a ověřují se samostatně. Je běžná v podnikových scénářích a často se upřednostňují sdílené zdroje, protože provoz více serverů MCP by byl zbytečně nákladný.

Jak vypadá kompletní požadavek MCP v praxi? Existuje osm základních fází, z nichž každá zahrnuje samostatnou komponentu architektury.

Vývojový diagram kompletního požadavku MCP v osmi krocích: zjištění nástrojů, vstup uživatele, zpracování modelem, výběr nástroje, požadavek, spuštění nástroje, výsledek a generování odpovědi.

Takto vypadá volání nástroje MCP v praxi na předchozím příkladu aplikace pro poznámky připojené ke službě pro správu úkolů:

Zjištění nástrojů: Aplikace pro poznámky (hostitel) si pomocí svého klienta MCP vyžádá dostupné nástroje serveru prostřednictvím požadavku tools/list. Server vrátí jejich názvy, popisy a očekávané vstupy, včetně těch pro nástroj add-task. K tomu může dojít ještě předtím, než odešlete prompt.
Vstup uživatele: Prostřednictvím chatbota v aplikaci odešlete požadavek poznámkové aplikaci založené na LLM, například: „Vytvoř v mém kalendáři úkol zkontrolovat můj nový koncept se střední prioritou.“
Zpracování modelem: Hostitel odešle váš požadavek a příslušné definice nástrojů do LLM.
Výběr nástroje: LLM vygeneruje strukturovaný požadavek na nástroj, v němž určí nástroj a jeho vstupy: add-task s title: Zkontrolovat koncept a priority: Medium. Hostitel zkontroluje, zda je akce povolena, a předá požadavek klientovi MCP, který odešle zprávu JSON-RPC.
Požadavek: Klient MCP odešle svému serveru MCP požadavek tools/call.
Spuštění nástroje: Server MCP zavolá API aplikace pro správu úkolů a vytvoří nový úkol se zadaným názvem a prioritou.
Vrácení výsledku: Server odešle výsledek zpět klientovi MCP, který ho předá hostiteli. Hostitel ho přidá k informacím poskytnutým LLM.
Generování odpovědi: LLM použije výsledek k vygenerování odpovědi pro uživatele, například: „Vytvořil jsem úkol zkontrolovat koncept se střední prioritou.“

MCP a tradiční architektura API se často zaměňují, ale jde o vzájemně se doplňující technologie. MCP byl navržen speciálně pro aplikace založené na AI. Odstraňuje vysokou zátěž spojenou s údržbou při implementaci a správě několika napevno zakódovaných připojení přes API.

Tím, že MCP poskytuje hostitelské aplikaci jediné připojení pro každého poskytovatele funkcí nebo interní zdroj, pomáhá řešit problém přebujelého vstupního kontextu (výčtu všech API) nebo omezených aplikačních skriptů založených na API.

Servery MCP místo toho mohou zpřístupňovat API (nebo spíše funkce, které API volají) jako součást svého seznamu nástrojů. Kdykoli poskytovatel aktualizuje svou aplikaci a objeví se nové API nebo se změní dokumentace, stačí aktualizovat server MCP. Na straně hostitelské aplikace nejsou nutné žádné změny kódu.

Bezpečnost MCP je od jeho zavedení předmětem rozsáhlých debat. Přestože je obecně považován za bezpečnou technologii, existuje několik bezpečnostních rizik, z nichž mnohá se výrazněji projevují ve složitých implementacích architektury.

Architektura MCP má tyto potenciální slabiny:

Prompt injection: Uživatel vloží do externích dat škodlivý prompt, který model AI chybně vyhodnotí jako pokyn.
Přístup s nadměrnými oprávněními: Servery MCP mohou modelu AI potenciálně zpřístupnit velké množství nástrojů, což může zvýšit potenciál bezpečnostních problémů (rozsah možných škod, tzv. blast radius).
Nechtěné úniky dat: U špatně nakonfigurovaných implementací se může stát, že se do LLM dostanou citlivé informace, jako jsou klíče API nebo přihlašovací údaje k databázi.
Manipulace s lokálním systémem: Lokální servery MCP jsou vůči problémům lokálního systému, jako jsou škodlivé skripty, stejně zranitelné jako jakékoli jiné aplikace – s tím rozdílem, že mohou mít navíc škodlivé následné dopady na agentní systémy AI.

Žádný z těchto problémů není nepřekonatelný. K zajištění bezpečnosti systému často stačí zavedená opatření. Opatření, jako je zapojení člověka do rozhodovací smyčky, vynucování přísných kontrol citlivých dat a ochrana před útoky na servery, jsou běžnou praxí.

MCP se ukázal jako užitečný a oblíbený otevřený standard pro vývojáře. Odstraňuje řadu problémů napevno zakódovaných API v aplikacích založených na LLM a výrazně snižuje programátorskou zátěž vývojářů.

Základní architektura hostitele a serveru MCP téměř jistě zůstane i nadále stejná. Budoucí inovace se zaměří na pokročilé agentní schopnosti napříč vícekrokovými pracovními postupy.

Kromě toho budou se zaváděním těchto agentních funkcí zapotřebí silnější bezpečnostní opatření a s tím, jak se systémy AI budou stávat rozsáhlejšími a složitějšími, také škálovatelná architektura, zejména v transportní vrstvě.

Co je architektura MCP?

Komponenty architektury MCP: hostitelé, klienti a servery

Hostitel

Klient

Server

Co je datová vrstva v architektuře MCP?

Co je transportní vrstva v architektuře MCP?

Co je multitenantní architektura MCP?

Diagram architektury MCP: Podrobný průvodce krok za krokem

Čím se architektura MCP liší od tradiční architektury API?

Je architektura MCP bezpečná?

Co čeká architekturu MCP v budoucnu?