Dotyczy wersji 2026.1.6 i powyżej, autor: Grzegorz Straś
Wstęp
W konfiguracji aplikacji dodano możliwość uruchomienia serwerów MCP (Model Context Protocol) w dwóch trybach: ogólnym oraz aplikacyjnym. Za pośrednictwem serwera ogólnego udostępniany jest zestaw wbudowanych narzędzi umożliwiających dostęp do danych użytkownika i elementów obiegu. Serwer aplikacyjny pozwala natomiast na wystawienie narzędzi opartych o Definicje API skonfigurowane w danej aplikacji. Dzięki temu możliwe jest wykorzystanie istniejącej logiki biznesowej jako operacji dostępnych dla zewnętrznych klientów AI bez konieczności tworzenia dodatkowych integracji.
Czym jest MCP i jak działa w WEBCON?
Model Context Protocol (MCP) to standard umożliwiający aplikacjom AI komunikację z systemami biznesowymi w ustrukturyzowany sposób. W WEBCON pełni rolę warstwy integracyjnej, która udostępnia funkcje platformy jako tzw. narzędzia (tools) dla klientów AI.
Kluczową cechą rozwiązania jest to, że MCP:
- nie wprowadza nowej logiki – wykorzystuje istniejące Definicje API i automatyzacje,
- działa jako warstwa pośrednia (wrapper) nad REST API,
- pozwala AI nie tylko odczytywać dane, ale również wykonywać operacje w systemie.
Uwaga: Serwery MCP działają tylko w nowym modelu licencjowania wprowadzonym w wersji 2026.1.4. Funkcjonalność nie będzie działać w przypadku korzystania z modelu licencjonowania pre-2026 ("Scenariusza 2" opisanego w artykule o licencjach).
Ogólny serwer MCP (General MCP Server)
Pierwszy z trybów działania Serwera MCP zapewnia zestaw siedmiu gotowych narzędzi dostępnych bez konfiguracji. Jest to tryb przeznaczony głównie do scenariuszy przewidujących odczyt danych (read-only) i eksploracyjnych.
- Get current user’s profile – zwraca dane aktualnie zalogowanego użytkownika (imię, e-mail, ID).
- Get my tasks – pobiera listę zadań użytkownika (z możliwością filtrowania i sortowania).
- Get element data – zwraca szczegóły konkretnego elementu obiegu (formularz, pola, komentarze, przypisania itd.).
- Get attachment – umożliwia pobranie zawartości załącznika.
- Get related elements – zwraca elementy powiązane z danym elementem obiegu.
- Search (Get search filters + search execution) – mechanizm wyszukiwania, pobranie dostępnych filtrów (metadata) i wykonanie wyszukiwania na ich podstawie (w praktyce traktowany jako zestaw powiązanych narzędzi).
- Get attachments metadata / details – pomocnicze narzędzie do pracy z załącznikami (np. lista/metadane przed pobraniem).
Serwer MCP dla aplikacji (Application-specific MCP Server)
Powiązany z konkretną aplikacją i oparty o Definicje API – każde narzędzie odpowiada konkretnej definicji API.
Możliwe są operacje odczytu i zapisu (w zależności od konfiguracji), a same narzędzia odwzorowują logikę biznesową aplikacji.
Każda aktywna definicja API zdefiniowana w procesie może zostać automatycznie wystawiona jako narzędzie MCP:
- nazwa narzędzia pochodzi z definicji API,
- schemat wejścia/wyjścia generowany jest automatycznie,
- dokumentacja API staje się opisem narzędzia.
Kluczowym aspektem architektury jest brak duplikacji logiki – API zdefiniowane raz są wykorzystywane przez REST API oraz przez MCP (AI) bez tworzenia dodatkowych implementacji.
Założenia:
- bezpieczeństwo i kontekst użytkownika – operacje wykonywane są w kontekście zalogowanego użytkownika, obowiązują standardowe role i uprawnienia, wykorzystywany jest OAuth2,
- kontrola nad zakresem operacji – administrator decyduje, które API są dostępne,
- możliwe jest ograniczenie do operacji typu read-only lub rozszerzenie o akcje. MCP nie „omija” logiki obiegu ani walidacji,
- w scenariuszach AI, AI proponuje działania, MCP je wykonuje zgodnie z regułami, ale finalnie użytkownik zachowuje kontrolę decyzyjną.
Szybki start (Quick start dla administratora)
- Przygotuj Definicje API w konfiguracji procesu – powinny być aktywne i poprawnie opisane.
- Skonfiguruj OAuth2, zarejestruj Aplikacje API w Panelu Administracyjnym, ustaw typ: Authorization Code, dodaj redirect URI klienta MCP.
- Uruchom Serwer MCP w ustawieniach aplikacji. Osobno włącz: Ogólny serwer MCP (opcjonalnie) oraz Serwer MCP dla aplikacji.
- Zweryfikuj dostępne narzędzia. Zweryfikuj endpointy w wygenerowanej dokumentacji „/api/mcp/server/{server_id}/docs”. Sprawdź listę narzędzi i ich schematy.
- Podłącz klienta AI poprzez konektor. Skonfiguruj połączenie w narzędziu AI (np. Copilot, ChatGPT). Użyj endpointu MCP i OAuth2.
Przykład: Zarządzanie Skargami (Complaint Management)
Poniższy obieg stworzono, aby kategoryzować, analizować oraz odpowiednio reagować na zgłaszane problemy.
W wielu organizacjach proces obsługi skarg wygląda podobnie: do systemu trafiają zgłoszenia pisane w bardzo różny sposób, przez różne osoby i z różnym poziomem szczegółowości. Jedna skarga jest krótka i konkretna, inna zawiera długi, chaotyczny opis, a jeszcze inna miesza kilka problemów naraz. W efekcie zespół odpowiedzialny za obsługę reklamacji dużą część czasu poświęca nie na realne rozwiązanie sprawy, ale na zrozumienie, czego właściwie dotyczy zgłoszenie, czy zostało poprawnie sklasyfikowane i jak wysoki ma priorytet.
Z perspektywy użytkownika końcowego, proces ten – tak jak każdy inny – jest dostępny w Portalu i można nim zarządzać za pomocą formularza.
W scenariuszu tym świetnie sprawdzi się chatbot zintegrowany z aplikacją do obsługi skarg. Jego rola nie polega wyłącznie na rozmowie z użytkownikiem, ale na aktywnym wspieraniu całego procesu.
Aby umożliwić chatbotowi dostęp do danych i logiki procesu, w konfiguracji procesu stworzono 8 definicji API:
Wybrane definicje API stają się Narzędziami Serwera MCP.
Po utworzeniu konektora w wybranym czacie AI użytkownik może podpiąć wewnątrz czatu aplikację i korzystać z udostępnionych narzędzi – AI może prezentować dane i oferować sugestie zgodne z pytaniami użytkownika, ale także wykonywać operacje udostępnione przez narzędzia. W tym przypadku może np.:
- nadać uprawnienia innemu użytkownikowi do skargi;
- ustawić pole wyboru Tak/Nie „Krytyczny”,
- przechodzić ścieżkami do kolejnych kroków,
- dowolnie prosić AI o analizę danych.
Przykładowo możliwe jest zwrócenie się o pomoc w wykrywaniu anomalii:
| ID | Instance number | Why it looks anomalous | Severity |
| 14 | 2026/02/00003/14 | In Plan corrective actions but Severity is blank and Corrective action is blank | High |
| 16 | 2026/02/00005/16 | In Categorize complaint but already has Complaint category = Invoice and Severity = Low; also summary describes a wrong pizza size, which looks more like Product/Order, not Invoice | High |
| 17 | 2026/02/00006/17 | Summary is clearly a system/generated prompt (“Please upload the relevant attachments… overwritten with a standardized prompt…”) rather than an actual complaint | High |
| 18 | 2026/02/00007/18 | Summary says “The soup was too salty” but complaint is in Product while a very similar record elsewhere is categorized as Invoice; possible inconsistent classification across duplicates | Medium |
| 19 | 2026/02/00008/19 | Summary says parking spot taken, but category is Invoice and corrective action plan talks about replacement product / packaging / sealing checks, which does not match the complaint at all | High |
| 27 | 2026/02/00009/27 | Corrective actions plan is just “1”; looks incomplete or corrupted | High |
| 41 | 2026/03/00001/41 | Summary says “Zupa była za słona” but category is Invoice; likely miscategorized | Medium |
| 42 | 2026/03/00002/42 | Summary is about PR review bottlenecks / workflow process, but category is Invoice; looks intentionally test-like or miscategorized | Medium |
Dodatkowo możliwe jest zwrócenie się o pomoc w raportowaniu (filtrowanie i szukanie danych, grupowanie po krokach, po osobie przypisanej itd.).
Opisany scenariusz nie jest kolejnym przykładem „chatbota do rozmowy”, ale przykładem AI osadzonej w procesie biznesowym. Asystent nie działa obok aplikacji, lecz wewnątrz niej, analizując dane z formularza, wspierając użytkownika przy wprowadzaniu informacji, oceniając spójność zgłoszenia, podpowiadając priorytet i pomagając przygotować odpowiedź.
Jeżeli użytkownik w trakcie rozmowy jest gotowy podjąć działanie nie musi „przełączać się” między chatem a Portalem; najważniejsze czynności, takie jak oflagowanie, przekazanie zadań, rozpoczęcie kolejnego etapu analizy, może wykonać z poziomu chatu.
Podsumowanie
MCP w WEBCON to rozszerzenie istniejących mechanizmów integracyjnych, które umożliwia wykorzystanie logiki biznesowej w scenariuszach AI bez dodatkowego developmentu. Dzięki podziałowi na serwer ogólny i aplikacyjny możliwe jest zarówno szybkie rozpoczęcie pracy z danymi, jak i budowanie zaawansowanych integracji dopasowanych do konkretnych procesów.
Rozwiązanie to stanowi fundament pod budowę nowoczesnych scenariuszy AI, w których użytkownik komunikuje się z systemem poprzez język naturalny, a operacje wykonywane są w sposób kontrolowany, bezpieczny i zgodny z logiką biznesową.