MCP (Model Context Protocol) - jeden standard, żeby podłączyć AI do wszystkich narzędzi firmy

MCP (Model Context Protocol) to otwarty standard komunikacji między aplikacjami AI a zewnętrznymi narzędziami i danymi - opublikowany przez Anthropic w listopadzie 2024 i w ciągu kilkunastu miesięcy przyjęty przez OpenAI, Google DeepMind i Microsoft. Rozwiązuje problem N×M: zamiast budować osobną integrację każdej aplikacji AI z każdym narzędziem (4 aplikacje × 4 narzędzia = 16 integracji), budujesz po jednym adapterze na każdą stronę (4 + 4 = 8). Jeśli Twoje narzędzia mają obsługiwać wiele aplikacji AI (Claude, ChatGPT, Cursor, własny agent) - MCP jest właściwym wyborem. Jeśli budujesz jedną aplikację z kilkoma funkcjami - wystarczy zwykły function calling, MCP byłby przerostem formy.

Kompletny przewodnik po MCP: jaki problem rozwiązuje protokół, jak działa architektura host-klient-serwer, czym różni się od function callingu i OpenAPI, jak zbudować własny serwer MCP w Pythonie i TypeScript, które gotowe serwery podłączyć do firmowych narzędzi i jak zabezpieczyć wdrożenie przed tool poisoningiem.

Twoja firma ma agenta AI w obsłudze klienta, asystenta w Slacku i copilota dla zespołu sprzedaży. Każdy z nich potrzebuje dostępu do CRM, bazy danych i kalendarza. Bez standardu piszesz dziewięć integracji - a gdy CRM zmieni API, poprawiasz trzy aplikacje naraz. Dokładnie ten ból doprowadził do powstania MCP.

Skala adopcji mówi sama za siebie: ponad 5 800 publicznych serwerów MCP w rejestrze, ~97 milionów pobrań SDK miesięcznie i wsparcie czterech największych graczy AI. W 2026 MCP przestał być ciekawostką - stał się decyzją architektoniczną, którą musi rozważyć każda firma wdrażająca agentów. Ten artykuł wyjaśnia, jak protokół działa, kiedy go używać i jak wdrożyć go bezpiecznie.

Jaki problem rozwiązuje MCP?

Przed MCP każda integracja AI z narzędziem była niestandardowa. LangChain miał swoje "tools", OpenAI swoje "functions", każdy framework własny format definicji i własną obsługę błędów. Efekt: ekosystem fragmentaryczny, integracje nieprzenośne, a każda nowa aplikacja AI w firmie zaczynała od zera.

MCP standaryzuje trzy rzeczy:

• Odkrywanie narzędzi - aplikacja AI pyta serwer "co potrafisz?" i dostaje listę narzędzi z opisami i schematami parametrów; nie musisz nic hardkodować
• Wywołanie - jeden format żądania i odpowiedzi (JSON-RPC 2.0) niezależnie od tego, czy narzędziem jest baza danych, API czy system plików
• Kontekst - poza narzędziami serwer może udostępniać zasoby (pliki, rekordy) i szablony promptów, które aplikacja AI pobiera w ujednolicony sposób

Analogia, która przylgnęła do protokołu: MCP jest jak USB-C dla AI. Producent laptopa nie buduje osobnego portu dla każdego urządzenia - jeden standard obsługuje wszystkie. Tak samo aplikacja AI z klientem MCP obsłuży każdy serwer MCP, niezależnie kto go napisał.

Jak działa MCP - host, klient, serwer

Architektura MCP ma trzy role:

Serwer MCP udostępnia trzy typy obiektów (tzw. prymitywy):

• Tools - funkcje, które model może wywołać: "wyszukaj klienta w CRM", "wyślij wiadomość", "uruchom zapytanie SQL"; to odpowiednik function callingu
• Resources - dane tylko do odczytu, które host może wciągnąć do kontekstu: plik, rekord bazy, dokument; jak GET w REST
• Prompts - gotowe szablony promptów z parametrami, które serwer poleca dla swoich narzędzi; rzadziej używane, ale przydatne przy złożonych systemach

Komunikacja odbywa się przez JSON-RPC 2.0 na jednym z dwóch transportów:

