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

MCP to protokół, który zmienia Claude Code z izolowanego asystenta w agenta podłączonego do Twoich realnych systemów.

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.

![JSystems](https://jsystems.pl/static/images/logo-colored.svg)

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:

```plaintext
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:

```json
{

  "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ło@sklep.pl/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](https://jsystems.pl/blog/show_post/claude_code_kompletny_przewodnik_dla_programistow) (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:

```python
# 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:

```python
@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](https://jsystems.pl/szkolenia-ai;mcp.szczegoly?utm_source=blog&utm_medium=article&utm_campaign=post382&utm_content=link_mcp-model-context-protocol-ai)

## 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ę](https://jsystems.pl/szkolenia-ai;mcp.szczegoly?utm_source=blog&utm_medium=article&utm_campaign=post382&utm_content=link_mcp-model-context-protocol-ai)