Integracje AI i MCP dla produktów i zespołów

Dla kogo jest ta usługa

Dla zespołów, które mają własne API i konkretny przypadek: asystent albo agent AI ma wykonać w Twoim systemie coś, czego gotowe łączniki nie potrafią. Najczęściej są to:

• właściciel produktu SaaS, który chce, żeby klienci obsługiwali produkt z poziomu Copilota, Claude'a albo ChatGPT — bez oddawania modelowi całego API;
• wewnętrzny zespół platformowy, który ma udostępnić dane i funkcje firmy agentom w bezpieczny, powtarzalny sposób;
• partner wdrożeniowy, któremu w projekcie brakuje jednego kontrolowanego połączenia między modelem a systemem klienta.

Warunek jest jeden, ale twardy: po Twojej stronie musi być ktoś, kto jest właścicielem tego API i może podjąć decyzję o wdrożeniu. Bez tego budowalibyśmy łącznik do systemu, którego nikt nie odbierze.

Czym jest MCP — i dlaczego nie o protokół tu chodzi

MCP (Model Context Protocol) to otwarty standard, w którym serwer wystawia funkcje systemu jako nazwane narzędzia z opisanym schematem — „znajdź kontrahenta”, „utwórz zamówienie do zatwierdzenia” — a klient (Claude, ChatGPT, Copilot Studio, Twój własny agent) wywołuje je zamiast osobnej integracji dla każdego programu. Cztery wzorce łączenia modelu z systemami firmy, w tym ten, porównaliśmy w tekście o integracji AI z ERP i CRM.

Sam protokół nie jest trudny — bibliotek jest pod dostatkiem, a publicznych serwerów tysiące. Trudne jest to, co serwer ma udostępniać, komu, z jakimi uprawnieniami i co się dzieje, gdy wywołanie się nie uda. Kiedy gotowy łącznik nie wykonuje Twojego przypadku, brakuje zwykle nie protokołu, tylko tej warstwy: semantyki biznesowej narzędzi, kontroli dostępu i testów. To ją budujemy.

Przygotowujemy też otwarty przykład referencyjny takiego serwera dla jednego z polskich systemów — po to, żeby sposób pracy dało się obejrzeć w kodzie, zanim cokolwiek zlecisz.

Najmniejszy zakres, od którego zaczynamy

Pierwszy projekt jest celowo mały, bo dopiero działające, przetestowane połączenie mówi, czy warto je rozszerzać:

• jedno istniejące API — nie budujemy nowego i nie przebudowujemy tego, które jest;
• jedna aplikacja kliencka — ta, której faktycznie będziesz używać, nie „dowolny klient MCP”;
• kilka nazwanych operacji, wybranych pod jeden przypadek użycia — nie całe API;
• najpierw odczyt albo operacje za zgodą człowieka; zapis bez zatwierdzenia dopiero po odbiorze;
• środowisko i konto testowe — nie publiczna usługa dla wielu najemców.

Rozszerzenie o kolejne operacje, drugiego klienta albo produkcyjny zapis jest osobnym, osobno wycenionym etapem — nie domyślną częścią pierwszego.

Co dostajesz

• Schematy narzędzi z semantyką biznesową — nazwy, argumenty i opisy, które model rozumie tak samo jak Twój zespół.
• Stabilne, przewidywalne błędy oraz stronicowanie i limity wyników.
• Uwierzytelnianie zintegrowane z Twoim systemem, z walidacją odbiorcy tokenu — serwer nie przekazuje dalej tokenów klienta.
• Uprawnienia per użytkownik i per najemca, egzekwowane przy każdym wywołaniu.
• Rozdzielone operacje odczytu i zapisu oraz bezpieczne ponawianie — powtórzone wywołanie nie tworzy duplikatu.
• Dziennik wywołań z redakcją danych wrażliwych.
• Testy odbiorowe uruchamiane przeciwko wybranemu klientowi.
• Paczka wdrożeniowa, opis wdrożenia i runbook dla osoby, która będzie to utrzymywać.

