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ždý pár. 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ž jedno připojíte k datům 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 — váš IT tým, dodavatel, 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 stalo 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 otevřel specifikaci spolu s prvními SDK. Vlastní materiály k uvedení popsaly tu myšlenku analogií, která zůstala: 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 jmenoval rané uživatele, kteří už stavěli podporu MCP do vlastních produktů, včetně firem podnikového softwaru Block a Apollo 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 člověka.
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 schématem ověření, vlastní obsluhou 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 tu hrstku, kterou posoudil jako hodnou inženýrského času, 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. Vlastní seznam Anthropic při uvedení jmenoval předpřipravené servery pro Google Drive, Slack, GitHub, Git, Postgres a nástroj na automatizaci prohlížeče jménem Puppeteer. Pointa nikdy nebyla, že je všechny postaví Anthropic. Byla, že to může kdokoli, a katalog dostupných serverů vyrostl daleko za to, co by jedna firma dokázala personálně unést.
Jak protokol doopravdy funguje
Když se sloupne rámování, MCP je poměrně prostý protokol klient–server, záměrně bez lesku. 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í procedury, 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 scvrkne 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 přitáhnout a předat modelu, aniž by o něj model musel žádat — obsah souboru, schéma databáze, tiket podpory. Prompts jsou znovupoužitelné šablony spouštěné uživatelem — hotové „shrň toto vlákno“ nebo „návrh aktualizace 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 může na něco koukat, nebo to změnit.
Kdo další to převzal a kdy
První měsíce MCP byly projekt jen Anthropic. To se změnilo rychle a způsobem, který je v AI opravdu neobvyklý: přímí konkurenti se sešli 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 stavby 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 spároval s 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 přistála i uvnitř GitHub Copilot a Copilot Studio.
Žádná z těch čtyř firem se neshodne na mnohém, jde-li 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 potrubí
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 dělá triviálním připojit se k systémům firmy, je protokol, který dělá triviálním, aby ke stejným systémům dosáhlo š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í. Ty volby leží celé na tom, kdo postavil nebo nastavil konkrétní server či klienta před vámi. Někteří dodavatelé to všechno staví pečlivě. Někteří to nestaví vůbec a protokol je nezastaví.
MCP je drátový 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 udělal — nebo neudělal.
Kontrolní seznam, než jedno připojíte
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á nevyžaduje čtení specifikace. Vyžadují jen, aby se někdo zeptal, než klikne na schválit, a opravdu si přečetl odpověď, kterou obrazovka spojení vrátí.
| Zeptejte se na tohle | Jak vypadá dobře | Hlídejte |
|---|---|---|
| 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í. | Sbalené Přístup pro zápis zahrnutý automaticky, bez způsobu 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ím přihlášením; 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 nad to, co vám samotný nástroj AI zvolí říct, že se stalo. |
| 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ý kus mapuje přímo na jednu 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 vlastními oprávněními FabricLoop konkrétního člověka — a je MCP klient, který se připojuje ven, takže kanál může vtáhnout 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ž to pro něj funguje, a správce může tu aplikaci nastavit do režimu jen pro čtení nebo ji omezit na seznam povolených konkrétních nástrojů místo všeho, co dodavatel vystavuje.
Každý připojený klient se objeví na obrazovce nastavení vedle ovládání Odvolat, které ho odpojí okamžitě — na stránce samotného člověka, 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 — dopadne 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ě nelesklá sada rozhodnutí, opakovaná důsledně: 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, poráží přístup, nad kterým nikdo nemusí přemýšlet — a MCP to dodá jen tehdy, když to někdo tak postaví. Protokol dělá potrubí standardním. Správu automatickou nedělá.
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 teď vydává, 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í, 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 standardizovalo, jak agent AI žádá nástroj, aby něco udělal. Neudělalo nic pro to, aby standardizovalo, jestli je tu žádost bezpečné udělit — ta část je pořád, a zůstane, rozhodnutí člověka, který kliká na „schválit“.