Czym jest serwer MCP? Jak działają MCP i MCP UI w 2026 roku

1 kwietnia 2025 roku Invariant Labs opublikowało narzędzie o nazwie add. Przyjmowało dwie liczby i zwracało ich sumę. Jego opis zawierał też blok oznaczony IMPORTANT, niewidoczny w interfejsie klienta, który kazał modelowi odczytać ~/.cursor/mcp.json i ~/.ssh/id_rsa, a potem wysłać oba pliki na zewnątrz przez dodatkowy parametr. Model posłuchał. Użytkownik zobaczył dodawanie.

Ta demonstracja to najlepsze wprowadzenie do serwerów MCP, jakie znam, bo pokazuje obie połowy naraz. Protokół zadziałał dokładnie tak, jak go zaprojektowano: klient AI odkrył narzędzie, przeczytał jego opis i je wywołał. Modelu zaufania nikt jeszcze nie zbudował.

Czym jest serwer MCP

Serwer MCP to program, który udostępnia aplikacjom AI narzędzia, dane i prompty przez Model Context Protocol (MCP). Oficjalna dokumentacja definiuje MCP jako „otwarty standard łączenia aplikacji AI z systemami zewnętrznymi.” Klient AI, taki jak Claude, ChatGPT, Visual Studio Code czy Cursor, łączy się z serwerem, pyta, co ten oferuje, i wywołuje te możliwości w imieniu użytkownika.

Anthropic ogłosiło MCP 25 listopada 2024 roku razem z sześcioma gotowymi serwerami: Google Drive, Slack, GitHub, Git, Postgres i Puppeteer. OpenAI przyjęło protokół w marcu 2025 roku. Google DeepMind dołączyło w kwietniu. W grudniu 2025 roku Anthropic przekazało protokół fundacji Agentic AI Foundation, funduszowi celowemu działającemu przy Linux Foundation, który Anthropic, Block i OpenAI założyły wspólnie.

Problemem jest mnożenie połączeń. Przed MCP każda aplikacja AI potrzebująca GitHub pisała własne złącze, a każdy dostawca budował połączenie dla każdej aplikacji AI. Dziesięć modeli i dziesięć narzędzi mogło oznaczać sto integracji. MCP zmniejsza liczbę do dwudziestu: klient wdraża protokół raz, a system udostępnia jeden serwer.

Pomyśl o tym jak o kontenerze transportowym integracji AI. Przed kontenerami każdy port ładował każdy towar ręcznie, własnymi dźwigami i własną ekipą. Kontener ustandaryzował skrzynię, więc każdy statek, dźwig i ciężarówka mogły przewieźć każdy ładunek. Nie ustandaryzował tego, co jest w środku, i nigdy nie sprawdzał zawartości. MCP to ta sama umowa. Zapamiętaj tę drugą połowę. Wróci w części o bezpieczeństwie.

Jak działa serwer MCP

Aktualna specyfikacja, w wersji 2026-07-28, używa komunikatów JSON-RPC 2.0 między trzema rolami. Jej własny opis ma trzy linijki: hosty to „aplikacje LLM, które inicjują połączenia”, klienci to „konektory wewnątrz aplikacji hosta”, a serwery to „usługi dostarczające kontekst i możliwości.”

Host, klient, serwer

Host to aplikacja, w której piszesz: Claude Desktop, IDE, Twój własny agent. W jej wnętrzu działa jeden klient na każde połączenie z serwerem. Serwer siedzi po drugiej stronie i rozmawia z prawdziwym systemem, czy to bazą danych Postgres, API GitHuba, czy folderem na Twoim dysku. Host decyduje, co widzi model i co musi zatwierdzić użytkownik. Serwer decyduje, co zrobi system pod spodem.

1. Host Claude Desktop · IDE · Twój własny agent

   pokazuje modelowi narzędzia, prosi użytkownika o zgodę

2. Klient jeden na połączenie z serwerem

   mówi JSON-RPC przez stdio lub Streamable HTTP

3. Serwer MCP narzędzia · zasoby · prompty

   opisuje, co oferuje, i wykonuje wywołania

4. System docelowy baza danych · SaaS API · pliki lokalne

   wykonuje pracę

Narzędzia, zasoby i prompty

