Czym jest MCP i dlaczego nagle każde narzędzie AI zaczyna nim mówić?
Przez większą część ostatniej dekady połączenie modelu AI z narzędziami firmy oznaczało osobną integrację dla każdej pary. Model Context Protocol, otwarty standard, który Anthropic wprowadził w listopadzie 2024 roku, zastąpił to jedną wtyczką pasującą wszędzie — a OpenAI, Google i Microsoft od tamtej pory wszystkie go przyjęły. Oto jak naprawdę działa i prawdziwa lista kontrolna, zanim połączysz jedno z danymi zespołu.
Otwórz aplikację desktopową Claude i poproś ją, żeby sprawdziła otwarte pull requesty zespołu, a ona po prostu to zrobi. Nie dlatego, że Anthropic wbudował w Claude integrację z GitHubem. Dlatego, że gdzieś — zespół IT, dostawca, programista na GitHubie — ktoś napisał mały program, który mówi protokołem o nazwie MCP, a Claude już wie, jak rozmawiać ze wszystkim, co nim mówi. To samo dotyczy teraz ChatGPT, Gemini od Google i Microsoft Copilot. Ta zbieżność, bardziej niż jakakolwiek pojedyncza premiera funkcji, jest powodem, dla którego MCP stał się tym, na co niemal każdy dostawca AI przez ostatni rok budował wsparcie.
Czym MCP naprawdę jest
MCP oznacza Model Context Protocol. Anthropic zaprojektował go i 25 listopada 2024 roku otworzył specyfikację wraz z pierwszymi SDK. Własne materiały z premiery opisały pomysł analogią, która została: pomyśl o MCP jak o porcie USB-C dla aplikacji AI — jeden fizyczny standard złącza zamiast osobnego kabla do każdego akcesorium. Przy premierze Anthropic wymienił wczesnych użytkowników, którzy już budowali wsparcie MCP we własnych produktach, w tym firmy oprogramowania dla przedsiębiorstw Block i Apollo oraz twórców narzędzi dla programistów Zed, Replit, Codeium i Sourcegraph. Aplikacja desktopowa Claude wyszła tego samego dnia z możliwością uruchamiania serwerów MCP lokalnie, na własnym komputerze danej osoby.
Problem, który rozwiązuje: N narzędzi razy M źródeł danych
Problem, który rozwiązuje MCP, ma nazwę, której inżynierowie używają mimochodem: problem integracji N przez M. Powiedzmy, że firma używa pięciu narzędzi AI, które muszą działać na danych firmy — Claude, ChatGPT, GitHub Copilot, Cursor i wewnętrzny bot wsparcia — a te dane żyją w ośmiu miejscach: Slack, GitHub, baza Postgres, Salesforce, Notion, Google Drive, Jira i wewnętrzne API. Bez wspólnego protokołu sensowne połączenie każdego narzędzia z każdym źródłem to nawet czterdzieści osobnych integracji — pięć razy osiem — każda z własnym schematem uwierzytelniania, własną obsługą błędów i własnym podatkiem utrzymaniowym za każdym razem, gdy jedno z tych API zmienia kształt. Dodaj szóste narzędzie AI, a liczba skacze do czterdziestu ośmiu. W praktyce nikt nie zbudował wszystkich czterdziestu. Każdy dostawca AI zbudował tę garść, którą uznał za wartą czasu inżynierów, a cała reszta została ręczna: kopiuj, wklej, tłumacz od nowa, powtarzaj.
MCP zamienia mnożenie w dodawanie. Firma, która chce, żeby Claude czytał z jej bazy Postgres, nie buduje złącza Postgres specjalnie pod Claude. Buduje — albo używa ponownie takiego, które ktoś już opublikował — jeden serwer MCP, który udostępnia Postgres, i ten serwer działa z Claude, ChatGPT, Gemini albo dowolnym innym agentem zgodnym z MCP bez dalszego kodu. Własna lista Anthropic przy premierze wymieniała gotowe serwery dla Google Drive, Slack, GitHub, Git, Postgres i narzędzia do automatyzacji przeglądarki o nazwie Puppeteer. Chodziło nigdy o to, że Anthropic zbuduje je wszystkie. Chodziło o to, że mógł to zrobić każdy, a katalog dostępnych serwerów urósł daleko poza to, co jedna firma byłaby w stanie obsadzić ludźmi.
Jak protokół naprawdę działa
Gdy odjąć opakowanie, MCP jest dość zwyczajnym protokołem klient–serwer, celowo pozbawionym blasku. Definiuje trzy role. Host to aplikacja, którą człowiek naprawdę otwiera — Claude Desktop, IDE takie jak Cursor, aplikacja ChatGPT. Host osadza MCP Client, który otwiera bezpośrednie, stanowe połączenie z MCP Server — małym programem udostępniającym jeden konkretny system: bazę danych, narzędzie do zgłoszeń, system plików, wewnętrzne API. Klient i serwer wymieniają komunikaty w formacie JSON-RPC 2.0, lekkim formacie zdalnego wywołania procedury już powszechnym w istniejącej infrastrukturze, przez jeden z dwóch transportów: stdio, gdy serwer jest programem działającym lokalnie na tej samej maszynie, albo Streamable HTTP, gdy jest usługą hostowaną gdzie indziej.
To, co serwer może udostępnić, sprowadza się do trzech prymitywów. Tools to funkcje, które model może wywołać, żeby wykonać działanie — create_task, run_query, send_message — a model decyduje, kiedy wywołać jedną, na podstawie rozmowy. Resources to kontekst tylko do odczytu, który Host może pobrać i podać modelowi, zanim ten o niego poprosi — treść pliku, schemat bazy, zgłoszenie wsparcia. Prompts to wielokrotnego użytku szablony uruchamiane przez użytkownika — gotowe „streść ten wątek” albo „napisz aktualizację statusu”, które człowiek wywołuje wprost, a nie coś, co model sam postanawia zrobić. Dobrze zbudowany serwer mówi wprost, który z trzech oferuje dla danej możliwości, bo właśnie to rozróżnienie decyduje, czy podłączone narzędzie AI może coś obejrzeć, czy też zmienić.
Kto jeszcze to przyjął i kiedy
Pierwsze miesiące MCP były projektem wyłącznie Anthropic. To zmieniło się szybko i w sposób w AI naprawdę niezwykły: bezpośredni konkurenci zbiegli się wokół protokołu jednej firmy, zamiast wydawać własne. OpenAI dodał wsparcie MCP do swojego Agents SDK w marcu 2025 roku, pozwalając programistom łączyć przepływy pracy agentów z dowolnym serwerem MCP zamiast budować szyte na miarę, specyficzne dla OpenAI integracje narzędzi. W kolejnym miesiącu Google DeepMind potwierdził, że Gemini i jego własny zestaw do budowy agentów również będą obsługiwać MCP — ruch, który Google połączył z własnym protokołem uzupełniającym, Agent2Agent, nastawionym na to, by niezależni agenci koordynowali się ze sobą, a nie tylko z narzędziami. Do maja 2025 roku Microsoft wprowadził natywne wsparcie MCP do Windows 11 przez to, co nazywa Windows AI Foundry, a wsparcie trafiło też do GitHub Copilot i Copilot Studio.
Żadna z tych czterech firm nie zgadza się w wielu sprawach, gdy chodzi o architekturę modeli, ceny albo strategię platformy. Wszystkie cztery wydają dziś produkty, które mówią tym samym protokołem, żeby połączyć agenta z narzędziem. W tej branży to wystarczająco rzadkie, żeby być właściwą historią — bardziej niż jakakolwiek pojedyncza funkcja, którą MCP umożliwia.
Dlaczego to pytanie o zaufanie, a nie tylko o instalację
Ta zbieżność jest naprawdę użyteczna i właśnie dlatego MCP zasługuje na kontrolę, a nie na ślepe zaufanie. Protokół, który sprawia, że agentowi banalnie łatwo połączyć się z systemami firmy, to protokół, który sprawia, że banalnie łatwo źle zbudowanemu albo źle skonfigurowanemu połączeniu dotrzeć do tych samych systemów. Sam MCP tego nie powstrzymuje. Specyfikacja określa, jak klient i serwer ze sobą rozmawiają — nie mówi nic o tym, kto może przyznać połączenie, czego to połączenie może dotknąć ani czy ktoś zauważy, gdy coś pójdzie nie tak. Te wybory leżą w całości po stronie tego, kto zbudował albo skonfigurował konkretny serwer lub klient przed tobą. Niektórzy dostawcy budują to wszystko starannie. Niektórzy nie budują tego wcale, a protokół ich nie zatrzyma.
MCP jest protokołem przewodowym, nie systemem kontroli dostępu. Standaryzuje to, jak agent prosi narzędzie, żeby coś zrobiło. Czy ta prośba jest ograniczona, zapisana i odwoływalna, to decyzja, którą ktoś podjął — albo nie — ponad nim.
Lista kontrolna, zanim jedno połączysz
Zanim zespół połączy serwer MCP — czy to produkt dostawcy, narzędzie open source, które ktoś znalazł na GitHubie, czy coś zbudowanego wewnętrznie — sześć pytań oddziela zarządzane połączenie od otwartych drzwi. Żadne nie wymaga czytania specyfikacji. Wymagają tylko, żeby ktoś zapytał, zanim kliknie zatwierdź, i naprawdę przeczytał odpowiedź, którą oddaje ekran połączenia.
| Zapytaj o to | Jak wygląda dobrze | Uważaj na |
|---|---|---|
| Jakich zakresów albo narzędzi żąda? | Wypunktowane Nazwana, konkretna lista, którą możesz przeczytać przed zatwierdzeniem — „twórz zadania, czytaj wiadomości na tym kanale”. | Blankietowe „Pełny dostęp do konta” bez wypunktowanej listy tego, co naprawdę może zrobić. |
| Jest tylko do odczytu, czy może pisać i działać? | Rozdzielone Dostęp do odczytu domyślnie; każde działanie, które zmienia dane, potrzebuje własnego widocznego nadania. | Spięte Dostęp do zapisu włączony automatycznie, bez sposobu, żeby stwierdzić, która możliwość co robi. |
| Jest na osobę, czy współdzielone w całym zespole? | Na osobę Każda osoba loguje się własnym loginem; agent widzi tylko to, co widzi ta osoba. | Współdzielone Jeden klucz API albo konto usługowe używane przez cały zespół, z pominięciem uprawnień indywidualnych. |
| Czy jest dziennik audytu tego, co zrobił? | Zapisane Każde wywołanie narzędzia jest rejestrowane — kto je podłączył, czego dotknął i kiedy. | Bez zapisu Żadnego śladu poza tym, co samo narzędzie AI zdecyduje ci powiedzieć, że się stało. |
| Czy da się je odwołać natychmiast? | Natychmiast Jeden przełącznik, skuteczny od razu, ze strony ustawień, którą kontrolujesz. | Z opóźnieniem Odwołanie wymaga zgłoszenia do wsparcia, telefonu do dostawcy albo w ogóle nie jest możliwe. |
| Czy odwołanie psuje coś jeszcze? | Izolowane Ograniczone do tego jednego połączenia; wyłączenie dotyczy tylko jego. | Splątane Dzieli poświadczenie z innymi narzędziami, więc odwołanie jednego po cichu psuje trzy kolejne. |
Jak naprawdę wygląda dobrze zbudowane połączenie
Własna konfiguracja MCP w FabricLoop jest jedną konkretną odpowiedzią na tę listę — nie dlatego, że jest niezwykła, ale dlatego, że każdy element mapuje się wprost na jedno z sześciu pytań powyżej i warto nazwać rzeczywistą mechanikę, a nie jej wersję marketingową. FabricLoop działa w obu rolach naraz: jest serwerem MCP, do którego łączą się zewnętrzne narzędzia, więc Cursor, Claude albo ChatGPT mogą utworzyć zadanie, dodać komentarz albo odczytać notatkę, używając własnych uprawnień FabricLoop konkretnej osoby — i jest klientem MCP, który łączy się na zewnątrz, więc kanał może wciągnąć aplikację MCP dostawcy, jak GitHub albo Linear, i wspomnieć ją przez @ jak członka zespołu.
Każde połączenie, w którąkolwiek stronę, zaczyna się od osoby, nie od przestrzeni roboczej. Podłączenie zewnętrznego klienta, takiego jak Cursor, otwiera ekran zgody OAuth pod adresem app.fabricloop.com/oauth/consent, gdzie ta osoba wybiera przestrzeń roboczą i zatwierdza konkretne narzędzia, o które prosi klient — klient może potem działać tylko w zakresach nadanych na tym ekranie, w ramach uprawnień tej jednej osoby, nigdy przez współdzielone konto usługowe. Kierunek odwrotny działa tak samo: administrator może włączyć aplikację MCP dostawcy dla całego zespołu, ale każda osoba i tak kończy własne logowanie, zanim zadziała to u niej, a administrator może ustawić tę aplikację w trybie tylko do odczytu albo ograniczyć ją do listy dozwolonych konkretnych narzędzi zamiast wszystkiego, co udostępnia dostawca.
Każdy podłączony klient pojawia się na ekranie ustawień obok kontrolki Odwołaj, która rozłącza go natychmiast — na stronie samej osoby, nie w zgłoszeniu do wsparcia. W planach Enterprise ta aktywność — w tym nadania MCP i to, co podłączony agent naprawdę zrobił — trafia do dziennika audytu, który zespół bezpieczeństwa może przejrzeć na żądanie, zamiast zrzutów ekranu wyciąganych po fakcie z wątku czatu.
Nic z tego nie jest egzotyczną inżynierią. To mały, celowo niebłyszczący zestaw decyzji, powtarzany konsekwentnie: ogranicz zakres, przypnij do osoby, zapisz, uczyń odwoływalnym bez szkód ubocznych. To ten sam argument, który ta strona stawia szerzej o Legibility — dostęp, który da się nazwać, zapisać i odwołać, wygrywa z dostępem, o którym nikt nie musi myśleć — a MCP dostarcza to tylko wtedy, gdy ktoś zbuduje go w ten sposób. Protokół standaryzuje instalację. Nie czyni zarządzania automatycznym.
Decyzja, która naprawdę ma znaczenie
MCP nie zniknie, a sprzeciw wobec niego na tym etapie przypomina trochę sprzeciw wobec USB. Każdy duży dostawca modeli już go wydaje, lista dostępnych serwerów wciąż rośnie, a agent, który nie sięga do twoich narzędzi, jest — przy większości prawdziwej pracy — agentem, który niewiele może. Interesująca decyzja nie brzmi, czy pozwolić narzędziu AI połączyć się z twoimi systemami — coraz częściej jakaś wersja tej decyzji jest już podejmowana za ciebie, integracja po integracji, gdy narzędzia, których zespół już używa, po cichu dodają wsparcie MCP pod funkcją, w którą kliknąłeś bez czytania drobnego druku. Decyzja, która wciąż naprawdę należy do ciebie, to co sprawdzasz, zanim klikniesz zatwierdź.
MCP ustandaryzował to, jak agent AI prosi narzędzie, żeby coś zrobiło. Nie zrobił nic, żeby ustandaryzować, czy tę prośbę bezpiecznie jest przyznać — ta część wciąż jest, i pozostanie, decyzją osoby, która klika „zatwierdź”.