Czy program firmy musi mieć API, żeby AI z nim pracowało? Co różni API od serwera MCP

API to interfejs, przez który jeden program komunikuje się z drugim: drzwi otwarte na zewnątrz, przez które inne oprogramowanie może pobierać dane albo wysyłać zlecenia. Serwer MCP (Model Context Protocol) to osobna warstwa, która z tych drzwi robi konkretne narzędzia opisane językiem naturalnym, zrozumiałe dla asystenta AI: z opisem co robi każde narzędzie, z uprawnieniami co wolno mu zmienić, z logiem każdego wywołania. Program bez API też da się podłączyć do AI, choćby przez bazę danych albo eksport pliku. Ale żeby asystent mógł z niego samodzielnie korzystać, odpowiadając na pytania pracownika, potrzebny jest serwer MCP po środku.

API a serwer MCP: jaka jest między nimi różnica?

Firma obsługuje kilkuset kontrahentów w Comarch ERP Optima. Główna księgowa pyta: "Czy dałoby się zrobić tak, żeby asystent odpowiadał mi na pytania w stylu: które faktury mają termin przekroczony o ponad 30 dni?" Informatyk sprawdza: Optima w tej wersji ma REST API. Dobra wiadomość. Ale to nie koniec.

To, że program udostępnia API, znaczy tyle, że inny program może się z nim połączyć i zapytać o dane, pod warunkiem że zna dokładny adres endpointu, wie jakie parametry wysłać i rozumie format odpowiedzi. Asystent AI nie "wie" z góry, że istnieje endpoint /api/rozrachunki?status=przeterminowane&min_dni=30. Trzeba mu powiedzieć, że takie narzędzie istnieje: jak się nazywa, co robi, jakie parametry przyjmuje i co zwraca. Właśnie to robi serwer MCP: tłumaczy techniczne API na narzędzia opisane po ludzku, z których asystent może korzystać samodzielnie.

API programu to zestaw adresów, metod HTTP i formatów danych. Mówi: "wyślij zapytanie GET pod ten adres z tym nagłówkiem autoryzacyjnym, a dostaniesz listę faktur w formacie JSON". Taki język rozumieją programy i programiści.

Serwer MCP to oddzielny komponent, który owija to API i prezentuje je asystentowi AI jako zestaw opisanych narzędzi. Narzędzie w MCP wygląda mniej więcej tak: nazwa pobierz_przeterminowane_faktury, opis "Pobiera listę faktur VAT sprzedażowych z przekroczonym terminem płatności. Parametry: kontrahent (opcjonalny, identyfikator lub NIP), min_dni (wymagany, minimalna liczba dni po terminie)". Asystent rozumie taki opis i sam decyduje, kiedy i z jakimi parametrami użyć tego narzędzia, odpowiadając na pytanie zadane mu po polsku.

MCP to skrót od Model Context Protocol: otwarty standard rozwijany pod opieką Linux Foundation. Opisuje, jak asystent AI komunikuje się z serwerem narzędzi: jak pyta o listę dostępnych narzędzi, jak je wywołuje, jak odbiera wynik. Ten sam serwer MCP zbudowany dla Optimy może działać z różnymi asystentami AI obsługującymi ten protokół.

Jedna rzecz jest tutaj istotna. Kupując dostęp do Comarch ERP Optima, nie dostajecie gotowego serwera MCP do Optimy. Dostajecie API, z którego można taki serwer zbudować. To jest właśnie część pracy przy wdrożeniu.

Które polskie programy mają API, a w których sytuacja jest bardziej skomplikowana?

Comarch ERP Optima: nowsze wersje mają REST API obejmujące moduły finansowo-księgowe, handel i kadry. Zakres dostępnych endpointów zmienia się między wersjami. Starsze instalacje, nieaktualizowane od kilku lat, mogą mieć API w bardzo ograniczonym zakresie albo nie mieć go wcale. Opcja chmurowa (Comarch Online) ma własny dostęp API, różniący się zakresem od instalacji serwerowej.

enova365: jedno z bardziej otwartych środowisk ERP w Polsce pod kątem integracji. Ma udokumentowane REST API obejmujące finanse, kadry, CRM i moduły dodatkowe. Producent (Soneta) aktywnie je rozwija.

Symfonia: szeroka rodzina produktów. Symfonia ERP ma interfejsy integracyjne, nowsze wersje kładą większy nacisk na otwartość. Starsze moduły, szczególnie Symfonia Handel w wersjach sprzed kilku lat, pracują bardziej zamknięcie. Tu naprawdę zależy od konkretnego produktu i konkretnej wersji.

Subiekt GT i Subiekt nexo (InsERT): Subiekt GT od dawna ma sIKS, System Integracyjny, który działa inaczej niż REST API: oparty jest na interfejsie COM i bezpośrednim dostępie do bazy. Subiekt nexo ma REST API w nowszych wersjach, ale zakres jest skromniejszy niż w dużych ERP-ach.