Serwer może oferować trzy rodzaje rzeczy:

• Narzędzia (tools) to funkcje, które model może wykonać: create_issue, query_orders, send_email. Każde ma nazwę, opis i JSON Schema dla danych wejściowych.
• Zasoby (resources) to kontekst i dane do odczytu dla użytkownika lub modelu: plik, schemat bazy danych, rekord.
• Prompty (prompts) to szablony wiadomości i workflow, które użytkownik może wybrać, na przykład „podsumuj ten pull request”.

Narzędzia dostają najwięcej uwagi, bo działają. Z tego samego powodu niosą największe ryzyko.

Wywołanie narzędzia krok po kroku

Rewizja 2026-07-28 uczyniła MCP bezstanowym. Nie ma już uzgadniania initialize. Każde żądanie niesie wersję protokołu i możliwości klienta w polu _meta, a serwery muszą implementować metodę server/discover, żeby klient mógł z góry zapytać, co obsługują. Pojedyncze wywołanie narzędzia przebiega teraz tak:

1. Użytkownik prosi: utwórz zgłoszenie dla tego błędu

2. Krok 1

   Odkrycie

   • Klient może wywołać server/discover, by poznać wersje i możliwości
3. Krok 2

   Lista narzędzi

   • tools/list zwraca nazwy, opisy i schematy danych wejściowych
4. Krok 3

   Model wybiera narzędzie

   • Host przekazuje modelowi definicje narzędzi
5. Krok 4

   Zgoda użytkownika

   • Według specyfikacji host musi uzyskać wyraźną zgodę przed wywołaniem dowolnego narzędzia
6. Krok 5

   Wywołanie

   • tools/call z argumentami, wersja protokołu w _meta

7. Brakuje danych? Serwer zwraca input_required, a klient ponawia próbę z odpowiedziami

   Krok 6

   Wynik

8. Wynik wraca do modelu jako kontekst

Krok 6 jest nowością tej rewizji. Serwer, który potrzebuje więcej informacji, nie wysyła już własnego żądania z powrotem do klienta. Zwraca wynik oznaczony input_required, klient zbiera odpowiedź i ponawia pierwotne wywołanie. Specyfikacja nazywa to wzorcem Multi Round-Trip Request.

Transporty: stdio i Streamable HTTP

Specyfikacja definiuje dwa standardowe transporty:

• stdio: klient uruchamia serwer jako podproces i wymienia komunikaty JSON-RPC, po jednym w linii, przez standardowe wejście i wyjście. Tak działa większość lokalnych serwerów, co oznacza, że serwer działa na Twoim komputerze z Twoimi uprawnieniami.
• Streamable HTTP: każdy komunikat to HTTP POST do jednego endpointu, a odpowiedzi wracają jako obiekt JSON albo strumień zdarzeń powiązany z danym żądaniem. Tak działają zdalne serwery hostowane.

Starszy transport HTTP+SSE jest formalnie wycofany. Rewizja 2026-07-28 usunęła też sesje na poziomie protokołu i nagłówek Mcp-Session-Id. Serwer, który potrzebuje stanu między wywołaniami, sam tworzy teraz uchwyt i dostaje go z powrotem jako zwykły argument narzędzia.

Autoryzacja

Autoryzacja w MCP jest opcjonalna i dotyczy tylko HTTP. Przy stdio specyfikacja mówi, że serwery powinny zamiast tego pobierać dane uwierzytelniające ze środowiska. Przy HTTP chroniony serwer MCP działa jako serwer zasobów OAuth 2.1. Musi publikować OAuth Protected Resource Metadata (RFC 9728), żeby klienci mogli znaleźć jego serwer autoryzacji. Klienci muszą wskazać dokładnie ten serwer, dla którego jest token (wskaźniki zasobów z RFC 8707). Serwery muszą odrzucać każdy token, który nie został wydany dla nich, a wytyczne bezpieczeństwa wprost zakazują „token passthrough”, czyli przekazywania tokenu klienta bez zmian do API dalej w łańcuchu.

Ta ostatnia zasada waży więcej, niż się wydaje. Serwer, który przekazuje dalej każdy otrzymany token, staje się proxy dla każdego, kto jakiś token ma.

Co dodaje MCP UI: serwery, które zwracają interfejs

