Model Context Protocol (MCP) - co to jest i po co w Claude Code

MCP (Model Context Protocol) to wspólny język, którym Claude rozmawia z Twoimi narzędziami i danymi. Wyjaśniamy, czym jest i dlaczego zmienia sposób pracy z AI.

Masz pięć modeli AI i osiem firmowych systemów, które chcesz z nimi spiąć: bazę zamówień, system obsługi klienta, repozytorium dokumentów, pocztę, kalendarz. Ile integracji musisz napisać? W najgorszym wariancie pięć razy osiem, czyli czterdzieści osobnych kawałków kodu - i każdy trzeba utrzymywać, gdy zmieni się którekolwiek z połączonych narzędzi. To problem typu „N razy M", przez który wdrożenia agentów AI w firmach grzęzną w klejeniu integracji, zamiast dawać wartość. Model Context Protocol (MCP) rozwiązuje go tak, jak gniazdo USB-C rozwiązało chaos kabli: jednym wspólnym standardem, w którym dowolny model rozmawia z dowolnym narzędziem. Ten artykuł tłumaczy, jak to działa, pokazuje kod i mówi uczciwie, gdzie MCP to przesada.

Z tego artykułu wyniesiesz:

• Na czym polega problem „N razy M" i dlaczego paraliżuje integracje AI w firmach
• Architekturę MCP: gospodarza i klienta, protokół, serwery udostępniające narzędzia i dane
• Gotowy kod: konfiguracja serwera (JSON), minimalny serwer MCP w Pythonie, definicja narzędzia
• Realne zastosowania firmowe oraz to, jak MCP porządkuje bezpieczeństwo i kontrolę dostępu
• Czym MCP różni się od zwykłego wywołania API i kiedy lepiej go nie używać

Problem „N razy M", czyli dlaczego integracje AI grzęzną

Zanim pojawił się wspólny standard, każde połączenie modelu AI z firmowym narzędziem trzeba było napisać od zera. Wyobraź sobie, że chcesz, by Twój asystent AI potrafił:

• sprawdzić status zamówienia w systemie ERP,
• pobrać dokument z firmowego repozytorium,
• zapisać notatkę w systemie obsługi klienta (CRM),
• sprawdzić wolne terminy w kalendarzu,
• uruchomić zapytanie do bazy danych.

Dla jednego modelu to pięć integracji. Problem zaczyna się, gdy masz kilka modeli (asystent w przeglądarce, asystent w edytorze kodu, agent działający w tle) i kilka narzędzi. Liczba potrzebnych połączeń to iloczyn: N modeli razy M narzędzi. Każde z nich ma własny format danych, własną obsługę błędów i własny sposób uwierzytelniania. Zmienisz model - przepisujesz integracje. Zaktualizujesz API systemu obsługi klienta - poprawiasz w kilku miejscach naraz. To nie jest praca, która buduje wartość, tylko podatek od fragmentacji.

MCP odwraca tę logikę. Zamiast łączyć każdy model z każdym narzędziem osobno, definiujesz wspólny protokół. Narzędzie udostępniasz raz - jako serwer MCP - a korzysta z niego dowolny klient. Z iloczynu „N razy M" robi się suma „N plus M": tyle serwerów, ile masz narzędzi, plus tyle klientów, ile masz modeli. Nic więcej.

Gospodarz + klient AI

asystent, edytor, agent

↔

Protokół MCP

(JSON-RPC)

↔

Serwer: baza danych

zapytania SQL

Serwer: pliki

repozytorium dokumentów

Serwer: CRM

kontakty, notatki

Jeden wspólny protokół zamiast osobnej integracji dla każdej pary model-narzędzie. Klient AI podłącza dowolny serwer MCP bez przepisywania kodu.

Jak działa MCP - gospodarz, klient, serwer

MCP opisuje rozmowę między trzema elementami. Warto je rozróżnić, bo nazwy bywają mylone.

Gospodarz i klient (strona AI)