Praktyczna wskazówka przed rozmową z wdrożeniowcem: nie zakładajcie, że "Optima ma API", więc Wasza Optima ma API. Sprawdźcie, jaką wersję macie zainstalowaną. To wychodzi w pierwszej technicznej rozmowie i lepiej wiedzieć wcześniej, żeby nie tracić czasu.

Jak podłączyć AI do programu, który nie ma API?

Brak REST API nie przekreśla możliwości pracy AI z danymi z programu. Są trzy podejścia, zwykle stosowane razem albo jedno po drugim.

Bezpośredni dostęp do bazy danych. Większość polskich programów biznesowych działa na Microsoft SQL Server albo innej bazie relacyjnej. Serwer MCP może łączyć się z bazą bezpośrednio i odpowiadać na pytania. To wymaga dostępu do bazy i wiedzy o strukturze tabel: zazwyczaj nie jest to publicznie udokumentowane, ale da się to ustalić w kilka godzin z dokumentacją albo z pomocą producenta. Ważne zastrzeżenie: zapis przez bazę, z pominięciem logiki programu, jest ryzykowny i robimy to tylko w wybranych tabelach i po bardzo dokładnym sprawdzeniu. Zaczynamy od odczytu.

Cykliczny eksport do pliku. Optima, Symfonia, Subiekt: każdy z nich potrafi eksportować dane do CSV albo XML. Można ustawić automatyczny eksport co kilka godzin do określonego folderu, a serwer MCP czyta ten folder. Dane mają kilkugodzinne opóźnienie, ale dla wielu zastosowań, na przykład analizy sprzedaży, stanów magazynowych czy przeterminowanych płatności na koniec dnia, to w zupełności wystarcza.

Gotowe pliki wymiany. Wiele programów generuje standardowe pliki: JPK, eDeklaracje, pliki przelewów do banku, raporty do GUS. Serwer MCP może czytać te pliki i odpowiadać na pytania na ich podstawie, nie ruszając w ogóle samego programu.

Typowy przykład: u klienta pracującego na starszej wersji Symfonii bez API podłączyliśmy asystenta przez codzienny eksport XML sprzedaży. Asystent odpowiada na pytania o faktury, marże i zaległości na podstawie pliku z wieczora. Instalacji Symfonii nie tknęliśmy, żadnych zmian w konfiguracji programu, żadnych aktualizacji wymaganych od firmy.

Co serwer MCP daje więcej niż bezpośrednie połączenie z danymi?

Można by zapytać: jeśli AI może odpytywać bazę SQL bezpośrednio, to po co w ogóle serwer MCP? To uzasadnione pytanie, i ma konkretną odpowiedź.

Bezpośredni dostęp AI do bazy bez żadnej kontrolowanej warstwy to ryzyko. Asystent może wygenerować zapytanie SQL, które zablokuje bazę na kilka minut albo przypadkowo przetworzy milion rekordów przy prostym pytaniu. Może też wygenerować zapytanie modyfikujące dane, jeśli nie ma wyraźnej bariery. Serwer MCP działa jak bramka z kontrolą:

• Opisane uprawnienia do każdego narzędzia: to narzędzie tylko czyta faktury, tamto może zapisać nowe zgłoszenie serwisowe, ale tylko po potwierdzeniu przez użytkownika. AI nie może wykonać czegoś, czego nie ma zdefiniowanego jako narzędzie z odpowiednimi uprawnieniami.
• Log każdej operacji: kiedy, przez jakiego użytkownika, jakie narzędzie, jakie parametry, co dostało w odpowiedzi. Zarząd albo audytor może sprawdzić, co asystent robił z danymi firmy w dowolnym dniu.
• Opisy w języku naturalnym, nie surowe struktury bazy: zamiast rozwiązywać, czy klucz relacji to id_dok czy FaId, asystent widzi: "Pobierz fakturę sprzedaży po numerze". Zmniejsza to błędy i poprawia trafność odpowiedzi.
• Kilka źródeł przez jedno środowisko: jeden serwer MCP może łączyć dane z ERP, z osobnej bazy CRM, z pliku wymiany i z zewnętrznego API (np. GUS lub VIES). Asystent pracuje z nimi jako jednym zestawem narzędzi, nie wiedząc, że za jednym pytaniem stoi pięć różnych źródeł.

To dlatego mówimy: nie "AI ma dostęp do Optimy", tylko "AI ma dostęp do Optimy przez serwer MCP". Różnica jak między kluczem do każdego pomieszczenia w biurze a recepcjonistą, który wpuszcza w wybrane miejsca i zapisuje kto wchodził i po co.

