MCP — co to jest i dlaczego warto je znać?

Problem, który MCP rozwiązuje#

Każdy, kto łączył model językowy z systemami firmy, zna ten schemat: dla każdej integracji piszesz definicje narzędzi, warstwę wywołań, obsługę błędów i autoryzację. Potem chcesz użyć tych samych integracji w innym miejscu — w innym asystencie, innym produkcie — i piszesz to samo jeszcze raz.

MCP (Model Context Protocol) to otwarty standard, który tę pracę normalizuje. Integrację piszesz raz — jako serwer MCP — a korzysta z niej każdy klient MCP: aplikacja czatowa, IDE, własny agent, narzędzie wewnętrzne.

Co wystawia serwer MCP?#

Serwer deklaruje trzy rodzaje możliwości, a klient (i model) odkrywają je w trakcie połączenia:

• Tools — akcje, które model może wywołać: „utwórz zadanie”, „wyszukaj klienta”, „wyślij ofertę”.
• Resources — dane do czytania: dokumenty, rekordy, pliki konfiguracyjne.
• Prompts — gotowe szablony interakcji, które użytkownik może uruchomić.

Kluczowe słowo to odkrywają: model nie musi być wcześniej uczony Twojego API. Dostaje listę narzędzi z opisami i schematami wejścia — i na tej podstawie decyduje, czego użyć.

Jak wygląda definicja narzędzia?#

Minimalny serwer MCP w TypeScript (SDK oficjalne) sprowadza się do zadeklarowania narzędzia i jego logiki:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "firmowy-crm", version: "1.0.0" });

server.tool(
  "znajdz_klienta",
  "Wyszukuje klienta w CRM po nazwie lub NIP",
  { zapytanie: z.string().describe("nazwa firmy albo NIP") },
  async ({ zapytanie }) => {
    const wynik = await crm.szukaj(zapytanie);
    return {
      content: [{ type: "text", text: JSON.stringify(wynik) }],
    };
  },
);

Z perspektywy modelu to narzędzie wygląda identycznie jak każde inne — niezależnie od tego, czy pod spodem jest Twój CRM, PostgreSQL czy zewnętrzne API.

Co z bezpieczeństwem?#

MCP przenosi kontrolę tam, gdzie powinna być: na serwer. To serwer decyduje, jakie narzędzia wystawia, z jakimi uprawnieniami działa i co loguje. Dobre praktyki, które stosujemy we wdrożeniach:

1. serwer dostaje konto serwisowe o minimalnych uprawnieniach — nigdy dostęp administratora,
2. operacje zapisu wymagają osobnych narzędzi (łatwiej je wyłączyć albo obłożyć potwierdzeniem),
3. każde wywołanie trafia do logu z pełnym wejściem i wyjściem — bez tego nie ma mowy o audycie,
4. narzędzia „niebezpieczne” (kasowanie, wysyłka na zewnątrz) przechodzą przez człowieka w pętli.

Czego MCP nie załatwia#

Standard opisuje, jak narzędzia są ogłaszane i wywoływane. Nie mówi nic o tym, co się dzieje wokół — a to jest większość pracy przy wdrożeniu:

• uprawnienia — kto może wywołać które narzędzie i z jakim zakresem danych. Serwer musi to rozstrzygnąć sam, na podstawie tożsamości wywołującego;
• limity — liczba wywołań, koszt, tempo. Bez nich pierwsza pętla agenta na nietypowej sprawie odbije się na rachunku;
• audyt — kto, co, kiedy i z jakim skutkiem. To wymóg, który pojawia się natychmiast, gdy narzędzia zaczynają zapisywać, a nie tylko czytać;
• jakość danych — narzędzie zwracające niekompletny rekord będzie źródłem błędnych decyzji niezależnie od protokołu.

Innymi słowy: MCP zdejmuje pracę integracyjną, nie projektową. To i tak dużo — ale warto wiedzieć, czego się po nim nie spodziewać.

Jak wygląda rozsądny pierwszy serwer#

Nie „wystawmy CRM przez MCP”, tylko trzy–pięć narzędzi obsługujących jeden konkretny scenariusz. Najlepiej wyłącznie odczyt: wyszukanie klienta, pobranie historii, sprawdzenie statusu.

Powód jest praktyczny. Odczyt pozwala przejść całą drogę — opisy narzędzi, uwierzytelnienie, limity, logowanie, testy z realnymi pytaniami — przy ryzyku ograniczonym do wycieku danych do złego odbiorcy, które i tak trzeba rozwiązać. Zapis dokłada do tego skutki nieodwracalne i lepiej dokładać go wtedy, gdy reszta jest już sprawdzona.

Dopiero drugi serwer warto budować z myślą o wielu klientach naraz — pierwszy ma nauczyć zespół, gdzie ten protokół pomaga, a gdzie tylko dokłada warstwę.

Kiedy warto postawić własny serwer MCP?#

• Gdy te same dane firmowe mają zasilać więcej niż jedno miejsce z AI — czat zespołu, agenta obsługi, narzędzia wewnętrzne.
• Gdy chcesz odseparować logikę integracji od logiki agenta — serwer MCP rozwija się niezależnie i testuje jak zwykły backend.
• Gdy planujesz agentów AI na poważnie — MCP porządkuje ich świat narzędzi od pierwszego dnia.

Jeśli natomiast masz jeden workflow i jedną integrację, zwykłe function calling w zupełności wystarczy — protokół dodaje wartość wraz ze skalą, nie zamiast niej.