Co je MCP server? Jak fungují MCP a MCP UI v roce 2026

Dne 1. dubna 2025 zveřejnila společnost Invariant Labs nástroj jménem add. Vzal dvě čísla a vrátil jejich součet. Jeho popis ale obsahoval i blok označený IMPORTANT, v rozhraní klienta neviditelný, který modelu přikazoval přečíst ~/.cursor/mcp.json a ~/.ssh/id_rsa a oba soubory poslat ven přes nadbytečný parametr. Model poslechl. Uživatel viděl sčítání.

Tahle ukázka je nejlepší úvod do MCP serverů, jaký znám, protože ukazuje obě poloviny najednou. Protokol fungoval přesně podle návrhu: AI klient objevil nástroj, přečetl jeho popis a zavolal ho. Model důvěry byl ta část, kterou ještě nikdo nepostavil.

Co je MCP server

MCP server je program, který zpřístupňuje nástroje, data a prompty AI aplikacím přes Model Context Protocol (MCP). Oficiální dokumentace definuje MCP jako „open-source standard pro propojení AI aplikací s externími systémy“. AI klient, například Claude, ChatGPT, Visual Studio Code nebo Cursor, se k serveru připojí, zeptá se, co nabízí, a tyto schopnosti volá jménem uživatele.

Anthropic ohlásil MCP 25. listopadu 2024 spolu se šesti hotovými servery: Google Drive, Slack, GitHub, Git, Postgres a Puppeteer. OpenAI protokol přijal v březnu 2025. Google DeepMind následoval v dubnu. V prosinci 2025 Anthropic daroval protokol nadaci Agentic AI Foundation, účelovému fondu pod Linux Foundation, který spoluzaložily Anthropic, Block a OpenAI.

Problémem je násobení propojení. Před MCP si každá aplikace AI se zájmem o GitHub psala vlastní konektor a každý dodavatel vytvářel spojení pro každou aplikaci AI. Deset modelů a deset nástrojů mohlo znamenat sto integrací. MCP z toho dělá dvacet: klient implementuje protokol jednou a systém vystaví jeden server.

Berte ho jako přepravní kontejner AI integrací. Před kontejnery se v každém přístavu nakládal každý náklad ručně, s vlastními jeřáby a vlastní posádkou. Kontejner standardizoval krabici, takže jakákoli loď, jeřáb a kamion mohly převézt jakýkoli náklad. Nestandardizoval ale, co je uvnitř, a obsah nikdy nekontroloval. MCP je stejný obchod. Zapamatujte si tu druhou polovinu, vrátí se v části o bezpečnosti.

Jak MCP server funguje

Aktuální specifikace, verze 2026-07-28, používá zprávy JSON-RPC 2.0 mezi třemi rolemi. Její vlastní popis má tři řádky: hostitelé jsou „aplikace s LLM, které navazují spojení“, klienti jsou „konektory uvnitř hostitelské aplikace“ a servery jsou „služby, které poskytují kontext a schopnosti“.

Hostitel, klient, server

Hostitel je aplikace, do které píšete: Claude Desktop, IDE, Váš vlastní agent. Uvnitř běží jeden klient na každé spojení se serverem. Server sedí na druhé straně a mluví se skutečným systémem, ať je to databáze Postgres, GitHub API nebo složka na Vašem disku. Hostitel rozhoduje, co model uvidí a co musí uživatel schválit. Server rozhoduje, co udělá systém pod ním.

1. Hostitel Claude Desktop · IDE · Váš vlastní agent

   ukazuje modelu nástroje, žádá uživatele o souhlas

2. Klient jeden na každé spojení se serverem

   mluví JSON-RPC přes stdio nebo Streamable HTTP

3. MCP server nástroje · zdroje · prompty

   popisuje, co nabízí, a provádí volání

4. Systém pod ním databáze · SaaS API · lokální soubory

   odvádí práci

Nástroje, zdroje a prompty

Server může nabízet tři druhy věcí:

• Nástroje (tools) jsou funkce, které model může spustit: create_issue, query_orders, send_email. Každý má název, popis a JSON Schema pro své vstupy.
• Zdroje (resources) jsou kontext a data, která čte uživatel nebo model: soubor, schéma databáze, záznam.
• Prompty jsou šablonové zprávy a postupy, které si uživatel může vybrat, například „shrň tento pull request“.

Nejvíc pozornosti dostávají nástroje, protože jednají. Ze stejného důvodu nesou i většinu rizika.

Volání nástroje krok za krokem

Revize 2026-07-28 udělala z MCP bezstavový protokol. Handshake initialize už neexistuje; každý požadavek nese verzi protokolu a schopnosti klienta v poli _meta a servery musí implementovat metodu server/discover, aby se klient mohl předem zeptat, co podporují. Jedno volání nástroje dnes probíhá takto:

1. Uživatel žádá: založ tiket na tuhle chybu

2. Krok 1

   Discover

   • Klient může zavolat server/discover kvůli verzím a schopnostem
3. Krok 2

   Seznam nástrojů

   • tools/list vrátí názvy, popisy a schémata vstupů
4. Krok 3

   Model vybere nástroj

   • Hostitel předá modelu definice nástrojů
5. Krok 4

   Souhlas uživatele

   • Podle specifikace musí hostitel před voláním jakéhokoli nástroje získat výslovný souhlas
6. Krok 5

   Volání

   • tools/call s argumenty, verze protokolu v _meta

7. Chybí vstup? Server vrátí input_required, klient zopakuje volání s odpověďmi

   Krok 6

   Výsledek

8. Výsledek se vrací modelu jako kontext

Krok 6 je v této revizi nový. Server, který potřebuje další informace, už neposílá klientovi vlastní požadavek. Vrátí výsledek označený input_required, klient získá odpověď a původní volání zopakuje. Specifikace tomu říká vzor Multi Round-Trip Request.

Transporty: stdio a Streamable HTTP

Specifikace definuje dva standardní transporty:

• stdio: klient spustí server jako podproces a vyměňuje si s ním JSON-RPC zprávy oddělené novým řádkem přes standardní vstup a výstup. Tak běží většina lokálních serverů, a to znamená, že server běží na Vašem počítači s Vašimi oprávněními.
• Streamable HTTP: každá zpráva je HTTP POST na jediný endpoint a odpovědi se vracejí jako JSON objekt nebo jako proud událostí vázaný na požadavek. Tak běží vzdálené, hostované servery.

Starší transport HTTP+SSE je formálně zastaralý. Revize 2026-07-28 také odstranila relace na úrovni protokolu i hlavičku Mcp-Session-Id; server, který potřebuje stav mezi voláními, si dnes vytvoří vlastní identifikátor a dostává ho zpět jako běžný argument nástroje.

Autorizace

Autorizace je v MCP volitelná a týká se jen HTTP. U stdio specifikace říká, že servery mají brát přihlašovací údaje z prostředí. U HTTP se chráněný MCP server chová jako OAuth 2.1 resource server. Musí zveřejnit OAuth Protected Resource Metadata (RFC 9728), aby klienti našli jeho autorizační server. Klienti musí uvést přesný server, pro který je token určen (resource indicators podle RFC 8707). Servery musí odmítnout každý token, který nebyl vydán pro ně, a bezpečnostní doporučení označují „token passthrough“, tedy předání tokenu klienta beze změny dalšímu API, za výslovně zakázané.

To poslední pravidlo je důležitější, než vypadá. Server, který přeposílá jakýkoli token, který dostane, se stává proxy pro kohokoli, kdo nějaký token drží.

Co přidává MCP UI: servery, které vracejí rozhraní

Textové odpovědi přestávají fungovat ve chvíli, kdy uživatel potřebuje porovnat čtyřicet řádků, upravit formulář s dvanácti poli nebo schvalovat dávku změn jednu po druhé. „MCP UI“ je název, pod kterým lidé řešení hledají: server vrátí interaktivní rozhraní, které se vykreslí přímo v AI klientovi, vedle konverzace.

Stav je třeba popsat přesně. Nápad začal jako komunitní projekt MCP-UI. OpenAI postavilo podobný mechanismus v Apps SDK. Projekt MCP navrhl společný standard s oběma 21. listopadu 2025 a 26. ledna 2026 zveřejnil MCP Apps jako první oficiální rozšíření MCP. Balíčky MCP-UI nyní standard implementují a zůstávají prostorem pro zkoušení dalších vylepšení.

MCP UI tedy dnes znamená MCP Apps. Je oficiální a je to rozšíření, ne jádro protokolu. Rozšíření jsou volitelná: musí je podporovat klient i server, a dokumentace otevřeně říká, že „podpora hostitelů se liší podle klienta“. Dokumentace MCP Apps uvádí jako podporované hostitele Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam a Archestra.AI. Server, jehož nástroje vracejí UI, musí pořád fungovat i v klientovi, který zobrazuje jen text.

Mechanicky znovu používá vlastní stavební prvky MCP:

1. Popis nástroje obsahuje _meta.ui.resourceUri, které ukazuje na zdroj ui://.
2. Hostitel tento zdroj, HTML stránku s jejími skripty, načte a může ho přednačíst ještě před voláním nástroje.
3. Hostitel ho vykreslí v sandboxovaném iframe, který nemůže číst nadřazenou stránku, její cookies ani úložiště.
4. Aplikace a hostitel spolu mluví přes postMessage v JSON-RPC dialektu MCP. Aplikace může žádat o volání nástrojů a hostitel rozhoduje, která povolí.

