MCP (Model Context Protocol) - czym jest i dlaczego zmieni AI w firmach

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.

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

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ł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:

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:

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.

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.

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.

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.

Reguła kciuka 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.