Odpowiedzi tekstowe przestają działać w chwili, gdy użytkownik musi porównać czterdzieści wierszy, poprawić formularz z dwunastoma polami albo zatwierdzić serię zmian jedna po drugiej. „MCP UI” to nazwa, pod którą ludzie szukają rozwiązania: serwer zwraca interaktywny interfejs, który renderuje się w kliencie AI, obok rozmowy.

Status wymaga precyzji. Pomysł zaczął się od MCP-UI, projektu społecznościowego. OpenAI przygotowało podobny mechanizm w Apps SDK. Projekt MCP zaproponował wspólny standard z obiema inicjatywami 21 listopada 2025 roku, a 26 stycznia 2026 roku opublikował MCP Apps jako pierwsze oficjalne rozszerzenie MCP. Pakiety MCP-UI stosują dziś standard i pozostają miejscem testowania ulepszeń.

MCP UI oznacza więc dziś MCP Apps. Jest oficjalne i jest rozszerzeniem, a nie rdzeniem protokołu. Rozszerzenia są opcjonalne: muszą je obsługiwać zarówno klient, jak i serwer, a dokumentacja mówi wprost, że „obsługa różni się w zależności od klienta.” Dokumentacja MCP Apps wymienia Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam i Archestra.AI jako hosty z obsługą. Serwer, którego narzędzia zwracają interfejs, nadal musi działać w kliencie, który pokazuje tylko tekst.

Mechanicznie korzysta z elementów samego MCP:

1. Opis narzędzia zawiera _meta.ui.resourceUri, które wskazuje na zasób ui://.
2. Host pobiera ten zasób, stronę HTML ze skryptami, i może załadować go z wyprzedzeniem, zanim narzędzie zostanie wywołane.
3. Host renderuje go w odizolowanym iframe (sandbox), który nie ma dostępu do strony nadrzędnej, jej ciasteczek ani pamięci.
4. Aplikacja i host komunikują się przez postMessage w dialekcie JSON-RPC protokołu MCP. Aplikacja może prosić o wywołania narzędzi, a host decyduje, na które pozwoli.

Koszt jest realny. Dostarczasz teraz frontend webowy w cudzej aplikacji, z polityką bezpieczeństwa treści (CSP), którą musisz zadeklarować, zasadami renderowania, nad którymi nie masz kontroli, i wersją tekstową dla każdego hosta, który go zignoruje. Zysk polega na tym, że praca nad zatwierdzaniem przestaje być zapisem czatu. Lista dobrych zastosowań w samej dokumentacji kończy się na „zatwierdzaniu raportów wydatków, przeglądaniu zmian w kodzie lub segregowaniu zgłoszeń”, i to jest uczciwe sedno: MCP UI najlepiej sprawdza się przy decyzjach, a nie jako dekoracja.

Przykład Tajo tylko do odczytu

Powierzchnia Alto MCP w Tajo zawiera query_contacts, które szuka kontaktów zapisanych w połączonym obszarze roboczym. Znajdź jeden istniejący kontakt po emailu i sprawdź identyfikator, stan zgody na email oraz czas ostatniego zaobserwowania. Oddzielne get_contact_topic_status czyta subskrypcje tematyczne kontaktu.

To odczyty z obszaru roboczego. Nie pobierają świeżych danych od dostawcy, nie uruchamiają synchronizacji i nie wysyłają wiadomości. Nie dowodzą też, że wszystkie złącza działają. Brakujące lub stare dane zbadaj u źródła. Pusty wynik nie dowodzi, że osoby nie ma w Brevo.

Użyj dokumentacji MCP Tajo, aby połączyć obsługiwanego klienta i zobaczyć narzędzia naprawdę udostępnione Twojemu obszarowi. Interaktywny panel może pomóc, gdy klient obsługuje MCP Apps. Wynik tekstowy nadal musi wyjaśniać rezultat.

Wywołanie narzędzia to nie trwała synchronizacja

Powtarzana synchronizacja potrzebuje harmonogramu, stałej tożsamości rekordów, zapisanego postępu, decyzji o ponowieniach i rejestru ukończonych zapisów. Odpowiada za to wykonująca aplikacja. MCP ujednolica dostęp do narzędzi; sama obecność w spisie nie dostarcza tych reguł.

