Zkratka proModel Context Protocolmodel kontext protokolTakéMCP, MCP server, MCP protokolPokročilý
Definice
Model Context Protocol je otevřený protokol, který jazykovým modelům zpřístupňuje externí data a akce přes jednotné rozhraní. Klient v AI aplikaci se připojí k MCP serveru a ten nabídne nástroje, zdroje dat a předpřipravené prompty. Komunikace probíhá zprávami ve formátu JSON-RPC 2.0, takže jeden server funguje s libovolným kompatibilním klientem.
Než se na to spolehnete: MCP je rychle se vyvíjející specifikace (verze protokolu se datují a mění, transport HTTP+SSE byl nahrazen streamovatelným HTTP), proto jsem se vyhnul konkrétním číslům verzí a datům. Doména modelcontextprotocol.io ani jsonrpc.org nejsou na povoleném seznamu domén: zdroj JSON-RPC jsem uvedl přesto, protože jde o kanonickou specifikaci, ale server ho pravděpodobně zahodí. Odkaz na draft OAuth 2.1 v
Jaký problém MCP řeší
Napojení jazykového modelu na firemní data bylo dlouho práce na míru: každá aplikace si psala vlastní konektor k Jiře, k databázi, k souborovému úložišti. Deset aplikací a deset systémů znamenalo sto integrací. Model Context Protocol tuhle matici rozřezává na dvě strany: kdo píše aplikaci, implementuje klienta; kdo vlastní data, vystaví server. Obě strany se potkají na společném protokolu a nemusejí o sobě předem vědět.
Tři věci, které server nabízí
Specifikace rozlišuje tři druhy schopností a rozdíl mezi nimi je zásadní pro bezpečnost. Tools jsou funkce, které model může zavolat a které mají vedlejší efekt: založit ticket, spustit dotaz, poslat zprávu. Resources jsou data ke čtení, adresovaná pomocí URI, a jejich načtení řídí aplikace, ne model. Prompts jsou pojmenované šablony, které server nabízí uživateli jako hotový postup. Vedle toho může server požádat klienta o dokončení modelem (sampling), takže si nemusí držet vlastní klíč k LLM.
Průběh spojení
Klient a server si nejdřív vymění zprávu initialize, ve které si oznámí verzi protokolu a podporované schopnosti. Teprve pak se klient ptá na seznam nástrojů (tools/list) a předává jejich popisy a JSON schémata modelu. Když model usoudí, že nástroj potřebuje, aplikace zavolá tools/call a výsledek vrátí do konverzace. Transport je buď standardní vstup a výstup lokálního procesu (stdio), nebo HTTP se streamováním pro vzdálené servery.
Proč zrovna JSON-RPC
JSON-RPC 2.0 je záměrně nudná volba: má definované požadavky, notifikace i chybové kódy, je stavově nenáročný a existují k němu knihovny prakticky všude. MCP nad ním přidává jen sémantiku schopností, takže implementace jednoduchého serveru je otázka desítek řádků.
Kde je hranice důvěry
Popis nástroje se dostane do kontextu modelu, a tím se stává vstupem, kterému nelze slepě věřit. Škodlivý server může do popisu propašovat instrukce (prompt injection) nebo se vydávat za jiný. Proto specifikace trvá na tom, aby volání nástrojů potvrzoval člověk a aby aplikace jasně ukazovala, který server co nabízí. U vzdálených serverů se autorizace řeší přes OAuth 2.1; místní server běží s právy uživatele, což je samo o sobě dost velká pravomoc.
Vztah k function callingu a k RAG
Function calling je schopnost modelu vygenerovat strukturované volání funkce. MCP neřeší, jak model volání vymyslí, ale odkud se seznam funkcí bere a jak se vykoná. Podobně se doplňuje s RAG: MCP server může vyhledávání v znalostní bázi vystavit jako nástroj, ale samotné vyhledávání zůstává úlohou té znalostní báze.
Kdy se MCP nevyplatí
Pro jedinou aplikaci s jediným pevným API je přímé volání jednodušší: protokol přidává vrstvu, proces navíc a nové bezpečnostní rozhraní. Smysl začíná dávat ve chvíli, kdy stejný server chce používat víc klientů, nebo když integrace vzniká mimo tým, který píše aplikaci.
Příklady z praxe
Asistent nad firemní Jirou
Vývojářský tým připojí do svého AI klienta MCP server pro Jiru. Server vystaví nástroje jako vyhledání issue, změnu stavu a přidání komentáře. Vývojář napíše „shrň mi otevřené bugy ve sprintu a přiřaď je“, model si vyžádá volání nástrojů a uživatel každou zapisující akci potvrdí. Stejný server pak beze změny použije i jiný klient.
Minimální server s jedním nástrojem
Server vystaví jediný nástroj pro převod měny. Klient si vyžádá seznam nástrojů, dostane popis a JSON schéma vstupu a předá je modelu. Schéma je důležité: podle něj model pozná, že částka je číslo a měna třípísmenný kód, a klient může vstup ověřit ještě před vykonáním.
{ "jsonrpc": "2.0", "id": 7, "method": "tools/call", "params": { "name": "prevod_meny", "arguments": { "castka": 1500, "z": "CZK", "na": "EUR" } } }
Časté omyly
- MýtusMCP je API od jednoho dodavatele, takže si tím zavřu dveře.
- Ve skutečnostiModel Context Protocol má veřejně publikovanou specifikaci a otevřené SDK ve více jazycích. Server napsaný podle specifikace funguje s jakýmkoli klientem, který protokol implementuje, nezávisle na tom, který model pod ním běží.
- MýtusKdyž připojím MCP server, model už si dokáže sám sáhnout na všechno.
- Ve skutečnostiModel sám nic nevolá. Návrh volání předává hostitelské aplikaci a ta rozhoduje, co se opravdu vykoná. Specifikace přímo počítá s tím, že zapisující akce schvaluje člověk.
- MýtusMCP nahrazuje RAG.
- Ve skutečnostiMCP je přenosová a integrační vrstva, ne způsob vyhledávání. Vektorové vyhledávání nad dokumenty může být jedním z nástrojů, které MCP server nabízí, ale kvalitu odpovědí určuje ta znalostní báze, ne protokol.
Časté dotazy
- Jaký je rozdíl mezi MCP serverem a běžným REST API?
- MCP server popisuje své schopnosti sám a strojově čitelně: klient se zeptá na seznam nástrojů a dostane jména, textové popisy a JSON schémata parametrů, které lze rovnou předat jazykovému modelu. REST API takový jednotný introspekční mechanismus nemá, popis bývá v OpenAPI dokumentu vedle a jeho podoba se liší projekt od projektu. MCP navíc definuje i směr od serveru ke klientovi, tedy notifikace o změnách a žádost o dokončení modelem. V praxi bývá MCP server tenkou vrstvou nad existujícím REST API.
- Jak zabezpečit vzdálený MCP server?
- Vzdálený MCP server se autorizuje podle OAuth 2.1: server vystupuje jako chráněný zdroj, tokeny vydává autorizační server a klient musí token ověřit pro konkrétní příjemce, aby nešlo token přeposlat jinam. K tomu patří běžná hygiena: HTTPS, krátká platnost tokenů, princip nejmenších oprávnění u účtu, pod kterým server pracuje, a logování volání nástrojů. Popisy nástrojů je vhodné považovat za nedůvěryhodný vstup a nepouštět je do systémového promptu bez kontroly.
- V jakých jazycích lze MCP server napsat?
- MCP server lze napsat v jakémkoli jazyce, který umí zpracovat JSON-RPC zprávy přes standardní vstup a výstup nebo přes HTTP. Oficiální SDK existují mimo jiné pro TypeScript, Python, Javu, C#, Kotlin a Go, ale nejsou podmínkou. Volba jazyka se obvykle řídí tím, kde už žije integrovaný systém: server nad interní databází se píše ve stejném zásobníku jako zbytek backendu, protože pak může sdílet ověřování, konfiguraci a přístupová práva.
- Kolik nástrojů má mít jeden MCP server?
- Počet nástrojů má praktický strop daný kontextovým oknem modelu: každý nástroj zabírá tokeny svým popisem a schématem, a čím delší je seznam, tím častěji model vybere špatně. Osvědčuje se držet server tematicky sevřený, řádově jednotky až nižší desítky nástrojů, a raději slučovat varianty do jednoho nástroje s parametrem než nabízet deset skoro stejných. Klienti obvykle umožňují jednotlivé nástroje vypnout, čehož se vyplatí využít.
Zdroje
- Model Context Protocol(otevře se v novém okně)
- The OAuth 2.1 Authorization Framework(otevře se v novém okně)
- OWASP Top 10 for Large Language Model Applications(otevře se v novém okně)
Související pojmy