Wszystko trafia do Twojego repozytorium. Po przekazaniu nie jesteś od nas zależny — to jeden z warunków metodyki wdrożenia.

Bezpieczeństwo: minimum, od którego nie odstępujemy

• Brak przekazywania tokenów — serwer występuje wobec Twojego API własną, walidowaną tożsamością, a nie tokenem przekazanym od klienta.
• Uprawnienia systemu docelowego egzekwowane przy każdym wywołaniu, nie raz przy logowaniu.
• Najmniejsze wystarczające uprawnienia — narzędzie do odczytu nie ma prawa zapisu.
• Sekrety poza promptami i poza dziennikami.
• Żadnych dowolnych operacji sieciowych ani plikowych — tylko te, które narzędzie deklaruje.
• Limity liczby wywołań, kosztu i czasu.
• Treść pobrana z systemu nigdy nie staje się instrukcją dla modelu — polecenie wstrzyknięte w opis produktu, e-mail czy dokument jest traktowane jako dane.

Specyfikacja MCP każe traktować opisy narzędzi i zwracaną treść jako niezaufane; my traktujemy tak również to, co użytkownik może wpisać. Gdzie trafiają dane i kto jest wtedy ich administratorem, opisaliśmy na stronie o bezpieczeństwie i RODO.

Odbiór: co sprawdzamy, zanim powiemy, że działa

Odbiór to lista przypadków, które integracja musi obsłużyć poprawnie — uzgodniona przed budową i uruchamiana jako testy:

• operacje dozwolone wykonują się, a niedozwolone są odrzucane z czytelnym błędem;
• użytkownik jednego najemcy nie widzi danych innego;
• wygasłe lub odwołane poświadczenia zatrzymują wywołanie;
• powtórzone wywołanie zapisu nie tworzy duplikatu;
• częściowa awaria systemu docelowego kończy się kontrolowanym błędem, nie zawieszeniem klienta;
• nieprawidłowe argumenty są odrzucane, zanim dotrą do Twojego API;
• złośliwa treść zwrócona przez narzędzie nie zmienia zachowania modelu;
• limity kosztu i czasu przerywają wywołanie, gdy zostaną przekroczone.

Lista jest częścią umowy. Jeżeli w trakcie pracy okaże się, że jakiegoś przypadku nie da się obsłużyć, mówimy o tym przed odbiorem, nie po.

Czego nie robimy w tym zakresie

• Nie udostępniamy „całego API” — narzędzia są wybierane pod przypadek użycia.
• Nie budujemy nowej platformy tożsamości — korzystamy z uwierzytelniania, które Twój system już ma.
• Nie uruchamiamy publicznej usługi dla wielu najemców jako pierwszego kroku.
• Nie włączamy zapisu do produkcji bez zatwierdzenia i bez odbioru.
• Nie przejmujemy utrzymania na czas nieokreślony — opieka po wdrożeniu jest osobną, ograniczoną usługą.

Odradzamy projekt, gdy nie ma konkretnego klienta — aplikacji ani zespołu — który będzie z integracji korzystał; gdy nikt po Twojej stronie nie jest właścicielem API; gdy nie ma budżetu na utrzymanie; albo gdy gotowy łącznik po prostu wystarcza. Komplet warunków, przy których mówimy „nie”, zebraliśmy na stronie czego nie robimy.

Kiedy wystarczy zwykłe API

Nie każde połączenie z modelem potrzebuje serwera MCP. Zwykłe API — albo gotowy łącznik — wystarczy, gdy:

• konsumentem jest Twój własny kod, nie model — deterministyczna integracja jest tańsza i łatwiejsza do przetestowania;
• kolejność kroków jest znana z góry — wtedy to zadanie dla automatyzacji AI, nie dla narzędzi wywoływanych przez model;
• Twój system albo wybrany klient ma już oficjalny łącznik, który wykonuje potrzebne operacje — coraz więcej systemów go ma;
• jest tylko jeden klient i jedna operacja — serwer MCP zwraca się dopiero wtedy, gdy jeden łącznik ma służyć wielu klientom lub wielu zadaniom.