Praktyczna zasada: buduj i testuj na stdio, przechodź na Streamable HTTP dopiero gdy z serwera ma korzystać więcej niż jedna osoba lub maszyna. Uwaga: starszy transport SSE został wycofany ze specyfikacji w marcu 2025 na rzecz Streamable HTTP - jeśli widzisz tutorial z SSE, jest nieaktualny.

Tak wygląda podłączenie serwerów MCP do Claude Desktop - jeden plik konfiguracyjny:

{  "mcpServers": {    "filesystem": {      "command": "npx",      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/firma/dokumenty"]    },    "postgres": {      "command": "npx",      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://readonly_user:haslo@localhost/crm"]    }  }}

Po restarcie aplikacji Claude widzi narzędzia obu serwerów i sam decyduje, kiedy ich użyć. Zwróć uwagę na "readonly_user" - to nie przypadek, wrócimy do tego przy bezpieczeństwie.

MCP vs function calling vs OpenAPI - co wybrać?

To najczęstsze pytanie i źródło największych nieporozumień. Te trzy podejścia rozwiązują ten sam problem - model wybiera akcję, runtime ją wykonuje - ale na różnych poziomach:

Decyzja w trzech pytaniach:

1. 1.Budujesz jedną aplikację z maksymalnie kilkoma-kilkunastoma funkcjami? Function calling - najprościej, najszybciej, bez dodatkowej infrastruktury (pisałem o tym w artykule o tool callingu w produkcji)
2. 2.Masz dojrzałe REST API z OpenAPI spec i chcesz je wystawić agentom? OpenAPI tools - nie buduj serwera MCP tylko po to, żeby opakować istniejące API, jeśli korzysta z niego jedna aplikacja
3. 3.Więcej niż jedna aplikacja AI ma używać tych samych narzędzi - albo chcesz korzystać z gotowego ekosystemu serwerów? MCP - koszt postawienia serwera zwraca się przy drugim kliencie

Ważny niuans: te podejścia się nie wykluczają. Host MCP pod spodem i tak używa function callingu danego modelu - MCP standaryzuje warstwę wyżej: skąd narzędzia pochodzą i jak są odkrywane.

Jak zbudować własny serwer MCP w Pythonie

Najszybsza droga to FastMCP - wysokopoziomowe SDK, w którym narzędzie to funkcja z dekoratorem. Przykład: serwer dający agentowi dostęp do firmowej bazy zamówień:

from fastmcp import FastMCPimport osimport psycopg2mcp = FastMCP("orders-server")def get_db():    return psycopg2.connect(        host="localhost", dbname="shop",        user="readonly_agent", password=os.environ["DB_PASS"]    )@mcp.tool()def find_order(order_id: str) -> dict:    """Zwraca status, kwote i date zamowienia po jego numerze."""    with get_db() as conn, conn.cursor() as cur:        cur.execute(            "SELECT status, total, created_at FROM orders WHERE id = %s",            (order_id,)        )        row = cur.fetchone()    if row is None:        return {"error": "Nie znaleziono zamowienia " + order_id}    return {"status": row[0], "total": float(row[1]), "created_at": str(row[2])}@mcp.tool()def orders_summary(days: int = 7) -> dict:    """Podsumowanie zamowien z ostatnich N dni: liczba i laczna kwota."""    if days < 1 or days > 90:        return {"error": "days musi byc w zakresie 1-90"}    with get_db() as conn, conn.cursor() as cur:        cur.execute(            "SELECT count(*), coalesce(sum(total),0) FROM orders "            "WHERE created_at > now() - make_interval(days := %s)",            (days,)        )        count, total = cur.fetchone()    return {"orders": count, "revenue": float(total), "period_days": days}if __name__ == "__main__":    mcp.run()

Trzy rzeczy, które robią tu różnicę w praktyce:

• Docstringi są częścią produktu - to z nich model dowiaduje się, kiedy użyć narzędzia; pisz je jak instrukcję dla nowego pracownika, nie jak komentarz dla programisty
• Walidacja zakresów w kodzie - model potrafi przekazać days=10000; serwer musi to odrzucić, a nie wykonać
• Konto readonly_agent - uprawnienia ogranicza baza danych, nie prompt; nawet udany prompt injection nie zrobi UPDATE przez konto, które ma tylko SELECT