Gospodarz (host) to aplikacja, w której pracujesz z modelem: asystent w przeglądarce, asystent w edytorze kodu, agent uruchomiony na serwerze. Gospodarz osadza w sobie klienta (client) - komponent, który nawiązuje i utrzymuje połączenie z konkretnym serwerem MCP oraz tłumaczy między modelem a protokołem. Jeden gospodarz może mieć wielu klientów, po jednym na każdy podłączony serwer.

Serwer (strona narzędzi i danych)

Serwer MCP to lekki program, który udostępnia trzy rodzaje rzeczy: narzędzia (tools, czyli akcje, które model może wywołać - na przykład „sprawdź status zamówienia"), zasoby (resources, czyli dane do odczytu - pliki, rekordy bazy) oraz szablony promptów (prompts, czyli gotowe wzorce instrukcji). Co kluczowe, serwer sam opisuje, co potrafi: podaje nazwę narzędzia, jego opis po ludzku i schemat danych wejściowych. Dzięki temu model nie musi mieć tej wiedzy zaszytej z góry - odkrywa ją w trakcie.

Protokół (warstwa komunikacji)

Klient i serwer rozmawiają w ustandaryzowanym formacie wiadomości opartym o JSON-RPC (lekki protokół zdalnego wywoływania procedur w formacie JSON). Połączenie może działać lokalnie (serwer uruchomiony jako proces na tej samej maszynie, komunikacja przez standardowe wejście i wyjście) albo zdalnie, po sieci. Przepływ jednej operacji wygląda tak:

Użytkownik  ->  „Jaki jest status zamówienia 4815?"

Klient AI  ->  pyta serwer: jakie masz narzędzia?

Serwer MCP ->  zwraca: get_order_status(order_id)

Model      ->  decyduje wywołać get_order_status z argumentem "4815"

Serwer MCP ->  odpytuje ERP, zwraca: {"status":"wysłane","kurier":"DPD"}

Model      ->  „Zamówienie 4815 zostało wysłane kurierem DPD."

Najważniejsze w tym przepływie jest to, że model sam decyduje, którego narzędzia użyć i z jakimi argumentami - na podstawie opisu, który serwer mu udostępnił. Nikt nie zaprogramował z góry, że pytanie o status zamówienia ma wywołać akurat to narzędzie. To różnica między sztywno spiętym przewodem a wspólnym gniazdem, do którego podłączasz, co chcesz.

Konfiguracja: jak podłączyć serwer MCP

Najprostsza droga do MCP nie wymaga pisania kodu. Gotowe serwery podłącza się przez plik konfiguracyjny w formacie JSON, w którym wskazujesz, jak uruchomić serwer i jakie ma mieć ustawienia. Przykład, który podłącza dwa serwery naraz - dostęp do plików i do bazy PostgreSQL:

{

  "mcpServers": {

    "pliki-firmowe": {

      "command": "npx",

      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/dane/dokumenty"]

    },

    "baza-zamowien": {

      "command": "npx",

      "args": ["-y", "@modelcontextprotocol/server-postgres"],

      "env": { "DATABASE_URL": "postgres://sklep:tajne_hasł[e-mail]/sklep" }

    }

  }

}

Pole env wstrzykuje zmienne środowiskowe do procesu serwera MCP - to standardowy sposób przekazywania poświadczeń bez wpisywania ich bezpośrednio w komendę. W przykładzie DATABASE_URL to connection string do PostgreSQL w formacie postgres://użytkownik:hasło@host/baza. Wstaw tam swoje rzeczywiste dane. Uważaj, żeby plik konfiguracyjny nie trafiał do repozytorium kodu razem z hasłem - dla produkcyjnych środowisk lepiej odczytywać hasło z menadżera sekretów i wstrzykiwać je osobno.

Gdzie zapisać plik konfiguracyjny

Lokalizacja pliku zależy od używanego klienta. Poniżej najczęstsze przypadki:

Klient	Lokalizacja pliku
Claude Desktop (macOS)	~/Library/Application Support/Claude/claude_desktop_config.json
Claude Desktop (Windows)	%APPDATA%\Claude\claude_desktop_config.json
Claude Code (CLI)	komenda claude mcp add lub plik .mcp.json w katalogu projektu
Cursor	.cursor/mcp.json (lokalnie, dla projektu) lub ~/.cursor/mcp.json (globalnie)

Jeśli plik nie istnieje, utwórz go ręcznie - wklej całą powyższą strukturę JSON jako jego zawartość. W Claude Desktop możesz też wejść w Settings > Developer i tam znajdziesz przycisk otwierający ten plik w edytorze. Po zapisaniu i ponownym uruchomieniu aplikacji asystent „widzi" oba serwery. Może czytać dokumenty z katalogu /dane/dokumenty i zadawać pytania do bazy zamówień. Zwróć uwagę na użytkownika bazy: w produkcyjnym środowisku powinno to być konto z uprawnieniami wyłącznie do odczytu, nie administrator. O tym, dlaczego to ważne, za chwilę.

Minimalny serwer MCP - własne narzędzie w Pythonie

Gotowe serwery wystarczą do wielu zadań, ale prawdziwa siła MCP to możliwość udostępnienia własnego, wewnętrznego systemu firmowego. Powiedzmy, że masz starszy system ERP z prostym API i chcesz, by asystent potrafił sprawdzić w nim status zamówienia. Wystarczy serwer MCP udostępniający jedno narzędzie. Oficjalny pakiet dla Pythona pozwala napisać go bardzo zwięźle:

# pip install "mcp[cli]"

from mcp.server.fastmcp import FastMCP

import httpx



server = FastMCP("firmowy-erp")



@server.tool()

def get_order_status(order_id: str) -> dict:

    """Sprawdza status zamówienia po numerze w firmowym systemie ERP."""

    r = httpx.get(f"https://erp.firma.pl/api/orders/{order_id}",

                  headers={"Authorization": "Bearer tajny_token_erp"}, timeout=10)

    r.raise_for_status()

    dane = r.json()

    # Udostępniamy tylko to, co bezpieczne - bez danych płatności

    return {

        "numer": dane["id"],

        "status": dane["status"],

        "kurier": dane.get("carrier"),

        "data_wysylki": dane.get("shipped_at"),

    }



if __name__ == "__main__":

    server.run()

Authorization: Bearer <token> to standardowy nagłówek HTTP do uwierzytelniania API - "Bearer" oznacza "okaziciel", czyli kto ma token, ten ma dostęp. Token generujesz lub pobierasz z ustawień swojego systemu ERP i wklejasz w miejsce tajny_token_erp.

To kompletny, działający serwer. Dekorator @server.tool() rejestruje funkcję jako narzędzie dostępne dla modelu. Co istotne, opis narzędzia bierze się wprost z dokumentacji funkcji i jej sygnatury - tekst „Sprawdza status zamówienia po numerze" oraz parametr order_id: str trafiają do schematu, który serwer pokazuje klientowi. Na tej podstawie model sam zdecyduje, kiedy narzędzie wywołać. Nie musisz pisać żadnego dodatkowego mapowania - schemat generuje się z kodu.

Gdy chcesz udostępnić nie akcję, lecz dane do odczytu, używasz zasobu. Ta sama biblioteka pozwala wystawić na przykład cennik jako zasób, który model może wczytać do kontekstu:

@server.resource("cennik://aktualny")

def cennik() -> str:

    """Aktualny cennik usług w formacie tekstowym."""

    with open("/dane/cennik.md", encoding="utf-8") as f:

        return f.read()

Różnica między narzędziem a zasobem jest celowa: narzędzie coś robi (i model może to wywołać samodzielnie), zasób dostarcza danych (i zwykle to gospodarz decyduje, kiedy go wczytać). To rozróżnienie pomaga panować nad tym, co model może zrobić, a co tylko przeczytać.

Realne zastosowania w firmie

MCP nie jest abstrakcją dla entuzjastów - rozwiązuje konkretne, kosztowne problemy. Kilka scenariuszy, które powtarzają się w organizacjach:

Scenariusz	Co udostępnia serwer MCP	Efekt
Asystent obsługi klienta	Odczyt zamówień z ERP, historia kontaktu z CRM	Konsultant pyta naturalnym językiem, asystent zbiera kontekst z dwóch systemów naraz
Wewnętrzna baza wiedzy	Repozytorium dokumentów, wyszukiwarka procedur	Pracownik dostaje odpowiedź z firmowych dokumentów, zamiast szukać po dyskach
Analityka na żądanie	Zapytania tylko do odczytu na hurtowni danych	Osoba nietechniczna pyta o liczby, model układa i uruchamia bezpieczne zapytanie
Wsparcie zespołu IT	Odczyt zgłoszeń z systemu obsługi zgłoszeń, status usług	Agent koreluje zgłoszenia z monitoringiem przy diagnozie awarii

Wspólny mianownik tych zastosowań: jeden serwer MCP obsługuje wiele klientów. Ten sam serwer udostępniający bazę zamówień działa zarówno dla asystenta w przeglądarce, jak i dla agenta w tle generującego raporty. Napisany raz, używany wszędzie - to jest oszczędność, którą daje standard.

Chcesz zbudować bezpiecznych agentów AI z dostępem do firmowych systemów? Szkolenie z Model Context Protocol w JSystems · od podłączenia gotowych serwerów po własny serwer dla wewnętrznego systemu · 2 dni warsztatów z praktykiem Zobacz szkolenie MCP

Bezpieczeństwo i kontrola dostępu

Tu kryje się największa przewaga MCP nad podejściem „daj modelowi klucz API i licz na rozsądek". Wcześniej agent często dostawał poświadczenia z pełnymi uprawnieniami i mógł zrobić wszystko, co pozwalało API. MCP wprowadza warstwę, w której Ty decydujesz, co model może, a czego nie.

• Wąski zakres uprawnień (granular permissions). Serwer udostępnia tylko wybrane operacje. Jeśli wystawiasz bazę, robisz to przez konto z prawem wyłącznie do odczytu - model fizycznie nie może niczego skasować, nawet gdyby „zechciał".
• Ślad audytowy (audit trail). Każde wywołanie narzędzia przechodzi przez serwer, więc każde da się zalogować: kto, kiedy, z jakimi argumentami i z jakim wynikiem. Masz pełny rejestr działań agenta.
• Zatwierdzanie przez użytkownika. Gospodarz może wymagać, by przed operacją wrażliwą (zapis, wysłanie wiadomości, usunięcie) człowiek kliknął „potwierdź". Model proponuje, człowiek decyduje.
• Izolacja. Model nigdy nie dotyka systemu bezpośrednio - rozmawia tylko z serwerem przez ustandaryzowany interfejs. Serwer jest jedyną bramą i jedynym miejscem, w którym egzekwujesz reguły.

Uwaga: sam MCP nie czyni nic bezpiecznym automatycznie - to tylko warstwa komunikacji. Bezpieczeństwo wynika z tego, jak zbudujesz serwer. Konto z pełnymi prawami do bazy, brak walidacji argumentów albo wystawienie zdalnego serwera bez uwierzytelniania zamieniają zaletę w zagrożenie. Zasada minimalnych uprawnień obowiązuje tu tak samo jak wszędzie indziej.

Dla firm, które porządkują wdrożenia AI pod kątem audytowalności i kontroli, ta architektura jest praktyczną odpowiedzią: działania agenta są rejestrowane, ograniczone do zdefiniowanego zakresu i możliwe do przeglądu w każdej chwili.

Ekosystem gotowych serwerów

Nie wszystko trzeba pisać samemu. Wokół MCP powstał szybko rosnący zbiór gotowych serwerów, które podłączysz samą konfiguracją:

• System plików - bezpieczny, ograniczony do wskazanego katalogu dostęp do dokumentów.
• Bazy danych - PostgreSQL, SQLite i inne, z możliwością ograniczenia do odczytu.
• Repozytoria kodu - repozytoria, zgłoszenia, żądania scalenia, wyszukiwanie w kodzie.
• Komunikatory i poczta - kanały, wiadomości, użytkownicy.
• Systemy zarządzania pracą - zgłoszenia, projekty, sprinty.
• Pobieranie stron - wczytywanie zawartości adresów internetowych do kontekstu.

Praktyczna konsekwencja: typowe wdrożenie zaczyna się od kilku gotowych serwerów (pliki, baza, repozytorium kodu), a własny serwer piszesz tylko dla tego, czego nikt jeszcze nie wystawił - zwykle wewnętrznego systemu firmowego. To znacząco skraca drogę od pomysłu do działającego agenta.

Czym MCP różni się od zwykłego wywołania API

To pytanie pada najczęściej: „przecież mój kod już potrafi wołać API, po co dokładać warstwę?". Różnica jest istotna i sprowadza się do tego, kto decyduje i jak bardzo rozwiązanie jest przenośne.

Aspekt	Zwykłe wywołanie API	MCP
Kto decyduje o wywołaniu	Programista, z góry, w kodzie	Model, dynamicznie, na podstawie opisu narzędzia
Opis możliwości	W dokumentacji, dla człowieka	W schemacie, który serwer podaje modelowi
Przenośność	Związane z jedną aplikacją lub modelem	Jeden serwer działa z dowolnym klientem MCP
Dodanie narzędzia	Zmiana kodu integracji	Podłączenie kolejnego serwera w konfiguracji
Kontrola i audyt	Do zbudowania osobno	Wbudowane w architekturę (jedna brama)

Innymi słowy: zwykłe wywołanie API to sztywny przewód między dwoma punktami, który ktoś zaprojektował i którego nie da się łatwo przełożyć gdzie indziej. MCP to wspólne gniazdo - serwer raz opisuje, co potrafi, a każdy zgodny klient może się podłączyć i pozwolić modelowi samodzielnie sięgnąć po właściwe narzędzie. Stąd porównanie do USB-C: jedno gniazdo zamiast szuflady pełnej niekompatybilnych kabli.

Gdzie MCP to przesada

Uczciwy artykuł musi powiedzieć też, kiedy nie warto. MCP to standard projektowany pod skalę i kontrolę - w prostych przypadkach dokłada warstwę, która niczego nie ułatwia.

• Jeden model, jedno narzędzie, jednorazowo. Jeśli piszesz skrypt, który raz na dobę odpytuje jedno API, zwykłe wywołanie funkcji jest prostsze i czytelniejsze. Serwer MCP to tu zbędny ceremoniał.
• Brak wymagań co do kontroli i audytu. Gdy nie potrzebujesz rejestrowania działań ani ograniczania uprawnień, główna korzyść z MCP odpada.
• Stała, niezmienna integracja. Jeśli model nie ma niczego „wybierać", bo logika jest sztywno ustalona, dynamiczne odkrywanie narzędzi nie wnosi nic poza narzutem.
• Bardzo wczesny prototyp. Na etapie sprawdzania pomysłu szybciej zobaczysz efekt, wołając API wprost. MCP wprowadzisz, gdy prototyp dojrzeje i pojawi się więcej narzędzi lub klientów.

Zasada jest prosta: im więcej narzędzi, im więcej klientów AI i im większa potrzeba kontroli, tym większa korzyść z MCP. Przy jednym połączeniu bez wymagań bezpieczeństwa to przerost formy nad treścią. Dobre wdrożenie zaczyna się od pytania „ile par model-narzędzie naprawdę będę mieć i czy muszę panować nad tym, co agent może zrobić".

Podsumowanie

MCP rozwiązuje konkretny, kosztowny problem: zamienia iloczyn „N modeli razy M narzędzi" na sumę „N plus M", a przy okazji daje warstwę kontroli, której brakowało, gdy agenci dostawali klucze API z pełnym dostępem. Serwer udostępnia narzędzia i dane raz, opisując je w sposób zrozumiały dla modelu, a dowolny zgodny klient z nich korzysta. To samo gniazdo, ta sama wtyczka, dowolne urządzenie. Dla firm wdrażających agentów AI to przejście od klejenia integracji do budowania na wspólnym fundamencie - i właśnie dlatego MCP realnie zmienia sposób, w jaki AI łączy się z systemami organizacji. Warto poznać go teraz, zanim stanie się tak oczywisty jak dziś REST API.

Model Context Protocol - agenci AI w organizacji Praktyczne szkolenie JSystems: od podłączenia gotowych serwerów MCP po własny serwer dla firmowego systemu, z naciskiem na bezpieczeństwo i kontrolę dostępu. 2 dni warsztatów. Sprawdź terminy i zapisz się