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 także go przyjęły. Oto jak naprawdę działa oraz praktyczna lista kontrolna, zanim podłączysz taki serwer do danych swojego 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 obsługuje protokół o nazwie MCP, a Claude już wie, jak rozmawiać ze wszystkim, co go obsługuje. 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ę standardem, którego obsługę przez ostatni rok budował niemal każdy dostawca AI.
Czym MCP naprawdę jest
MCP oznacza Model Context Protocol. Anthropic zaprojektował go i 25 listopada 2024 roku opublikował jako open source specyfikację wraz z pierwszymi SDK. Własne materiały z premiery opisały pomysł analogią, która się przyjęł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 tworzące oprogramowanie 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ą potocznie: 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 znajdują się 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 wymaga nawet czterdziestu osobnych integracji — pięć razy osiem — każda z własnym schematem uwierzytelniania, własną obsługą błędów i własnym kosztem utrzymania za każdym razem, gdy jedno z tych API zmienia kształt. Dodaj szóste narzędzie AI, a liczba rośnie do czterdziestu ośmiu. W praktyce nikt nie zbudował wszystkich czterdziestu. Każdy dostawca AI zbudował te nieliczne, które uznał za wartą czasu inżynierów, a cała reszta pozostał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 korzysta z takiego, który 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 dodatkowego 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. Nigdy nie chodziło 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 obsłużyć.
Jak protokół naprawdę działa
Gdy odjąć opakowanie, MCP jest dość zwyczajnym protokołem klient–serwer, celowo nieefektownym. 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, system obsługi 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 na podstawie rozmowy, kiedy wywołać daną funkcję. Resources to kontekst tylko do odczytu, który Host może pobrać i podać modelowi, bez czekania na jego prośbę — 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 funkcji, 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 skupili 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.
Te cztery firmy nie zgadzają się ze sobą w wielu sprawach, takich jak architektura 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 na tyle rzadkie, że stanowi prawdziwy temat — bardziej niż jakakolwiek pojedyncza funkcja, którą MCP umożliwia.
Dlaczego to pytanie o zaufanie, a nie tylko o infrastrukturę techniczną
Ta zbieżność jest naprawdę użyteczna i właśnie dlatego MCP zasługuje na dokładne sprawdzenie, 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 zatwierdzić 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 komunikacyjnym, a nie systemem kontroli dostępu. Standaryzuje to, jak agent prosi narzędzie o wykonanie działania. To, czy ta prośba jest ograniczona zakresem, rejestrowana i możliwa do odwołania, zależy od decyzji, którą ktoś podjął na jego bazie — albo nie.
Lista kontrolna przed podłączeniem serwera MCP
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ą jedynie, żeby ktoś zapytał, zanim kliknie „Zatwierdź”, i naprawdę przeczytał odpowiedź, którą wyświetla ekran połączenia.
| Zapytaj o to | Jak wygląda dobra odpowiedź | Uważaj na |
|---|---|---|
| Jakich zakresów albo narzędzi żąda? | Wyszczególnione Konkretna lista z nazwami, którą możesz przeczytać przed zatwierdzeniem — „twórz zadania, czytaj wiadomości na tym kanale”. | Szerokie „Pełny dostęp do konta” bez wyszczególnionej listy tego, co naprawdę może zrobić. |
| Czy jest tylko do odczytu, czy może też zapisywać dane i wykonywać działania? | Rozdzielone Dostęp do odczytu domyślnie; każde działanie, które zmienia dane, wymaga osobnej, widocznej zgody. | W pakiecie Dostęp do zapisu włączony automatycznie, bez możliwości sprawdzenia, która możliwość co robi. |
| Czy jest przypisane do osoby, 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ło? | 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 się ci przekazać. |
| 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 zakłóca działanie czegoś jeszcze? | Izolowane Ograniczone do tego jednego połączenia; wyłączenie dotyczy tylko jego. | Powiązane 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 odpowiada wprost 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 dodać aplikację MCP dostawcy, jak GitHub albo Linear, i oznaczyć 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 przechodzi 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, wybranych 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 zgody 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 nieefektowny zestaw decyzji, powtarzany konsekwentnie: ogranicz zakres, przypnij do osoby, zapisz, spraw, by dało się to odwołać bez skutków ubocznych. To ten sam argument, który ta strona przedstawia szerzej w kontekście 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 zapewnia to tylko wtedy, gdy ktoś zbuduje to w ten sposób. Protokół ujednolica infrastrukturę. Nie sprawia, że zarządzanie dostępem dzieje się automatycznie.
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 obsługuje, lista dostępnych serwerów wciąż rośnie, a agent, który nie sięga do twoich narzędzi, jest w większości realnych zadań agentem, który niewiele może. Ciekawe jest nie to, 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ą kliknięto 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 ujednolicił natomiast tego, czy tę prośbę bezpiecznie jest zatwierdzić — ta część wciąż jest, i pozostanie, decyzją osoby, która klika „zatwierdź”.