Jeśli zastanawiacie się, jak wygląda taka architektura od strony wdrożenia: wdrożenie MCP dla firmy opisuje, co robimy krok po kroku, od analizy istniejących programów po gotowy serwer z opisanymi narzędziami i testami na realnych danych.

WebMCP: co to jest i czy zmienia plany dla programów firmowych?

Przy rozmowach o MCP pojawia się coraz częściej termin WebMCP. Warto od razu wyjaśnić, bo to inna rzecz niż serwer MCP dla programów biznesowych.

WebMCP to projekt specyfikacji prowadzony przez W3C Community Group, za którym stoją Google i Microsoft. Chodzi o to, żeby strony internetowe mogły same opisywać swoje formularze i akcje jako narzędzia dla asystenta AI działającego w przeglądarce. Zamiast osobnego serwera, opisy byłyby wprost w HTML: atrybuty toolname, tooldescription i toolparamdescription na formularzach i polach wejściowych. W JavaScripcie pojawia się navigator.modelContext, przez który strona może wymieniać informacje z asystentem użytkownika.

Stan na wrzesień 2026: Chrome testuje WebMCP w ramach origin trial, wejście do stabilnej wersji planowane na koniec 2026 roku. Edge też go testuje. Safari nie zapowiedziało wsparcia. WebMCP nie jest jeszcze standardem W3C, to projekt w Community Group.

Co istotne: przeglądarka bez WebMCP po prostu pomija te atrybuty. Strona działa normalnie. Wdrożenie WebMCP na stronie niczego nie psuje u odwiedzających ze zwykłą przeglądarką. W Polsce praktycznie nikt nie oferuje jeszcze takich wdrożeń.

Dla programów ERP, magazynowych i kadrowych: WebMCP nie zmienia niczego. Dotyczy aplikacji webowych i stron firmowych, nie instalacji serwerowych. Jeśli macie własny panel dla klientów albo sklep internetowy i chcecie, żeby asystent AI w przeglądarce klienta mógł z nich samodzielnie korzystać, to WebMCP jest dla Was interesujący. Dla Optimy, Subiekta i podobnych programów liczy się serwer MCP po stronie serwera, opisany wyżej.

Od czego zaczynamy: lista kontrolna i pierwsze kroki

Zanim zadzwonicie do firmy wdrożeniowej albo Waszego informatyka, warto zebrać kilka konkretnych informacji. Z nimi pierwsza rozmowa trwa kilkanaście minut, a nie kilka godzin:

• Jaki program i dokładnie jaka wersja? Na przykład: Comarch ERP Optima 2024.1.1, enova365 2310.0, Symfonia ERP 2.2. Wersja decyduje, co jest dostępne technicznie.
• Czy program stoi na Waszym serwerze czy w chmurze producenta? Przy własnej instalacji jest więcej opcji, przy chmurze producenta trzeba sprawdzić, co udostępnia ich API.
• Co AI ma czytać, a czego nie powinno zmieniać samodzielnie? Lista konkretna: faktury VAT, kartoteki kontrahentów, stany magazynowe, grafik pracowników. I oddzielnie: co wymaga zatwierdzenia przez człowieka zanim cokolwiek się zmieni.
• Jakie pytania pracownicy zadają programowi najczęściej? Wypisz 5-10 realnych pytań: "Ile zostało towaru X na stanie?", "Które faktury do kontrahenta Y są nierozliczone?", "Jaka była sprzedaż w październiku na klienta Z?". To fundament, na którym buduje się narzędzia w serwerze MCP.
• Kto zarządza serwerem i bazą danych? Imię i kontakt do administratora IT albo zewnętrznej firmy obsługującej infrastrukturę. Będzie potrzebny na etapie konfiguracji.

Typowo pierwsze wdrożenie zaczyna się od odczytu danych i najprostszych pytań, które mają realną wartość dla konkretnej osoby w firmie: "co jest przeterminowane", "co się kończy na stanie", "jakie faktury czekają na wystawienie". Bezpieczne, bo nie ruszamy danych w programie, i od razu użyteczne, bo oszczędzają czas komuś, kto by to sam klikał przez kilkanaście minut.

Zapis danych przez AI, czyli wystawianie dokumentów, zmiana statusów, aktualizacja kartotek, pojawia się w drugim etapie. Po tym, jak firma widzi na co dzień, jak asystent pracuje i rozumie, jakie ma uprawnienia i gdzie są granice.

Jeśli macie konkretny program i konkretne pytania, które chcielibyście zadawać asystentowi: umówcie 15 minut rozmowy o MCP. Bez przygotowania technicznego. Wystarczy wiedzieć, jaki macie program i co chcielibyście móc pytać. Możecie też zajrzeć na realne wdrożenia, żeby zobaczyć, jak to wyszło w innych firmach.