← Wróć do bloga

MCP: co to jest Model Context Protocol i kiedy naprawdę go potrzebujesz?

MCP łączy aplikacje AI z danymi i narzędziami. Zobacz, jak działa, czym różni się od API i kiedy naprawdę warto go użyć.

Opublikowano: 4 min czytania

MCP, czyli Model Context Protocol, to otwarty standard łączenia aplikacji AI z zewnętrznymi danymi i narzędziami. Pozwala klientowi AI odkryć udostępnione możliwości i korzystać z nich przez wspólny protokół, zamiast budować osobną integrację dla każdej pary aplikacji i źródła danych.

Porównanie MCP do USB-C jest wygodne, ale trochę zbyt gładkie. Samo wspólne złącze nie rozwiązuje uprawnień, jakości narzędzi ani bezpieczeństwa decyzji modelu.

Co to jest MCP?

Anthropic opublikował Model Context Protocol w listopadzie 2024 roku. Aktualna dokumentacja definiuje go jako otwarty standard łączenia aplikacji AI z systemami zewnętrznymi: plikami, bazami danych, wyszukiwarkami, kalkulatorami i workflowami.

W typowym układzie występują trzy elementy:

  • host: aplikacja, w której działa użytkownik i model, na przykład narzędzie programistyczne,
  • client: komponent utrzymujący połączenie z konkretnym serwerem MCP,
  • server: program udostępniający dane, prompty lub narzędzia przez protokół MCP.

Serwer może wystawić narzędzie do wyszukania dokumentów, pobrania rekordu z CRM albo utworzenia zadania. Klient pobiera opis możliwości i przekazuje go modelowi. Gdy model wybierze narzędzie, host nadal odpowiada za wywołanie i kontrolę całej operacji.

MCP a zwykłe API

MCP nie zastępuje API. Najczęściej stoi nad nim.

Jeśli system ma już endpoint POST /tasks, serwer MCP może opakować go jako narzędzie create_task z opisanymi parametrami. API nadal wykonuje właściwą operację, a MCP ujednolica sposób, w jaki aplikacja AI ją odkrywa i wywołuje.

Bez MCP każda aplikacja AI może potrzebować własnej warstwy integracyjnej. Z MCP jeden serwer może być używany przez wielu zgodnych klientów. To ma znaczenie, gdy:

  • chcemy udostępnić ten sam system kilku narzędziom AI,
  • zestaw możliwości zmienia się i powinien być odkrywany dynamicznie,
  • potrzebujemy wspólnego sposobu opisu narzędzi i zasobów,
  • zależy nam na przenośności między klientami.

Jeśli budujemy jedną zamkniętą aplikację z trzema stabilnymi funkcjami, bezpośrednie function calling może być prostsze. Nowy protokół nie powinien być nagrodą za użycie AI.

Co może udostępniać serwer MCP?

Najczęściej spotkamy trzy rodzaje możliwości:

Narzędzia

To operacje, które model może wybrać, na przykład search_orders, create_issue albo run_test. Narzędzie ma nazwę, opis i schemat parametrów.

Zasoby

Zasoby dostarczają kontekst: plik, dokument, rekord albo wynik zapytania. Klient może je odczytać bez udawania, że każde pobranie danych jest osobną „akcją”.

Prompty i workflowy

Serwer może udostępniać gotowe procedury lub szablony pracy. To wygodne, gdy wiedza o sposobie użycia systemu powinna być utrzymywana blisko integracji.

MCP nie jest warstwą bezpieczeństwa

Protokół ułatwia połączenie. Nie odpowiada automatycznie na pytanie, czy model powinien dostać dostęp.

Przed podłączeniem serwera warto rozdzielić co najmniej cztery sprawy:

  1. Tożsamość: w imieniu którego użytkownika działa klient?
  2. Uprawnienia: jakie dane i operacje są dostępne dla tej osoby?
  3. Zgoda: które działania wymagają zatwierdzenia przed wykonaniem?
  4. Audyt: czy potrafimy ustalić, co model wywołał i z jakim wynikiem?

Serwer MCP z narzędziem delete_customer nie staje się bezpieczny dlatego, że schemat jest poprawny. Operacja nadal potrzebuje ograniczeń, potwierdzenia i najlepiej odwracalnego przebiegu.

Dochodzi też prompt injection. Dokument pobrany jako kontekst może zawierać tekst próbujący nakłonić model do użycia narzędzia. Dane zewnętrzne trzeba traktować jak dane, nie jak instrukcje o wyższym priorytecie.

Kiedy MCP naprawdę pomaga?

MCP jest dobrym wyborem, gdy integracja ma żyć dłużej niż jeden prototyp i obsługiwać więcej niż jednego klienta. Szczególnie wtedy, gdy organizacja chce wystawić spójny katalog kontrolowanych możliwości dla różnych agentów.

Przykład: zespół ma dokumentację w jednym systemie, projekty w drugim i analitykę w trzecim. Zamiast pisać osobne wtyczki do każdego asystenta, przygotowuje serwery MCP z małym, świadomie wybranym zestawem operacji. Różne klienty korzystają z tego samego kontraktu, ale uprawnienia nadal wynikają z tożsamości użytkownika.

MCP nie pomoże, jeśli prawdziwym problemem jest nieczytelne API, nieaktualne dane albo brak modelu uprawnień. Wtedy tylko udostępnimy agentowi bałagan przez nowszy protokół.

Jak zacząć bez dokładania ryzyka?

Wybrałbym jedną operację tylko do odczytu, na przykład wyszukiwanie dokumentacji.

Następnie:

  1. zdefiniuj wąski schemat wejścia,
  2. zwracaj mały, jednoznaczny wynik,
  3. loguj każde wywołanie,
  4. sprawdź zachowanie na zestawie realistycznych pytań,
  5. dopiero później dodaj zapis i osobną bramkę akceptacji.

Opis narzędzia jest częścią interfejsu dla modelu. Jeśli dwie operacje brzmią prawie tak samo, agent również może je mylić. Więcej zasad znajdziesz w przewodniku o projektowaniu narzędzi i API dla agentów.

MCP daje agentowi drogę do danych i działań. To środowisko agenta decyduje, jak daleko może tą drogą dojść.

Źródła