Serwer MCP ma sens, gdy po drugiej stronie stoi model albo agent, który sam wybiera narzędzia — czyli wtedy, gdy uprawnienia i testy stają się ważniejsze niż sam transport. O tym, kiedy agent w ogóle ma sens, piszemy przy wdrożeniu agentów AI; sama integracja bywa też jednym z etapów szerszego wdrożenia AI w firmie.

Zakres i cena

Najczęstsze pytania

Czym jest MCP i czy to jedyna droga do integracji AI z naszym systemem?

MCP (Model Context Protocol) to otwarty standard, w którym serwer wystawia funkcje systemu jako nazwane narzędzia z opisanym schematem, a klient — Claude, ChatGPT, Copilot Studio albo własny agent — wywołuje je zamiast osobnej integracji dla każdego programu. Nie jest to jedyna droga: bezpośrednie wywołanie API, warstwa pośrednia w rodzaju n8n albo, w ostateczności, RPA rozwiązują inne przypadki. Serwer MCP ma sens wtedy, gdy po stronie klienta stoi model lub agent, który sam wybiera narzędzia, i gdy jeden łącznik ma służyć wielu klientom albo wielu zadaniom.

Mamy dobrze udokumentowane API. Po co nam jeszcze serwer MCP?

Jeżeli z API korzysta Twój własny kod, nie potrzebujesz serwera MCP — deterministyczna integracja jest tańsza i łatwiejsza do przetestowania. Serwer jest potrzebny wtedy, gdy z API ma korzystać model: model nie czyta dokumentacji tak jak programista, tylko wybiera narzędzia po ich nazwach, opisach i schematach, więc każdą operację trzeba opisać semantyką biznesową, ograniczyć uprawnieniami egzekwowanymi przy każdym wywołaniu i sprawdzić testami, których zwykłe API nie ma — na przykład tym, co się stanie, gdy zwrócona treść zawiera wstrzyknięte polecenie.

Czy model będzie miał dostęp do naszych danych?

Tylko do tego, co zwracają narzędzia, które świadomie udostępnisz — a te projektuje się wąsko: narzędzie do odczytu nie ma prawa zapisu, użytkownik jednego najemcy nie widzi danych innego, a uprawnienia systemu docelowego są egzekwowane przy każdym wywołaniu, nie raz przy logowaniu. Fragmenty danych trafiają do dostawcy modelu, którego wybierzesz, na jego warunkach — gdzie trafiają i kto jest wtedy administratorem, opisaliśmy na stronie o bezpieczeństwie i RODO. Sekrety nie pojawiają się ani w promptach, ani w dziennikach.

Z którymi klientami AI to działa?

Z każdym, który obsługuje MCP — dziś są to między innymi Claude, ChatGPT, Microsoft Copilot Studio, Claude Code i wiele platform agentowych — oraz z Twoim własnym agentem. Pierwszy etap budujemy i testujemy przeciwko jednemu klientowi: temu, którego naprawdę będziesz używać. Drugi klient bywa prostym rozszerzeniem, ale nie zakładamy tego z góry, bo klienci różnią się tym, czy pytają użytkownika o zgodę na każde wywołanie narzędzia.

Ile to kosztuje i ile trwa?

Zakres i cenę ustalamy po obejrzeniu dokumentacji Twojego API i jednego opisanego przypadku użycia — z nazwą klienta, listą operacji i osobą, która po Twojej stronie odbierze wynik. Wycena jest za etap w stałym zakresie i stałej cenie: pierwszy obejmuje jeden interfejs, jednego klienta i uzgodnioną listę testów odbiorowych, i zwykle liczy się w tygodniach, nie w miesiącach. Licencje i zużycie API zewnętrznych dostawców, w tym modeli, są poza wyceną.