Blog - Jak działają MCP

Chat z AI sam z siebie nie wie, co masz w trackerze zadań, w repo ani w firmowej bazie. Widzi tylko to, co mu wkleisz — albo to, do czego mu dasz dostęp.

MCP (Model Context Protocol) to wspólny sposób, żeby asystent mógł bezpiecznie sięgać po zewnętrzne rzeczy: zgłoszenie, plik, API. Zamiast pisać osobną wtyczkę pod każdy chat, wystawiasz jedno „gniazdko”, a różne aplikacje (IDE, desktopowy asystent, własny agent) podpinają się tym samym językiem.

Po co to komu

Bez MCP każdy produkt AI buduje własne integracje od zera. Jedno narzędzie tu, drugie tam, baza jeszcze inaczej — i nikt nie używa tego samego dwa razy.

Z MCP raz robisz serwer, który umie np. tworzyć zgłoszenia. Potem ten sam serwer działa w IDE i w firmowym chacie. Mniej klejenia, mniej „u nas to inaczej”.

Kto z kim gada

W skrócie:

• Aplikacja (IDE, chat) — tam siedzisz i piszesz do modelu.
• Klient — tłumacz po stronie aplikacji; zna MCP.
• Serwer — mały program, który naprawdę gada z zewnętrznym systemem, dyskiem albo bazą.

Model nie łączy się „magicznie” z niczym. Prosi aplikację: „zrób to”, a aplikacja idzie do serwera MCP.

Co serwer może oferować

Trzy rzeczy, które najczęściej spotkasz:

1. Narzędzia (tools) — „zrób coś”: utwórz zgłoszenie, wyślij maila, odpal zapytanie. Model wybiera narzędzie i argumenty; resztę ogarnia aplikacja.
2. Zasoby (resources) — „pokaż mi coś”: treść pliku, opis zadania, schemat tabeli. Raczej czytanie niż działanie.
3. Prompty — gotowe scenariusze po stronie serwera, np. „zrób przegląd tej zmiany”.

Nie musisz znać wszystkich szczegółów protokołu, żeby to używać. Wystarczy wiedzieć: akcja, dane, gotowy przepis.

Jak to wygląda w praktyce

Piszesz: „załóż zgłoszenie, że pada logowanie”.

Model proponuje wywołanie. Aplikacja pyta serwer. Serwer robi robotę. Wynik wraca do rozmowy — i dopiero wtedy AI Ci odpowiada.

Lokalnie czy w sieci

Serwer MCP często odpala się lokalnie obok IDE (szybko, blisko Twoich plików). Czasem stoi na serwerze i łączy się przez HTTP — wtedy z tego samego korzysta cały zespół.

Pod spodem to zwykła rozmowa request/response. Nie musisz tego debugować na co dzień; ważne, że jest wspólny język.

Co z tego dla nas

Budujesz jeden serwer MCP pod firmę — CRM, repo, checklisty wdrożeniowe — i podpinasz go tam, gdzie pracujecie z AI. Nie piszesz trzeciej wtyczki „tylko pod ten jeden chat”.

MCP nie zastępuje modelu. To raczej wspólna wtyczka zasilająca: jak model ma dostać narzędzia i kontekst, żeby przestać zgadywać, a zacząć działać na prawdziwych danych.