MCP (Model Context Protocol)

1. Przegląd koncepcji i problem systemowy

Przed pojawieniem się protokołu MCP ekosystem narzędzi agentowych borykał się z klasycznym problemem niespójności $N \times M$:

1. Fragmentacja adapterów: Jeśli dysponujesz 5 klientami AI (Cursor, Claude Desktop, Continue, wewnętrzny agent CLI, interfejs webowy) oraz 10 źródłami danych (PostgreSQL, GitHub, Slack, Sentry, lokalny system plików), inżynierowie musieli tworzyć i utrzymywać 50 osobnych konektorów integracyjnych.
2. Wyciek wrażliwych kluczy: Aplikacje klienckie wymagały przekazywania bezpośrednich tokenów API do swojego kontekstu, co zwiększało powierzchnię ataku.
3. Brak ujednoliconej typizacji zasobów: Nie istniał standard określający, jak model powinien pobierać dane pasywne (dokumenty do odczytu) oddzielnie od aktywnych działań skutkujących efektami ubocznymi (mutacje w bazie danych).

Model Context Protocol (MCP) rozwiązuje ten problem analogicznie do Language Server Protocol (LSP) w świecie IDE: jest to „USB-C dla sztucznej inteligencji”, które ujednolica interakcję między klientami AI a narzędziami backendowymi poprzez otwarty protokół JSON-RPC 2.0.

2. Taksonomia architektoniczna i model mentalny

Protokół MCP opiera się na wyraźnym podziale klient-serwer i operuje na trzech głównych prymitywach:

• 1. Tools (Aktywne narzędzia z efektami ubocznymi): Wykonywalne funkcje, które model może wywołać w celu zmiany stanu świata zewnętrznego (wykonanie zapytania SQL, uruchomienie builda, wysłanie komentarza na GitHub). Opisane za pomocą rygorystycznej schemy JSON Schema.
• 2. Resources (Pasywne źródła danych do odczytu): Dane adresowane przez URI bez efektów ubocznych, przekazywane do kontekstu modelu jako dokumenty (zawartość plików, logi serwera, schematy tabel, dokumentacja).
• 3. Prompts (Szablony interakcji): Z góry sparametryzowane prompty i łańcuchy kontekstowe, które serwer proponuje klientowi (np. gotowa instrukcja do audytu podatności lub generowania migracji).
• 4. Warstwa transportowa (Transport Layer):
  • stdio: Uruchomienie serwera jako procesu potomnego na tej samej maszynie. Nie wymaga portów sieciowych, charakteryzuje się zerowym narzutem latencji.
  • SSE (Server-Sent Events): Działanie przez HTTP/HTTPS, umożliwiające podłączanie zdalnych mikrousług korporacyjnych oraz agentów chmurowych.

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia sesji w protokole MCP przechodzi przez 4 etapy:

1. Handshake & Capabilities Negotiation (Uścisk dłoni): Klient wysyła żądanie initialize, deklarując swoje możliwości (np. obsługę powiadomień czy folderów root). Serwer odpowiada listą swoich możliwości (Tools, Resources, Prompts) oraz wersją protokołu.
2. Dynamic Discovery (Odkrywanie usług): Klient pyta o manifesty za pośrednictwem tools/list lub resources/list. Otrzymane opisy funkcji i parametrów są automatycznie translatowane do formatu Function Calling dla docelowego LLM.
3. Execution & Context Invocation (Wywołanie akcji): Gdy model generuje wywołanie funkcji, klient translateruje je w żądanie tools/call skierowane do odpowiedniego serwera MCP ze zwalidowanymi parametrami JSON.
4. Result Streaming & State Notification (Zwrot wyniku): Serwer wykonuje akcję lokalnie, wykorzystując własne bezpieczne konfiguracje (bez przekazywania haseł klientowi) i zwraca wynik w formacie tekstu, obrazów lub osadzonych zasobów.

4. Praktyczne scenariusze inżynierskie w środowisku produkcyjnym

01. Bezpieczny dostęp do produkcyjnej bazy danych

Serwer MCP dla PostgreSQL działa wewnątrz zamkniętego konturu VPC. Udostępnia on dla Cursor lub Claude Code wyłącznie narzędzie execute_read_only_query. Agent może analizować schemat i optymalizować wolne zapytania, nie mając bezpośredniego dostępu do hasła bazy danych ani uprawnień do usuwania danych.

02. Ujednolicony lokalny warsztat deweloperski

Jednorazowo napisany serwer MCP do interakcji z korporacyjnym GitLab, wewnętrzną Jirą oraz serwisem metryk Datadog jest podłączany jednocześnie do terminala CLI (Claude Code), edytora graficznego (Cursor) oraz zautomatyzowanych GitHub Actions.

03. Automatyzacja przeglądarkowa z Puppeteer/Playwright

Serwer MCP zarządza headless-przeglądarką, udostępniając klientowi narzędzia navigate_to, click_element, take_screenshot. Agent samodzielnie testuje interfejsy i waliduje design bez konieczności instalowania ciężkich zewnętrznych pluginów.

5. Pułapki, typowe błędy i bezpieczeństwo

• Zasysanie okna kontekstowego (Context Bloat): Podłączenie 15 serwerów MCP ze setką szczegółowych schem JSON może zużyć ponad 30 000 tokenów jeszcze przed wprowadzeniem pierwszego słowa przez użytkownika. Stosuj dynamiczną filtrację lub leniwe ładowanie narzędzi (Dynamic Tool Selection).
• Niebezpieczeństwo obcych serwerów (Arbitrary Code Execution): Lokalny serwer MCP działa z pełnymi uprawnieniami Twojego konta OS. Uruchamianie niezweryfikowanych serwerów przez npx -y bez sprawdzenia kodu źródłowego może prowadzić do kradzieży lokalnych kluczy SSH.
• Naruszenie kontraktu protokołu przez logowanie: Użycie standardowego console.log() lub print() wewnątrz kodu serwera korumpuje kanał stdout w transporcie stdio. Diagnostykę zapisuj wyłącznie w stderr.