MCP vs API: czego nauczyliśmy się, prowadząc serwer MCP na produkcji

MCP opiera się na architekturze klient-host-serwer. Host to aplikacja AI, w której pracuje użytkownik. Tworzy i koordynuje wielu klientów oraz egzekwuje zasady bezpieczeństwa i zgody użytkownika. Każdy klient łączy się z dokładnie jednym serwerem, a każdy serwer udostępnia modelowi swoje możliwości.

Protokół opiera się na JSON-RPC. Serwer może być procesem lokalnym na komputerze programisty albo zdalną usługą dostępną przez sieć. Specyfikacja w wersji 2026-07-28 opisuje MCP jako protokół bezstanowy: każde żądanie zawiera własną wersję protokołu i listę możliwości, bez sesji na poziomie protokołu.

Narzędzia, zasoby i prompty

Serwer udostępnia trzy rodzaje elementów:

• Narzędzia (tools) to funkcje, które model może wywołać, na przykład „utwórz stronę” albo „pokaż listę case studies”.
• Zasoby (resources) to dane tylko do odczytu, na przykład plik logu albo schemat bazy danych.
• Prompty to gotowe szablony dla określonego typu interakcji.

Uzgadnianie możliwości i izolacja

Klient i serwer deklarują, które funkcje obsługują. W specyfikacji w wersji 2026-07-28 klient dołącza swoje możliwości do każdego żądania, a serwer ogłasza swoje w odpowiedzi na server/discover. Nasz publiczny endpoint deklaruje wcześniejsze wersje 2025-06-18, 2025-03-26 i 2024-11-05, więc nie korzysta z server/discover ani z żądań bezstanowych.

Z założenia serwer nie powinien widzieć całej rozmowy ani zaglądać do innych serwerów. Pełna historia zostaje u hosta, a serwer dowiaduje się tylko tego, co host mu przekaże.

Kto rozwija MCP

Od grudnia 2025 roku MCP należy do fundacji Agentic AI Foundation, działającej w ramach Linux Foundation, której Anthropic go przekazał; sposób zarządzania projektem się nie zmienił. Fundację założyli Anthropic, Block i OpenAI, a wspierają ją m.in. Google, Microsoft, AWS, Cloudflare i Bloomberg. Pierwsi użytkownicy wymienieni w ogłoszeniu z listopada 2024 roku to Block i Apollo oraz narzędzia deweloperskie Zed, Replit, Codeium i Sourcegraph. W grudniowym komunikacie Anthropic podał, że działa ponad 10 000 aktywnych publicznych serwerów MCP.

Tradycyjne API udostępnia stałe endpointy i zakłada, że programista z góry wie, które operacje wywołać. Serwer MCP publikuje listę narzędzi, każde z nazwą, opisem i typowanym schematem danych wejściowych. Klient pyta, co jest dostępne, i przekazuje te opisy modelowi, który sam wybiera potrzebne narzędzie. Podobnie opisują to zestawienia „Model Context Protocol (MCP) vs. APIs: Architecture & Use Cases” w Codecademy i „MCP vs API” w TrueFoundry.

MCP nie zastępuje API. W wielu systemach produkcyjnych serwer MCP wywołuje pod spodem istniejące API, więc API wyznacza granicę usługi, a MCP granicę agenta.

Zwykłe API wystarczy, gdy integrację pisze programista, który z góry zna operacje. Tak wygląda większość integracji system-system ze stałym kontraktem.

MCP ma sens, gdy z systemu będzie korzystać agent albo asystent AI (ChatGPT, Claude, Cursor), który sam wybiera narzędzia na podstawie ich opisów. Pomaga też wtedy, gdy jeden serwer ma obsłużyć wielu klientów AI naraz, bo każdy z nich czyta tę samą listę narzędzi zamiast dostawać osobną integrację.

MCP nie jest związany z Claude'em. Według grudniowego komunikatu Anthropic obsługują go też ChatGPT, Cursor, Gemini, Microsoft Copilot i Visual Studio Code.