Náklady jsou skutečné. Najednou dodáváte webový front-end uvnitř cizí aplikace, s content security policy, kterou musíte deklarovat, s pravidly vykreslování, která neřídíte, a s textovou náhradou pro každého hostitele, který rozhraní ignoruje. Výhra je v tom, že schvalování přestane být přepisem chatu. Seznam vhodných použití v dokumentaci končí slovy „schvalování výkazů výdajů, kontrola změn v kódu nebo třídění issues“, a to je poctivý střed celé věci: MCP UI je nejlepší na rozhodování, ne na ozdoby.

Příklad Tajo pouze ke čtení

Rozhraní Alto MCP v Tajo obsahuje query_contacts, které hledá kontakty uložené v připojeném pracovním prostoru. Vyhledejte jeden existující kontakt podle e-mailu a prohlédněte ID, stav souhlasu s e-mailem a čas posledního pozorování. Samostatný nástroj get_contact_topic_status čte jeho tematická přihlášení.

Jde o čtení z pracovního prostoru. Nenačítají čerstvý stav přímo od poskytovatele, nespouštějí synchronizaci ani neposílají zprávy. Nedokazují ani provoz všech konektorů. Chybějící nebo stará data zkoumejte u zdroje. Prázdný výsledek nedokazuje, že člověk v Brevu není.

Podle dokumentace MCP Tajo připojte podporovaného klienta a zjistěte, které nástroje se skutečně vystavují Vašemu oprávněnému prostoru. Interaktivní panel pomáhá, pokud hostitel podporuje MCP Apps. Textový výsledek přesto musí vysvětlit výsledek akce.

Volání nástroje není trvalá synchronizace

Opakovaná synchronizace vyžaduje také plán, stabilní identitu záznamů, uložený postup, rozhodování o opakování a záznam dokončených zápisů. To patří vykonávající aplikaci. MCP standardizuje přístup k nástrojům; jejich výpis tato pravidla nedodá.

Po vypršení času lze čtení obvykle opakovat. Odeslání nebo platba už mohla proběhnout. Uchovejte záznam o vykonání a ověřte výsledek před dalším pokusem. Jistota modelu nedává oprávnění ani nedělá opakování bezpečným.

Průvodce API Brevo vysvětluje cílový zápis pro konkrétní kontaktní cestu. Průvodce reverse ETL ukazuje, kdy vypočítaná pole potřebují vlastní udržovanou synchronizaci.

Bezpečnostní účet přichází spolu s protokolem

Námitka si zaslouží zaznít celá: „MCP dává pravděpodobnostnímu modelu seznam funkcí, které umí mazat data a posílat e-maily, a pak věří textu napsanému cizími lidmi, který je popisuje. To není integrační standard. To je útok na dodavatelský řetězec se specifikací.“ Většina z toho je pravda. Specifikace s premisou souhlasí. Její bezpečnostní část říká, že nástroje „představují libovolné spouštění kódu a je třeba s nimi zacházet s náležitou opatrností“, že popisy nástrojů „by měly být považovány za nedůvěryhodné, pokud nepocházejí z důvěryhodného serveru“, a že MCP „nemůže tyto bezpečnostní principy vynutit na úrovni protokolu“.

Dosavadní bilance vypadá takto:

• Otrávení nástrojů (tool poisoning). Zveřejnění Invariant Labs z dubna 2025, výše popsaný nástroj add. Stejný příspěvek popsal rug pull, kdy server změní popis nástroje až poté, co jste ho schválili, a shadowing, kdy jeden škodlivý server přepíše chování modelu vůči jinému, důvěryhodnému serveru.
• Kompromitace lokálního serveru. V červenci 2025 JFrog zveřejnil CVE-2025-6514 v mcp-remote ve verzích 0.0.5 až 0.1.15, která škodlivému serveru umožnila spouštět příkazy na počítači uživatele. Téhož léta zasáhla CVE-2025-49596 vlastní MCP Inspector od Anthropicu, který se ve výchozím nastavení dodával bez autentizace.
• Nafukování scopes. Oficiální bezpečnostní doporučení ten vzor pojmenovávají: tokeny s oprávněním files:* nebo admin:* udělené hned na začátku, protože server vypsal všechny scopes a klient si o všechny řekl.
• Oficiální obavy. V květnu 2026 americká Národní bezpečnostní agentura (NSA) uvedla, že „rychlé šíření MCP předběhlo vývoj jeho bezpečnostního modelu“.

Kde se námitka mýlí, je závěr. Řešením nikdy nebylo přestat propojovat modely se systémy; týmy to už dělaly se surovými API klíči vloženými do promptů a skriptů, úplně bez auditní stopy. Řešením je zacházet s MCP serverem jako s jakoukoli jinou privilegovanou závislostí:

• Instalujte servery jen ze zdrojů, kterým byste svěřili stejné přihlašovací údaje i mimo MCP.
• Dejte přednost vzdáleným serverům s OAuth a úzkými scopes před lokálními binárkami s dlouhodobými klíči.
• U každého zápisu vyžadujte lidské schválení a zaznamenávejte, kdo co schválil.
• Zamkněte verze serverů a znovu je zkontrolujte, když se změní popis nástroje.
• Nabízejte nástroje šité na úkoly, ne celé API; model nemůže zneužít endpoint pro mazání, který nikdy nebyl zpřístupněn.

Protokol standardizoval krabici. Kontrola nákladu je pořád Vaše práce.

Postavit MCP server, nebo použít existující

Veřejné katalogy jako mcp.so shromažďují servery od komunity a mnoho SaaS dodavatelů zveřejňuje vlastní. Například Brevo nabízí MCP server, který je rozdělený i na jednotlivé servery, takže agent může dostat kontakty bez kampaní. Rozhodnutí se týká méně námahy a víc toho, kdo má vlastnit tvar nástrojů.

Jaký MCP server má Váš agent použít?

1. Dodavatel zveřejňuje server, který úkol pokrývá

   Použijte server dodavatele

   Drží krok s API a dodavatel ho udržuje.

2. Jeden systém, ale potřebujete méně akcí nebo bezpečnější akce

   Použijte ho se zúženým rozsahem

   Udělte minimální scopes a zpřístupněte jen skupiny nástrojů, které agent potřebuje.

3. Interní data nebo systém bez serveru

   Postavte malý server

   Několik nástrojů šitých na úkoly nad Vaším vlastním API, s vlastní autentizací.

4. Úkol zasahuje do dvou a více systémů

   Postavte nebo převezměte řízenou vrstvu

   Jedna sada nástrojů, pravidel souhlasu a auditní historie napříč všemi.

Postavit základní server je ta snadná část. S oficiálním SDK je funkční stdio server s jedním nástrojem práce na jedno odpoledne. Náklady přijdou později: OAuth pro HTTP verzi, zastarávání (revize 2026-07-28 označila za zastaralé Roots, Sampling a Logging i Dynamic Client Registration) a trvalá práce na popisech nástrojů, které model přečte správně. Obalit API stylem jeden endpoint, jeden nástroj je nejčastější chyba. Každý popis nástroje je text, který musí model přečíst a zvážit, takže krátký seznam nástrojů šitých na úkoly porazí celé API.

MCP, API, integrace a iPaaS

MCP nenahrazuje API. Téměř každý MCP server je obal kolem nějakého API. Práce se pořád odehrává v API, s jeho limity, datovým modelem a zvláštnostmi. MCP mění, kdo ho může volat: model, za běhu, který volání vybírá podle popisu, místo vývojáře, který ho předem natvrdo zapíše do kódu.

Tento rozdíl vede čistou hranici vůči dvěma dalším věcem, se kterými se MCP plete:

• Integrace a iPaaS (hlavní platformy srovnáváme zde) přesouvají data podle plánu nebo na spouštěč, deterministicky, ať je zrovna někdo v chatu, nebo ne. Noční synchronizace 40 000 objednávek do CRM by neměla záviset na tom, že se model rozhodne udělat 40 000 volání nástrojů.
• Reverzní ETL posílá modelovaná data z datového skladu zpět do provozních nástrojů. Co je reverzní ETL a kdy se hodí je samostatné téma, a jde o pipeline, ne o konverzaci.
• MCP slouží chvílím, kdy se člověk nebo agent potřebuje na něco zeptat, něco prohlédnout nebo něco udělat napříč těmito systémy, na vyžádání.

Chyba se děje oběma směry. Jedny týmy staví MCP servery na hromadnou synchronizaci a dostanou pomalé, drahé a neopakovatelné pipeline. Jiné týmy pečlivě postaví integrace a pak dají svému AI asistentovi surový API klíč, aby se nad nimi dotazoval, a dostanou neřízená zadní vrátka.

U podporované integrace musí trvalá úloha a nástroje pro její kontrolu sdílet jasnou hranici oprávnění. Ověřte konektor, povolené akce a zaznamenané výsledky daného postupu. Dokumentace integrací rozlišuje návod k nastavení od cest, které ještě potřebují důkaz z produkce. MCP může vystavit oddělené schválené nástroje; seznam nedokazuje aktivní opakovanou synchronizaci ani všechny kontroly.

Za 22 měsíců se MCP dostal od šesti referenčních serverů k projektu Linux Foundation, kterým mluví Claude, ChatGPT, VS Code i Cursor. Propojit model se systémem je dnes ta levná část. Rozhodnout, co tam smí dělat, je ta skutečná práce.