Po przekroczeniu czasu odczyt można zwykle ponowić. Wysyłka lub płatność mogła już nastąpić. Zachowaj zapis wykonania i uzgodnij rezultat przed kolejną próbą. Pewność modelu nie udziela zgody ani nie czyni powtórki bezpieczną.

Poradnik API Brevo opisuje zapis po stronie celu dla konkretnego kontaktu. Poradnik reverse ETL pomaga ocenić, kiedy obliczone pola wymagają własnej utrzymywanej synchronizacji.

Rachunek za bezpieczeństwo przychodzi razem z protokołem

Zarzut zasługuje na to, by przytoczyć go w całości: „MCP daje probabilistycznemu modelowi listę funkcji, które mogą usuwać dane i wysyłać maile, a potem ufa tekstom napisanym przez obcych, które te funkcje opisują. To nie jest standard integracji. To atak na łańcuch dostaw ze specyfikacją.” Większość z tego jest prawdą. Specyfikacja zgadza się z założeniem. Jej sekcja o bezpieczeństwie mówi, że narzędzia „oznaczają wykonywanie dowolnego kodu i muszą być traktowane z odpowiednią ostrożnością”, że opisy narzędzi „należy uznawać za niezaufane, chyba że pochodzą z zaufanego serwera”, oraz że MCP „nie może egzekwować tych zasad bezpieczeństwa na poziomie protokołu.”

Oto dotychczasowy bilans:

• Tool poisoning (zatrute opisy narzędzi). Ujawnienie Invariant Labs z kwietnia 2025 roku, czyli narzędzie add opisane wyżej. Ten sam wpis opisywał rug pulls, gdy serwer zmienia opis narzędzia po tym, jak je zatwierdziłeś, oraz shadowing, gdy jeden złośliwy serwer przepisuje zachowanie modelu wobec innego, zaufanego serwera.
• Przejęte serwery lokalne. W lipcu 2025 roku JFrog ujawnił CVE-2025-6514 w mcp-remote w wersjach od 0.0.5 do 0.1.15, który pozwalał złośliwemu serwerowi uruchamiać polecenia na komputerze użytkownika. Tego samego lata CVE-2025-49596 dotknął MCP Inspector, narzędzie samego Anthropic, które domyślnie było dostarczane bez uwierzytelniania.
• Rozdęte zakresy uprawnień. Oficjalne dobre praktyki bezpieczeństwa nazywają ten wzorzec: tokeny z góry dostają files:* albo admin:*, bo serwer wymienił każdy zakres, a klient poprosił o wszystkie.
• Oficjalne obawy. W maju 2026 roku amerykańska National Security Agency stwierdziła, że „szybkie rozprzestrzenianie się MCP wyprzedziło rozwój jego modelu bezpieczeństwa.”

Zarzut myli się we wniosku. Rozwiązaniem nigdy nie było przestać łączyć modeli z systemami. Zespoły i tak już to robiły, wklejając surowe klucze API do promptów i skryptów, bez żadnego śladu audytowego. Rozwiązaniem jest traktowanie serwera MCP jak każdej innej uprzywilejowanej zależności:

• Instaluj serwery tylko ze źródeł, którym powierzyłbyś te same dane uwierzytelniające także poza MCP.
• Wybieraj zdalne serwery z OAuth i wąskimi zakresami zamiast lokalnych plików binarnych z długowiecznymi kluczami.
• Wymagaj zatwierdzenia przez człowieka przy każdym zapisie i zapisuj w logach, kto co zatwierdził.
• Przypinaj wersje serwerów i ponownie je przeglądaj, gdy zmieni się opis narzędzia.
• Udostępniaj narzędzia skrojone pod zadanie, a nie całe API. Model nie nadużyje endpointu do usuwania, którego nigdy nie udostępniono.

Protokół ustandaryzował skrzynię. Sprawdzanie ładunku nadal należy do Ciebie.

Zbudować serwer MCP czy użyć istniejącego

Publiczne katalogi, takie jak mcp.so, zbierają serwery tworzone przez społeczność, a wielu dostawców SaaS publikuje własne. Brevo na przykład udostępnia serwer MCP, który jest też podzielony na osobne serwery, więc agent może dostać dostęp do kontaktów bez kampanii. Decyzja dotyczy nie tyle nakładu pracy, ile tego, kto powinien decydować o kształcie narzędzi.