Główne zagrożenia dla serwera MCP to zdezorientowany pośrednik, przekazywanie cudzego tokenu, fałszowanie żądań po stronie serwera, przejęcie uchwytu stanu, przejęcie lokalnego serwera i niezweryfikowane adresy autoryzacji OAuth. Część zabezpieczeń MCP jest wbudowana w sam protokół. Host egzekwuje zgody użytkownika i zasady, a serwer nie widzi ani całej rozmowy, ani innych serwerów. Reszta zależy od tego, jak zbudujesz i wdrożysz serwer.

Oficjalny przewodnik MCP „Security Best Practices” (wersja 2026-07-28) opisuje główne ataki:

• Zdezorientowany pośrednik (confused deputy). Serwer z własnymi uprawnieniami działa w imieniu klienta, który nie powinien ich mieć, na przykład przez współdzielonego klienta OAuth.
• Przekazywanie cudzego tokenu (token passthrough). Serwer przyjmuje token, który nie został dla niego wystawiony, i przekazuje go dalszym usługom, przez co audyt i kontrola dostępu przestają działać.
• Fałszowanie żądań po stronie serwera (SSRF). Serwer zostaje nakłoniony do wysłania żądań na wewnętrzne adresy, do których ma dostęp, a atakujący nie.
• Przejęcie uchwytu stanu (state handle hijacking). Atakujący ponownie używa albo odgaduje uchwyt, który wiąże żądania z wcześniejszą interakcją.
• Przejęcie lokalnego serwera MCP (local MCP server compromise). Serwer działający na komputerze użytkownika zostaje uruchomiony albo przejęty przez niezaufaną stronę.
• Niezweryfikowane adresy autoryzacji OAuth (unvalidated OAuth authorization URLs). Złośliwy serwer kieruje klienta na adres autoryzacji, któremu ten nie powinien ufać.

Przewodnik omawia też transport stdio w układach z proxy, kilka zagadnień OAuth (ataki mix-up, podszywanie się pod przekierowanie na localhost, zasady zaufania dla Client ID Metadata Documents) oraz minimalizację zakresów. Minimalizacja zakresów polega na tym, że klient najpierw prosi o najmniejszy zakres do odczytu, a o szersze uprawnienia dopiero przy operacji, która ich wymaga. Dla każdego z tych zagadnień przewodnik podaje sposoby ochrony.

Na naszym produkcyjnym serwerze MCP trzy bramki po stronie serwera decydują o tym, co agent AI może utworzyć, zapisać i opublikować. Serwer łączy agentów AI z CMS-em, na którym działa ta strona. Jego 164 narzędzia (stan na 20 października 2026 roku) obejmują strony, treści, SEO i GEO (generative engine optimization, czyli widoczność w odpowiedziach AI), schema.org, media, menu, przekierowania, analitykę Search Console i GA4 oraz leady. Tokenami dostępu i logiem wywołań zarządzamy w panelu Wagtaila. Nie mamy metryk biznesowych z tego wdrożenia.

Checklista dla CTO: twarde bramki na serwerze MCP udostępnionym agentom AI

1. Bez briefu strategii nie ma strony. Wywołanie create_page bez strategii, która przypisuje stronę do celu w naszym planie treści i do jej roli w lejku sprzedaży, kończy się błędem HTTP 400.
2. Bez zatwierdzenia przez człowieka nie ma treści. Zapis treści, gdy brief nie został zatwierdzony przez człowieka, kończy się błędem HTTP 409.
3. Bez czystego audytu nie ma publikacji. Publikacja zwraca HTTP 409, gdy audyt znajdzie fakty spoza zatwierdzonej checklisty, nazwy klientów objęte NDA albo brak werdyktu niezależnego agenta-krytyka.

Żadne narzędzie na serwerze nie ma parametru, który pozwalałby ominąć te bramki. Same bramki mają dwa wyjątki: tryb poprawki dla stron już opublikowanych, który publikuje szkic tylko wtedy, gdy audyt nie znajdzie w nim nic gorszego niż w wersji na żywo, oraz ręczna publikacja przez człowieka w panelu Wagtaila.