Testowanie przed podłączeniem do agenta: "npx @modelcontextprotocol/inspector python orders_mcp_server.py" otwiera webowy interfejs MCP Inspector, w którym ręcznie wywołasz każde narzędzie i zobaczysz surowe odpowiedzi. To odpowiednik Postmana dla MCP - używaj go zawsze przed integracją.

Serwer MCP w TypeScript

Dla zespołów JS/TS oficjalne SDK wygląda tak - serwer ze statusem magazynu:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";import { z } from "zod";const server = new McpServer({ name: "inventory", version: "1.0.0" });server.tool(  "check_stock",  "Sprawdza stan magazynowy produktu po SKU. Zwraca ilosc i lokalizacje.",  { sku: z.string().regex(/^[A-Z0-9-]{4,20}$/) },  async ({ sku }) => {    const res = await fetch("https://api.firma.pl/v1/stock/" + sku, {      headers: { Authorization: "Bearer " + process.env.WMS_TOKEN }    });    if (!res.ok) {      return { content: [{ type: "text", text: "Brak produktu: " + sku }] };    }    const data = await res.json();    return { content: [{ type: "text", text: JSON.stringify(data) }] };  });const transport = new StdioServerTransport();await server.connect(transport);

Różnice względem Pythona: walidację parametrów robi Zod (schemat regex na SKU odrzuca śmieciowe wejścia zanim dotkną API), a logi muszą iść na console.error - stdout jest zajęty przez protokół i każdy console.log zepsuje komunikację. Wybór języka: Python/FastMCP dla szybkiej iteracji i integracji z ML, TypeScript dla serwisów utrzymywanych długoterminowo, gdzie typy procentują.

Gotowe serwery MCP do narzędzi firmowych

Zanim napiszesz własny serwer, sprawdź rejestr - większość popularnych systemów już go ma:

• Dane i bazy: PostgreSQL, MongoDB, SQLite, Redis - zapytania z kontrolą dostępu na poziomie roli bazodanowej
• Komunikacja: Slack (czytanie kanałów, wysyłka wiadomości), Gmail, Microsoft Teams
• Dokumenty: Google Drive, Notion, Confluence, system plików z ograniczeniem do wskazanych katalogów
• Developerskie: GitHub (issues, PR, code review), GitLab, Sentry, Docker
• Biznesowe: Stripe (płatności i faktury), HubSpot, Salesforce, Linear, Jira
• Web: Brave Search, Puppeteer/Playwright (automatyzacja przeglądarki), Firecrawl (scraping)

Reguła decyzyjna: gotowy serwer bierz, gdy pokrywa Twój przypadek użycia w całości i pochodzi z zaufanego źródła (oficjalny vendor lub repozytorium modelcontextprotocol). Własny pisz, gdy potrzebujesz logiki biznesowej (np. "znajdź klientów z ryzykiem churn"), agregacji kilku systemów w jedno narzędzie albo twardych ograniczeń uprawnień, których gotowy serwer nie wymusza.

Bezpieczeństwo MCP - nowa powierzchnia ataku

