Co je MCP a proč jím najednou mluví každý nástroj AI?
Po většinu poslední dekády znamenalo připojení modelu AI k nástrojům firmy vlastní integraci pro každou dvojici. Model Context Protocol, otevřený standard, který Anthropic představil v listopadu 2024, to nahradil jednou zástrčkou, která sedí všude — a OpenAI, Google i Microsoft ho od té doby všechny přijaly. Tady je, jak to doopravdy funguje, a skutečný kontrolní seznam, než některý z nich připojíte k datům svého týmu.
Otevřete desktopovou aplikaci Claude a požádejte ji, ať zkontroluje otevřené pull requesty týmu, a ona to prostě udělá. Ne proto, že by Anthropic vestavěl do Claude integraci s GitHubem. Proto, že někde — ať už váš IT tým, dodavatel, nebo vývojář na GitHubu — někdo napsal malý program, který mluví protokolem jménem MCP, a Claude už umí mluvit se vším, co jím mluví. Totéž teď platí pro ChatGPT, Gemini od Googlu a Microsoft Copilot. Tahle konvergence, víc než jakékoli jednotlivé vydání funkce, je důvod, proč se MCP stal tím, pro co téměř každý dodavatel AI poslední rok stavěl podporu.
Co MCP doopravdy je
MCP znamená Model Context Protocol. Anthropic ho navrhl a 25. listopadu 2024 zveřejnil specifikaci jako open source spolu s prvními SDK. Vlastní materiály k uvedení popsaly tu myšlenku analogií, která se uchytila: představte si MCP jako port USB-C pro aplikace AI — jeden fyzický standard konektoru místo jiného kabelu ke každému příslušenství. Při uvedení Anthropic uvedl první uživatele, kteří už stavěli podporu MCP do vlastních produktů, včetně firem Block a Apollo, které vyvíjejí podnikový software, a tvůrců vývojářských nástrojů Zed, Replit, Codeium a Sourcegraph. Desktopová aplikace Claude vyšla téhož dne se schopností spouštět servery MCP lokálně na vlastním počítači uživatele.
Problém, který řeší: N nástrojů krát M zdrojů dat
Problém, který MCP řeší, má jméno, které inženýři používají ledabyle: problém integrace N krát M. Řekněme, že firma používá pět nástrojů AI, které potřebují jednat s firemními daty — Claude, ChatGPT, GitHub Copilot, Cursor a interního bota podpory — a ta data žijí na osmi místech: Slack, GitHub, databáze Postgres, Salesforce, Notion, Google Drive, Jira a interní API. Bez sdíleného protokolu zabere užitečné propojení každého nástroje s každým zdrojem až čtyřicet samostatných integrací — pětkrát osm — každá s vlastním způsobem autentizace, vlastním zpracováním chyb a vlastní daní za údržbu pokaždé, když jedno z těch API změní tvar. Přidejte šestý nástroj AI a číslo vyskočí na čtyřicet osm. V praxi nikdo nepostavil všech čtyřicet. Každý dodavatel AI postavil jen hrstku, která podle něj stála za inženýrský čas, a všechno ostatní zůstalo ruční: kopírovat, vložit, znovu vysvětlit, opakovat.
MCP mění násobení na sčítání. Firma, která chce, aby Claude četl z její databáze Postgres, nestaví konektor Postgres specifický pro Claude. Staví — nebo znovu použije takový, který už někdo zveřejnil — jeden MCP server, který vystavuje Postgres, a ten server funguje s Claude, ChatGPT, Gemini nebo jakýmkoli jiným agentem kompatibilním s MCP bez dalšího kódu. Seznam, který Anthropic zveřejnil při spuštění, uváděl předpřipravené servery pro Google Drive, Slack, GitHub, Git, Postgres a nástroj na automatizaci prohlížeče jménem Puppeteer. Nešlo o to, že je všechny postaví Anthropic, ale o to, že to může udělat kdokoli, a katalog dostupných serverů vyrostl daleko za to, co by jedna firma dokázala obsadit lidmi.
Jak protokol doopravdy funguje
Po odstranění marketingového obalu je MCP poměrně prostý protokol typu klient–server, záměrně nenápadný. Definuje tři role. Host je aplikace, kterou člověk skutečně otevře — Claude Desktop, IDE jako Cursor, aplikace ChatGPT. Host v sobě nese MCP Client, který otevře přímé, stavové spojení s MCP Server — malým programem, který vystavuje jeden konkrétní systém: databázi, nástroj na tikety, souborový systém, interní API. Klient a server si vyměňují zprávy ve formátu JSON-RPC 2.0, lehkém formátu vzdáleného volání procedur, který je v existující infrastruktuře už běžný, přes jeden ze dvou transportů: stdio, když je server program běžící lokálně na stejném stroji, nebo Streamable HTTP, když je to hostovaná služba běžící někde jinde.
To, co server může vystavit, se redukuje na tři primitiva. Tools jsou funkce, které model může zavolat, aby provedl akci — create_task, run_query, send_message — a model podle konverzace rozhodne, kdy jednu zavolá. Resources jsou kontext jen pro čtení, který Host může načíst a předat modelu, aniž by o něj model musel žádat — obsah souboru, schéma databáze, tiket podpory. Prompts jsou opakovaně použitelné šablony spouštěné uživatelem — hotové „shrň toto vlákno“ nebo „sepiš aktualizaci stavu“, které člověk vyvolá výslovně, ne něco, co se model rozhodne udělat sám. Dobře postavený server je explicitní v tom, které ze tří nabízí pro danou schopnost, protože právě to rozlišení určuje, jestli připojený nástroj AI si může něco jen prohlížet, nebo to i měnit.
Kdo další to převzal a kdy
První měsíce MCP byly projektem samotného Anthropic. To se změnilo rychle a způsobem, který je v AI opravdu neobvyklý: přímí konkurenti se sjednotili na protokolu jedné firmy, místo aby vydali vlastní. OpenAI přidala podporu MCP do svého Agents SDK v březnu 2025 a umožnila vývojářům připojit pracovní postupy agentů k libovolnému MCP serveru místo vytváření zakázkových integrací nástrojů specifických pro OpenAI. Následující měsíc Google DeepMind potvrdil, že Gemini a jeho vlastní sada pro vývoj agentů budou MCP také podporovat — krok, který Google doplnil vlastním doplňkovým protokolem Agent2Agent, zaměřeným na to, aby se nezávislí agenti koordinovali mezi sebou, ne jen s nástroji. Do května 2025 Microsoft přinesl nativní podporu MCP do Windows 11 přes to, čemu říká Windows AI Foundry, a podpora se objevila i uvnitř GitHub Copilot a Copilot Studio.
Ty čtyři firmy se shodnou jen na málokterém tématu, ať jde o architekturu modelů, ceny, nebo strategii platformy. Všechny čtyři teď vydávají produkty, které mluví stejným protokolem pro připojení agenta k nástroji. V tomhle odvětví je to dost vzácné na to, aby to byl skutečný příběh — víc než jakákoli jednotlivá funkce, kterou MCP umožňuje.
Proč je to otázka důvěry, ne jen technická infrastruktura
Ta konvergence je opravdu užitečná a právě proto si MCP zaslouží zkoumání místo slepé důvěry. Protokol, který agentovi usnadňuje připojení k systémům firmy, usnadňuje stejným systémům i špatně postavené nebo špatně nastavené spojení. Samotné MCP tomu nezabrání. Specifikace definuje, jak spolu klient a server mluví — neříká nic o tom, kdo smí spojení udělit, čeho se to spojení smí dotknout, ani jestli si někdo všimne, když se něco pokazí. Tato rozhodnutí zcela závisejí na tom, kdo postavil nebo nastavil konkrétní server či klienta, který máte před sebou. Někteří dodavatelé to všechno staví pečlivě. Někteří to nestaví vůbec a protokol je nezastaví.
MCP je komunikační protokol, ne systém řízení přístupu. Standardizuje, jak agent žádá nástroj, aby něco udělal. Jestli je ta žádost vymezená, zaznamenaná a odvolatelná, je rozhodnutí, které nad ním někdo učinil — nebo neučinil.
Kontrolní seznam před připojením
Než váš tým připojí MCP server — ať je to produkt dodavatele, open-source nástroj, který někdo našel na GitHubu, nebo něco postaveného interně — šest otázek odděluje řízené spojení od otevřených dveří. Žádná z nich nevyžaduje čtení specifikace. Stačí, aby se někdo zeptal, než klikne na schválit, a opravdu si přečetl odpověď, kterou mu zobrazí obrazovka připojení.
| Zeptejte se na tohle | Jak vypadá dobrý stav | Na co si dát pozor |
|---|---|---|
| Jaké rozsahy nebo nástroje žádá? | Rozepsané Pojmenovaný, konkrétní seznam, který si můžete přečíst před schválením — „vytvářej úkoly, čti zprávy v tomto kanálu.“ | Paušální „Plný přístup k účtu“ bez rozepsaného seznamu toho, co skutečně umí. |
| Je jen pro čtení, nebo umí psát a jednat? | Oddělené Přístup pro čtení jako výchozí; každá akce, která mění data, potřebuje vlastní viditelné udělení. | Sloučené Přístup pro zápis zahrnutý automaticky, bez možnosti poznat, která schopnost co dělá. |
| Je na osobu, nebo sdílené v celém týmu? | Na osobu Každý se přihlásí vlastními přihlašovacími údaji; agent vidí jen to, co vidí ten člověk. | Sdílené Jeden API klíč nebo servisní účet pro celý tým, který obchází individuální oprávnění. |
| Existuje auditní záznam toho, co udělal? | Zaznamenané Každé volání nástroje se zapisuje — kdo ho připojil, čeho se dotkl a kdy. | Bez záznamu Žádný záznam kromě toho, co vám o dění sám nástroj AI uzná za vhodné sdělit. |
| Dá se odvolat okamžitě? | Okamžitě Jeden přepínač, účinný hned, ze stránky nastavení, kterou ovládáte. | Se zpožděním Odvolání vyžaduje tiket podpory, hovor s dodavatelem, nebo není možné vůbec. |
| Rozbije jeho odvolání něco dalšího? | Izolované Vymezené na to jedno spojení; vypnutí se týká jen jeho. | Propletené Sdílí přihlašovací údaj s jinými nástroji, takže odvolání jednoho tiše rozbije tři další. |
Jak doopravdy vypadá dobře postavené spojení
Vlastní nastavení MCP ve FabricLoop je jedna konkrétní odpověď na ten seznam — ne proto, že by bylo neobvyklé, ale proto, že každá součást odpovídá přímo jedné ze šesti otázek výše a stojí za to pojmenovat skutečnou mechaniku místo marketingové verze. FabricLoop běží v obou rolích najednou: je MCP server, do kterého se připojují vnější nástroje, takže Cursor, Claude nebo ChatGPT mohou vytvořit úkol, přidat komentář nebo přečíst poznámku s oprávněními, která má daný člověk ve FabricLoop — a je MCP klient, který se připojuje ven, takže kanál může připojit MCP aplikaci dodavatele, jako GitHub nebo Linear, a @zmínit ji jako člena týmu.
Každé spojení, v obou směrech, začíná člověkem, ne pracovním prostorem. Připojení vnějšího klienta jako Cursor otevře obrazovku souhlasu OAuth na app.fabricloop.com/oauth/consent, kde si ten člověk vybere pracovní prostor a schválí konkrétní nástroje, o které klient žádá — klient pak může jednat jen s rozsahy udělenými na té obrazovce, pod oprávněními toho jednoho člověka, nikdy přes sdílený servisní účet. Opačný směr běží stejně: správce může zapnout MCP aplikaci dodavatele pro celý tým, ale každý člověk stejně dokončí vlastní přihlášení, než mu aplikace začne fungovat, a správce může tu aplikaci nastavit do režimu jen pro čtení nebo ji omezit na seznam povolených nástrojů místo všeho, co dodavatel vystavuje.
Každý připojený klient se objeví na obrazovce nastavení vedle tlačítko Odvolat, které ho odpojí okamžitě — na vlastní stránce uživatele, ne v tiketu podpory. Na plánech Enterprise ta aktivita — včetně udělení MCP a toho, co připojený agent skutečně udělal — se zapíše do auditního záznamu, který bezpečnostní tým může projít na vyžádání, místo snímků obrazovky vytahovaných zpětně z chatového vlákna.
Nic z toho není exotické inženýrství. Je to malá, záměrně nenápadná sada rozhodnutí, důsledně opakovaná: vymezit, připnout k člověku, zaznamenat, udělat odvolatelným bez vedlejších škod. To je tentýž argument, který tento web vede šířeji o Legibility — přístup, který umíte pojmenovat, zaznamenat a odvolat, je lepší než přístup, nad kterým nikdo nemusí přemýšlet — a MCP to dodá jen tehdy, když to někdo tak postaví. Protokol standardizuje technickou infrastrukturu, ale správu a řízení přístupu automaticky nezajistí.
Rozhodnutí, na kterém doopravdy záleží
MCP nezmizí a stavět se proti němu v tuhle chvíli je trochu jako stavět se proti USB. Každý velký poskytovatel modelů ho dnes podporuje, seznam dostupných serverů pořád roste a agent, který nedosáhne na vaše nástroje, je pro většinu skutečné práce agent, který toho moc nesvede. Zajímavé rozhodnutí není to, jestli nechat nástroj AI připojit se k vašim systémům — čím dál víc se nějaká verze toho rozhodnutí dělá za vás, jedna integrace po druhé, jak nástroje, které tým už používá, tiše přidávají podporu MCP pod funkci, do které jste klikli bez čtení drobného písma. Rozhodnutí, které je pořád opravdu vaše, je to, co zkontrolujete, než kliknete na schválit.
MCP standardizoval, jak agent AI žádá nástroj, aby něco udělal. Neudělal nic pro to, aby standardizoval, zda je taková žádost bezpečné schválit — ta část je pořád, a zůstane, rozhodnutí člověka, který kliká na „schválit“.