Dobre praktyki bezpieczeństwa MCP z naszego serwera produkcyjnego

Reguły, których agent nie może złamać, umieść na serwerze. Instrukcja w prompcie prosi model o przestrzeganie reguły, a kod odpowiedzi albo walidacja na serwerze ją wymusza. Reguły egzekwujemy kodami HTTP i walidacją, a prompt tylko je objaśnia.

Daj każdemu agentowi własny token i loguj każde wywołanie. Każdy agent ma własny token, więc każdy wpis w logu wywołań wskazuje jednego agenta i odpowiada na pytanie, który agent co zrobił.

Oddziel zakres publiczny od uwierzytelnionego. Od 8 października 2026 roku prowadzimy też publiczny endpoint MCP dla asystentów AI pod adresem https://ordergroup.co/mcp. Nie wymaga tokenu i pozwala tylko na odczyt i kontakt. Służą do tego dwa narzędzia: list_case_studies i submit_project_enquiry. Jest wpisany do oficjalnego rejestru MCP jako co.ordergroup/public (status „active”, wersja 1.0.0, opublikowany 8 października 2026 roku). Zapis w CMS-ie jest możliwy tylko z tokenem, więc agent bez autoryzacji może odczytać dane i wysłać zapytanie, nic więcej.

Czym różni się MCP od API?

API udostępnia stałe endpointy programiście, który z góry zna operacje. Serwer MCP publikuje listę narzędzi z nazwą, opisem i schematem danych wejściowych, a klient AI pyta, co jest dostępne, i pozwala modelowi wybrać. Na produkcji oba rozwiązania zwykle działają razem.

Czy MCP zastępuje API?

Nie. MCP dodaje warstwę dla agentów AI nad systemami, które już masz. W wielu wdrożeniach produkcyjnych serwer MCP wywołuje pod spodem istniejące API, więc API pozostaje granicą usługi, a MCP staje się granicą agenta.

Kiedy wybrać MCP zamiast API?

MCP wybierz wtedy, gdy z systemem będzie pracować agent albo asystent AI, na przykład ChatGPT, Claude czy Cursor, który sam wybiera narzędzia na podstawie opisów, albo gdy jeden serwer ma obsłużyć wielu klientów AI. Gdy programista pisze integrację system-system ze stałym kontraktem, wystarczy API.

Czy MCP jest bezpieczny?

Część ochrony jest wbudowana w protokół: host egzekwuje zgody użytkownika i zasady, a serwer nie widzi całej rozmowy ani innych serwerów. Reszta zależy od serwera. Oficjalny przewodnik opisuje ataki takie jak zdezorientowany pośrednik (confused deputy), przekazywanie cudzego tokenu (token passthrough) i fałszowanie żądań po stronie serwera (SSRF), każdy razem ze sposobami ochrony.

Jakie są dobre praktyki bezpieczeństwa MCP?

Reguły, których agent nie może złamać, egzekwuj na serwerze kodami odpowiedzi i walidacją. Daj każdemu agentowi własny token i loguj każde wywołanie. Oddziel publiczny zakres tylko do odczytu od uwierzytelnionego, a o uprawnienia proś stopniowo: najpierw najmniejszy zakres, więcej dopiero wtedy, gdy operacja tego wymaga.

Czy MCP działa tylko z Claude'em?

Nie. MCP stworzył Anthropic, ale w grudniu 2025 roku przekazał protokół fundacji Agentic AI Foundation, działającej w ramach Linux Foundation. Według tego samego komunikatu MCP obsługują też ChatGPT, Cursor, Gemini, Microsoft Copilot i Visual Studio Code.

Jeśli zastanawiasz się, czy Twój produkt potrzebuje serwera MCP, API czy obu naraz, zobacz nasze usługi tworzenia serwerów MCP, usługi tworzenia oprogramowania AI albo umów bezpłatną konsultację.