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.

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.