MCP dodaje do aplikacji AI nową klasę ryzyk, której nie było przy zwykłym function callingu - bo narzędzia pochodzą teraz z zewnętrznych źródeł. To bezpośrednie rozwinięcie tematów z artykułu o prompt injection (#39):

• Tool poisoning - atakujący umieszcza złośliwe instrukcje w opisie narzędzia; model je czyta i wykonuje, a użytkownik nigdy ich nie widzi, bo UI pokazuje tylko nazwę narzędzia
• Rug pull - serwer, który przeszedł audyt, po cichu zmienia definicje narzędzi w kolejnej wersji; zaufanie z dnia instalacji nie obowiązuje wiecznie
• Confused deputy - serwer MCP działa z uprawnieniami szerszymi niż użytkownik, który go wywołuje; jeden błąd w konfiguracji OAuth i agent robi rzeczy, których użytkownikowi robić nie wolno
• Wyciek credentials - pliki konfiguracyjne MCP zawierają klucze API i hasła; tool poisoning może kazać agentowi je odczytać i wysłać na zewnątrz (CVE-2025-6514 pokazało przechwytywanie tokenów OAuth przez złośliwy endpoint autoryzacji)

Zasady obrony przy wdrożeniu:

1. 1.Allowlista zamiast blocklisty - host domyślnie odrzuca wywołania narzędzi; zatwierdzasz pojedynczo te, których agent faktycznie potrzebuje
2. 2.Pinning wersji serwerów - po audycie zamroź wersję (dokładny hash paczki, nie "latest"); aktualizacja = ponowny przegląd definicji narzędzi
3. 3.Least privilege na poziomie systemu źródłowego - konto bazodanowe read-only, scoped API keys, OAuth z minimalnym zakresem; uprawnienia wymusza system, nie prompt
4. 4.Tylko zaufane źródła serwerów - oficjalne repozytoria vendorów; serwer MCP z przypadkowego GitHuba to ten sam poziom ryzyka co instalacja nieznanego pakietu npm z uprawnieniami do Twojego CRM
5. 5.HTTPS wszędzie - znacząca część audytowanych serwerów MCP używa plaintext HTTP, wystawiając tokeny na przechwycenie; w produkcji żadnego wyjątku od TLS
6. 6.Human-in-the-loop dla akcji nieodwracalnych - wysyłka, płatność, kasowanie wymagają potwierdzenia człowieka, dokładnie jak w warstwach obrony z artykułu #39

Wdrożenie MCP w firmie - od czego zacząć

1. 1.Zinwentaryzuj aplikacje AI i narzędzia: ile masz hostów (Claude, Cursor, własni agenci) i ile systemów do podłączenia - jeśli wynik to 1×N, zostań przy function callingu
2. 2.Zacznij od gotowych serwerów w trybie read-only: filesystem na wskazanym katalogu i Postgres na koncie readonly - zero kodu, natychmiastowa wartość
3. 3.Testuj każdy serwer w MCP Inspector przed podłączeniem do hosta
4. 4.Pierwszy własny serwer napisz dla jednego procesu biznesowego z 2-4 narzędziami - nie buduj od razu "serwera do wszystkiego"
5. 5.Docstringi i opisy narzędzi traktuj jak prompty: testuj, czy model wybiera właściwe narzędzie, i iteruj nad opisami
6. 6.Waliduj parametry w kodzie serwera (zakresy, regex, typy) - model przekaże kiedyś wartość absurdalną
7. 7.Wszystkie credentials w zmiennych środowiskowych lub vault - nigdy w konfigu commitowanym do repo
8. 8.Ustaw allowlistę narzędzi na hoście i pinning wersji serwerów
9. 9.Loguj każde wywołanie narzędzia (kto, co, z jakimi parametrami, wynik) - audyt i debugging w jednym
10. 10.Przejdź na Streamable HTTP z OAuth dopiero, gdy serwer ma być współdzielony - lokalne stdio jest bezpieczniejsze domyślnie

Najważniejsze wnioski

MCP rozwiązuje realny problem - eksplozję integracji N×M - i ma za sobą rzadki konsensus całej branży: Anthropic, OpenAI, Google i Microsoft. Wybieraj go, gdy więcej niż jedna aplikacja AI korzysta z tych samych narzędzi; przy pojedynczej aplikacji zostań przy function callingu. Start jest tani: gotowe serwery podłączysz w godzinę, własny napiszesz w FastMCP w 1-3 dni. Bezpieczeństwo traktuj poważnie od pierwszego dnia: allowlista narzędzi, pinning wersji, least privilege na kontach systemów źródłowych i tylko zaufane źródła serwerów - bo serwer MCP to nowy wektor ataku o uprawnieniach Twoich systemów.

---

Pomagam firmom projektować i wdrażać architekturę narzędzi dla agentów AI - od decyzji function calling vs MCP, przez budowę własnych serwerów MCP z właściwymi uprawnieniami, po bezpieczne wdrożenie produkcyjne z monitoringiem. Napisz do mnie - zaczynam od bezpłatnej 30-minutowej analizy Twojego przypadku.

Powiązane artykuły

• Tool calling w produkcji
• Agenci AI - jak działają
• LangGraph - workflow agenta AI