Którego serwera MCP powinien używać Twój agent?

1. Dostawca publikuje serwer, który obejmuje zadanie

   Użyj serwera dostawcy

   Nadąża za API, a dostawca go utrzymuje.

2. Jeden system, ale potrzebujesz mniej lub bezpieczniejszych działań

   Użyj go z ograniczeniami

   Nadaj minimalne zakresy i udostępnij tylko te grupy narzędzi, których agent potrzebuje.

3. Dane wewnętrzne albo system bez serwera

   Zbuduj mały serwer

   Kilka narzędzi skrojonych pod zadanie, na Twoim własnym API, z Twoim własnym uwierzytelnianiem.

4. Zadanie obejmuje dwa lub więcej systemów

   Zbuduj lub wdróż zarządzaną warstwę

   Jeden zestaw narzędzi, zasad zgody i historii audytu dla wszystkich systemów.

Zbudowanie prostego serwera to łatwa część. Z oficjalnym SDK działający serwer stdio z jednym narzędziem to praca na jedno popołudnie. Koszt przychodzi później: OAuth dla wersji HTTP, wycofywane funkcje (rewizja 2026-07-28 oznaczyła jako przestarzałe Roots, Sampling i Logging oraz Dynamic Client Registration) i ciągła praca nad opisami narzędzi, które model odczyta poprawnie. Opakowanie API w zasadzie jedno narzędzie na jeden endpoint to najczęstszy błąd. Każdy opis narzędzia to tekst, który model musi przeczytać i rozważyć, więc krótka lista narzędzi skrojonych pod zadanie wygrywa z całą powierzchnią API.

MCP, API, integracje i iPaaS

MCP nie zastępuje API. Prawie każdy serwer MCP jest nakładką na jakieś API. To API nadal wykonuje pracę, z własnymi limitami zapytań, własnym modelem danych i własnymi dziwactwami. MCP zmienia to, kto może je wywołać: model, w trakcie działania, który wybiera wywołanie na podstawie opisu, zamiast programisty, który zakodował je na sztywno z wyprzedzeniem.

To rozróżnienie wyznacza wyraźną granicę wobec dwóch innych rzeczy, z którymi MCP bywa mylony:

• Integracje i iPaaS (tu porównujemy główne platformy) przenoszą dane według harmonogramu lub po wyzwalaczu, deterministycznie, niezależnie od tego, czy ktoś siedzi na czacie. Nocna synchronizacja 40 000 zamówień do CRM nie powinna zależeć od tego, czy model zdecyduje się wykonać 40 000 wywołań narzędzi.
• Reverse ETL wypycha zamodelowane dane z hurtowni danych z powrotem do narzędzi operacyjnych. Czym jest reverse ETL i kiedy pasuje to osobny temat, a do tego jest to potok danych, nie rozmowa.
• MCP służy do chwil, w których osoba albo agent musi na żądanie zapytać, sprawdzić albo zadziałać w tych systemach.

Błąd działa w obie strony. Jedne zespoły budują serwery MCP do masowej synchronizacji i dostają wolne, drogie, niepowtarzalne potoki. Inne budują staranne integracje, a potem dają swojemu asystentowi AI surowy klucz API, żeby je odpytywał, i dostają niezarządzane tylne drzwi.

Dla obsługiwanej integracji trwałe zadanie i narzędzia do jego kontroli powinny mieć wspólną, wyraźną granicę uprawnień. Sprawdź złącze, dozwolone działania i zapisane rezultaty konkretnego przepływu. Dokumentacja integracji odróżnia instrukcje konfiguracji od ścieżek wciąż wymagających dowodu produkcyjnego. MCP może udostępniać oddzielnie zatwierdzone narzędzia; ich lista nie dowodzi, że cykliczna synchronizacja lub wszystkie kontrole są aktywne.

W 22 miesiące MCP przeszło od sześciu serwerów referencyjnych do projektu Linux Foundation, którym posługują się Claude, ChatGPT, VS Code i Cursor. Połączenie modelu z systemem to dziś tania część. Prawdziwa praca to zdecydować, co wolno mu tam robić.