Przestań zwracać JSON: Wysyłaj interaktywną interfejs użytkownika z aplikacjami MCP
Aplikacje MCP umożliwiają serwerom dostarczanie interfejsów użytkownika w środowisku izolowanym razem z narzędziami, dzięki czemu ludzie mogą je zatwierdzać, konfigurować i obsługiwać bez opuszczania rozmowy z agentem.
Przez większość wczesnego okresu istnienia MCP pętla interakcji pozostawała wąska: agenci wywołują narzędzia, narzędzia je wykonują, serwery odpowiadają tekstem lub strukturyzowanymi danymi, a modele parafrazują wynik dla ludzi.
Bardzo wiele pytań nadal pasuje do tego modelu. Liczenie prawidłowych implementacji nie wymaga żadnego specjalnego narzędzia: wystarczy wywołać funkcję get_deployments(), odczytać zwięzły obiekt taki jak {"total": 12, "healthy": 10, "degraded": 2}, a następnie odpowiedzieć w jednej linii.
Sytuacja zmienia się, gdy ludzie chcą interakcjonować z wynikiem. Tablice kontrolne, procesy zatwierdzania, tabele filtrowalne, formularze konfiguracyjne, wykresy, panele implementacji, wieloetapowe procesy robocze oraz mechanizmy z udziałem człowieka wymagają czegoś więcej niż prostego wyeksportowania danych w formacie JSON. Przez długi czas MCP nie oferował żadnego standardu międzyhostowego w tym zakresie. Teraz takowy istnieje, nosi nazwę MCP Apps i rozszerza to, co serwer MCP może reprezentować.
Serwery MCP były przede wszystkim interfejsami maszynowymi
Pierwszy model mentalny był zorientowany na agenty. Serwery udostępniają takie narzędzia jak search_projects(), create_ticket(), restart_service() oraz get_customer(). Modele je odkrywają, do nich wywołują, otrzymują dane, a ludzie widzą to, co model postanowi pokazać. Jest to potężne rozwiązanie, ponieważ operacje odbywają się przez jeden protokół zamiast poprzez specjalistyczną integrację dla każdego agenta. Ograniczeniem jest to, że te możliwości zostały zaprojektowane dla maszyn, więc człowiek pozostaje o krok dalej od surowego wyniku.
To jest w porządku, dopóki interakcja nie jest z natury wizualna. Zapytanie „Pokaż mi wszystkie usługi produkcyjne” może zwrócić poprawny obiekt JSON zawierający informacje o stanie, zużyciu CPU i pamięci, jednak kompaktowa karta kontrolna z paskami postępów, odznakami oraz funkcjami Logi/Ponowne uruchomienie/Maßskalierung jest o wiele bardziej przydatna. MCP Apps ma na celu zamknięcie tej luki.
Czym dokładnie są aplikacje MCP?
Aplikacje MCP rozszerzają Model Context Protocol, dzięki czemu serwery mogą dostarczać interaktywne interfejsy użytkownika wraz ze swoimi narzędziami – nie są to zrzuty ekranu ani Markdown udające interfejs użytkownika, lecz prawdziwe aplikacje HTML/JavaScript renderowane wewnątrz hosta MCP. Dokumentacja opisuje narzędzia publikujące zasoby typu ui://, hosty wyświetlające te zasoby w izolowanych iframe’ach, a także ten sam host, który zarówno wprowadza treści narzędzi do widoku, jak i umożliwia ponowne wywoływanie narzędzi wyłącznie przez ten host.
MCP App = MCP Tool + UI Resource + Host/View protocol
Narzędzie nadal korzysta z API, wysyła zapytania do baz danych, wykonuje logikę biznesową i zwraca strukturyzowane dane. Może dodatkowo oferować interfejs użytkownika do prezentacji tych wyników. Interfejs ten jest zasobem MCP, np. ui://services/dashboard, i może zawierać pełny frontend – HTML, CSS, JavaScript, React, wykresy, formularze, przyciski. Dzięki temu jedna operacja obejmuje zarówno funkcjonalność przeznaczoną dla maszyn, jak i interfejs dostępny dla ludzi, ustandaryzowany na wszystkich hostach.
Skąd pochodzą aplikacje MCP?
To rozszerzenie jest nowe. Twórcy, którzy wdrażali serwery MCP do 2025 roku, nie przegapili żadnej tajemniczej funkcji – oficjalny standard jeszcze nie istniał.
Późny listopad 2025 roku przyniósł SEP-1865 – propozycję Apps opracowaną we współpracy z twórcami i administratorami MCP-UI z czołowych laboratoriów modeli. Istniały już eksperymenty równoległe (MCP-UI, Apps SDK); brakowało jednak jednego spójnego sposobu na dostarczanie przez serwer narzędzi, danych i interfejsów użytkownika, które każdy zgodny host mógłby wyświetlić. Post na blogu MCP z listopada 2025 roku dotyczący propozycji Apps zawiera informację o ogłoszeniu SEP-1865.
Pod koniec stycznia 2026 roku ta sama grupa ogłosiła Apps jako pierwszą oficjalną rozszerzalność gotową do użycia w produkcji, charakteryzującą się bardziej precyzyjnymi specyfikacjami, SDK oraz hostami umożliwiającymi jej wdrożenie. Jako wczesni klienci wymieniono ChatGPT, Claude, Goose oraz Visual Studio Code. Post na blogu MCP z stycznia 2026 roku potwierdza, że Apps jest pierwszą oficjalną rozszerzalnością.
Kandydat na wersję z lipca 2026 roku poprawił ogólnie funkcjonalności rozszerzeń – zapewnił stabilne identyfikatory, umożliwił negocjację możliwości, oddzielił repozytoria, wprowadził niezależne wersjonowanie oraz stworzył sekcję Extensions Track, która wymienia aplikacje. Podkreślono również, że wywołania poprzez przyciski nadal przechodzą przez ścieżkę JSON-RPC hosta, dzięki czemu Agent → Tool oraz Human → Button → Tool pozostają pod jednym planem sterowania. Post o kandydacie na wersję z lipca 2026 roku opublikowany na blogu MCP omawia sekcję Extensions Track.
We wrześniu 2026 roku artykuł na temat AWS Bedrock AgentCore przedstawił konkretny wzorzec hostowania, który nie ogranicza się wyłącznie do aplikacji AWS: host → gateway → runtime → serwer MCP (narzędzia + zasoby interfejsu) → Lambda/DynamoDB. W demonstracji użyto ChatGPT i zaznaczono, że Claude oraz inne hosty aplikacji działają w ten sam sposób. Szczegółowy opis znajduje się w artykule na blogu AWS Machine Learning o interaktywnych aplikacjach MCP z Bedrock AgentCore.
Kto faktycznie wspiera aplikacje MCP?
Wsparcie dla MCP nie jest tym samym co wsparcie dla aplikacji MCP. Klient może obsługiwać zwykłe narzędzia i zasoby bez implementacji rozszerzenia Apps. Ogłoszenie z stycznia 2026 roku wymieniło ChatGPT, Claude, Goose i VS Code; obecne dokumenty opisują renderowanie wewnątrztekstowe w Claude, ChatGPT i innych kompatybilnych klientach, zaznaczając jednocześnie, że wsparcie ze strony hosta jest zróżnicowane. Projektuj z myślą o tej rzeczywistości: nie zakładaj, że każdy klient rozumie aplikacje Apps. Przydatne równanie brzmi Server supports MCP Apps + Host supports MCP Apps = Interactive UI, a staranny serwer powinien przejść na tekst lub strukturyzowany content, gdy host nie może wyświetlić aplikacji.
Jedno pytanie, które naprawdę ma znaczenie
Jeśli zasób interfejsu użytkownika to statyczny HTML, jak zmiany w danych narzędzia docierają do niego? Wydajność CPU może wynosić 21% teraz, a 87% dziesięć sekund później; regenerowanie całego interfejsu na każde wezwanie narzędzia byłoby absurdalne. Rozwiązaniem jest rozdzielenie: interfejs użytkownika i dane to różne elementy. Traktuj narzędzie jako producenta danych, zasób jako warstwę prezentacji, a hosta jako element łączący je. Narzędzie zwraca dane dynamiczne; zasób zwraca aplikację, która wie, jak je wyświetlić; host łączy je w czasie uruchamiania.
Jak faktycznie działają aplikacje MCP
Rozważmy funkcję get_servers(), która zwraca obiekty serwerów zawierające id, nazwę, stan, wydajność CPU i ilość pamięci, a których metadane wskazują na ui://servers/dashboard. Cykl życia:
Model wywołuje get_servers(). Serwer uruchamia swoją logikę – bazę danych, API chmurowe, Kubernetes, usługę wewnętrzną – i zwraca strukturyzowane dane. Host widzi metadane interfejsu użytkownika dla ui://servers/dashboard i wysyła żądanie resources/read. Serwer zwraca plik z kodem frontendu (React, Vue lub zwykły JavaScript). Obecne wiersze serwerów nie są wbudowane w ten HTML; interfejs użytkownika zna jedynie oczekiwany kontrakt (servers[].id, servers[].status itp.).
Host renderuje aplikację w zamkniętym iframe, dzięki czemu kod interfejsu użytkownika z serwera MCP nie może swobodnie modyfikować DOM hosta, sesji ani danych uwierzytelniających. Następnie host przekazuje wynik narzędzia do działającego interfejsu, zwykle za pomocą JSON-RPC poprzez postMessage pomiędzy hostem a zamkniętym interfejsem.
Frontend otrzymuje dane w taki sam sposób jak każde SPA i renderuje je odpowiednio. Jeden serwer dostarcza jedną kartę; pięćdziesiąt serwerów dostarcza pięćdziesiąt kart. Aplikacja pozostaje niezmieniona; zmieniają się tylko dane.
W porównaniu z klasyczną aplikacją internetową — gdzie React wywołuje GET /api/servers — w MCP Apps agent uruchamia tools/call, narzędzie zwraca JSON, a host wstrzykuje to JSON do aplikacji React znajdującej się w iframe. Interfejs nie zawsze pobiera dane samodzielnie; host może przesłać wyniki do niego.
Ale MCP Apps to nie tylko ładniejsze wyniki narzędzi
Głębszą cechą jest to, że aplikacja może również wywoływać narzędzia. Przyciski, formularze i wykresy nie służą tylko dekoracji; mogą używać tych samych narzędzi MCP, których używa agent, za pośrednictwem hosta.
MCP App → call tool → Host → tools/call → MCP Server → restart_server()
Naprzимер, przycisk restartu w panelu sterowania może wywołać restart_server za pośrednictwem hosta, zamiast tworzyć dodatkowy kanał komunikacji:
async function restartServer(serverId) {
return app.callServerTool({
name: "restart_server",
arguments: { server_id: serverId }
});
}
Hositator pozostaje osobą odpowiedzialną za uprawnienia, rejestrację działań oraz polityki.
Jedna funkcjonalność, dwa interfejsy
Ta sama operacja w tle może zatem mieć dwa aspekty: narzędzie, do którego model odwołuje się podczas rozmowy, oraz aplikację, którą człowiek obsługuje wizualnie. Żadne z nich nie zastępuje drugiego. Agenci nadal doskonale radzą sobie z rozumowaniem otwartym; aplikacje natomiast sprawdzają się, gdy ważna jest struktura, gęstość informacji lub powtarzalne działania.
Przykład z praktyki: zatwierdzenie przez człowieka w ramach procesu pracy agenta
Załóżmy, że agent sporządza historię użytkownika, która musi zostać zatwierdzona przed jej zapisaniem. Bez aplikacji model wkleja projekt do czatu i ma nadzieję, że osoba ludzka wpisze „zatwierdzić” lub „odmówić z uzasadnieniem”. Z aplikacjami narzędzie takie jak present_user_story_for_approval może zwrócić projekt wraz z zasobem interfejsu użytkownika pokazującym opcje Akceptuj / Poproś o zmiany / Odmów. Kliknięcie na Odmówić może otworzyć pole na wpisanie uzasadnienia; wysłanie danych może uruchomić narzędzie, które zapisuje decyzję i opcjonalnie aktualizuje kontekst modelu, aby w następnej rundzie już wiedziano, dlaczego wersja 1 nie zadziałała.
To podejście polega na udziale człowieka z rzeczywistym interfejsem sterowania, a nie na kruchym rytuale opartym na języku naturalnym.
Nie każdy przycisk musi być narzędziem widocznym dla modelu
Część narzędzi powinna być dostępna wyłącznie dla agentów, inne tylko dla aplikacji, a jeszcze inne wspólnie. Paginację w panelu sterowania można wywołać tylko z widoku, aby model nie został przeciążony narzędziami do przerzucania stron. Serwer może określać różne poziomy widoczności, tworząc rzeczywiste granice dostępu zamiast zwykłej konwencji nazewniczej.
Komunikacja może również płynąć z aplikacji do kontekstu modelu (gdy host na to pozwala): powód odrzucenia wpisany w interfejsie może zaktualizować kontekst, dzięki czemu kolejna iteracja modelu poprawi projekt bez konieczności ponownego wpisywania krytyki przez użytkownika w czacie.
MCP Apps to nie nowa podstawowa zasada
Pomimo nazwy, Apps nie stanowi czwartego elementu obok narzędzi/zasobów/promptów. Jest to rozszerzenie, które standaryzuje związek pomiędzy narzędziem a zasobem interfejsu oraz protokołem hosta/widoku. Skoro narzędzia i zasoby są już dobrze znane, Apps stanowi interaktywną warstwę wokół nich – a nie oddzielny protokół dodany na końcu.
Jakie zmiany następują, jeśli posiadasz aplikację do czatowania
Zespoły tworzące własną platformę agentów stają się hostem MCP. Ten host musi wykrywać metadane interfejsu użytkownika, odczytywać zasoby, izolować aplikację w środowisku sandbox, przekazywać dane wejścowo-wyjściowe narzędzi do widoku, przekierowywać dozwolone wywołania narzędzi z powrotem na serwer, negocjować możliwości działania oraz egzekwować uprawnienia. To rzeczywiście złożona struktura architektoniczna.
Istnieją trzej uczestnicy – serwer MCP, host MCP oraz widok aplikacji MCP – a oficjalne SDK oddziela programistów tworzących widoki, hosty oraz autorów serwerów. Pakiety pomocnicze znajdują się w katalogu @modelcontextprotocol/ext-apps w TypeScript, co nie zmusza logiki biznesowej do pracy w środowisku Node. MCP na poziomie połączeń nadal wykorzystuje metadane narzędzi, zasoby, strukturyzowany kontent oraz żądania MCP, więc serwer napisany w Pythonie/FastMCP może funkcjonować, o ile udostępnia to, czego oczekują hosty obsługujące funkcje Apps. Widok jest realizowany za pomocą technologii webowych; istniejące backendy mogą pozostać bez zmian.
Bезpieczeństwo nie może być sprawą drugorzędną
Ruchomy interfejs użytkownika zwiększa ryzyko. Iframe’y w izolacji oraz połączenia za pośrednictwem hosta pomagają, jednak każda aplikacja powinna być traktowana jako niezaufany interfejs użytkownika — szczególnie gdy może uruchomić funkcje takie jak restart_service(), delete_resource(), approve_payment() lub deploy_to_production(). Okna potwierdzenia są przydatne, ale niewystarczające. Autoryzacja, walidacja, polityki bezpieczeństwa, logi audytowe, zasady idempotencji, sprawdzanie wersji oraz limity szybkości nadal muszą znajdować się po stronie serwera. Interfejs użytkownika nie stanowi granicy zaufania.
Gdzie aplikacje MCP faktycznie mają sens
Nie należy otaczać każdego narzędzia aplikacją. Aby zwrócić wartość 42 lub ciąg znaków reprezentujący wersję, nie jest potrzebny React. Aplikacje okazują się przydatne wtedy, gdy interakcja ma określoną strukturę:
Panel sterowania operacjami — usługi, implementacje, infrastruktura, logi, metryki, zadania, kolejki: analiza, a następnie działanie.
Procesy zatwierdzania — zatwierdzać/odrzucać, akceptować/prosić o zmiany, wdrażać/anulować, publikować/przechowywać w wersji roboczej. Często stanowią najlepsze rozwiązanie dla dużych przedsiębiorstw.
RAG i wyszukiwanie wiedzy w przedsiębiorstwach — filtry, pola wyboru oraz funkcja „Porównaj wybrane” dają lepsze wyniki niż dwadzieścia rezultatów z tekstu prostego, przy czym agent nadal zajmuje się rozumowaniem.
Zarządzanie agentami — język naturalny pomaga określić, kto ma dostęp do produkcji w Salesforce; widok rejestru jest lepszy do przeglądania i zatwierdzania zmian uprawnień.
Formularze i konfiguracja — podawanie informacji w formie „CPU 2, pamięć 4GB, region us-east-1, repliki 3” jest gorsze niż użycie formularza, który agent wywołuje w razie potrzeby.
Nie twórz jednej aplikacji na każde narzędzie
Unikaj rozprzestrzeniania się tool_1 → app_1. Woląj aplikacje działające w domenie. Aplikacja „Deployment Management” może łączyć operacje pobierania danych, logowania, restartu, skalowania i cofania zmian w jedną grupę. Jedno narzędzie umożliwia dostęp do aplikacji; następnie interfejs może bezpośrednio wywoływać powiązane operacje. Interfejs użytkownika pozostaje spójny, a struktura MCP staje się bardziej uporządkowana.
Bardziej znacząca zmiana architektoniczna
Ciekawą zmianą nie jest sam iframe. Operacje zaprojektowane dla agentów mogą teraz dostarczać standaryzowaną warstwę przeznaczoną dla ludzi:
OPERATION → Machine Interface (MCP Tool) + Human Interface (MCP App)
Jeśli funkcjonalności są pakowane jako plagińty dla agentów, pakiet Salesforce może zawierać razem instrukcje, narzędzia (search_accounts, create_opportunity, update_lead), uprawnienia, oceny oraz aplikacje (przeglądarka kont, formularz szansy sprzedażowej, panel sterowania procesem). Funkcjonalność ta staje się pełną powierzchnią interakcji zarówno dla agentów, jak i ludzi.
Agent nie musi znać React ani faktu istnienia iframów. Wywołuje get_services(...) lub present_user_story_for_approval(...); metadane informują hosta o istnieniu interfejsu. Interfejs pozostaje w warstwie UI, gdzie odbywa się komunikacja z agentem, natomiast logika biznesowa znajduje się w backendzie.
Jak wprowadziłbym to do istniejącego systemu
Na platformie, która już posiada dostosowany czat, agenty oraz serwer FastMCP, unikaj przeprojektowania. Zacznij od jednej funkcji tylko do odczytu, takiej jak getagents(), wraz z najprostszym widokiem (ui://agents/list) pokazującym nazwy, statusy i liczbę narzędzi — bez przycisków. Udowodnij działanie tego mechanizmu: agent wywołuje narzędzie, host wykrywa interfejs, odczytuje zasób, renderuje iframe, a wynik narzędzia trafia do widoku.
Następnie dodaj funkcję Odśwież, potem rzeczywistą operację taką jak Wyłączenie agenta, dalej autoryzację i rejestrację działań audytowych, a na końcu bardziej zaawansowane aplikacje. Wdrożenie odbywa się stopniowo, bez konieczności przepisywania logiki agenta.
Zespoły oceniające możliwości wdrożenia powinny również przewidzieć budżet na negocjację możliwości hosta. Serwer świadomy aplikacji, który zawsze przekazuje metadane interfejsu użytkownika, nadal może poprawnie funkcjonować na starszych klientach, jeśli host po prostu ignoruje nieznane pola, a strukturalna zawartość narzędzia pozostaje kompletna sama w sobie. Z drugiej strony host, który twierdzi o obsłudze aplikacji, musi zaimplementować mechanizmy sandboxingu, odczytu zasobów oraz proxyingu wywołań narzędzi, zanim włączy flagę funkcji dla użytkowników końcowych; niepełnie zaimplementowane hosty tworzą uszkodzone iframy, które szybciej niszczą zaufanie niż zwykły JSON.
Zachowanie aplikacji powinno być uwzględnione w tym samym planie wdrażania. Rejestruj, które narzędzia przenoszą zasoby interfejsu użytkownika, które serwery je renderują, które wywołania narzędzi inicjowane przyciskami zakończyły się sukcesem, a które przechodzą na wersję tekstową. Te metryki pokazują, czy aplikacje rzeczywiście przekazują interaktywny obciążenie, czy też użytkownicy wciąż wolą pisać wiadomości ręcznie. Bez takich danych telemetrycznych łatwo jest wdrożyć panele kontrolne, których nikt nie używa.
Na koniec pamiętaj o wersjonowaniu umów schematycznych. Aplikacja i narzędzie muszą się zgadzać co do nazw i typów pól. Rozbicie servers[].cpu na zagnieżdżone obiekty bez aktualizacji umowy interfejsu spowoduje wyświetlanie pustych elementów, mimo że agent nadal otrzymuje poprawny JSON. Traktuj oczekiwany payload aplikacji jako publiczną API należącą do tej samej grupy, która odpowiada za narzędzie.
Podczas oceny sukcesu po wdrożeniu należy odróżnić „Aplikacja wyświetlona” od „Aplikacja użyta”. iframe, który jest renderowany raz i nigdy nie otrzymuje kliknięcia, stanowi jedynie ciekawostkę; natomiast aplikacja powodująca ponowne uruchomienia, potrzebę zatwierdzeń lub zmian konfiguracji ma rzeczywisty wpływ na produkt. Połącz analizę produktu z logami audytowymi MCP, aby móc pokazać, które działania ludzi pochodzą z aplikacji a które z czatu, oraz czy te działania skróciły czas rozwiązania zgłoszeń już obsługiwanych przez agentów.
Ostatnia myśl
MCP odpowiada na pytanie, w jaki sposób agenci komunikują się z zewnętrznymi systemami za pomocą jednego protokołu. Aplikacje MCP pytają natomiast, w jaki sposób ludzie mogą korzystać z tych samych funkcji bez opuszczania rozmowy.
Vczorajszą ścieżką były agent, narzędzie, JSON, a następnie proza. Dziś jedna tylko funkcjonalność może się rozgałęziać: modele nadal wywołują narzędzia podczas rozmowy, podczas gdy ludzie korzystają z aplikacji wizualnej, a obie gałęzie kończą się w tych samych usługach domenowych. Rozumowanie pozostaje przy agencie, wykonywanie zadań przy narzędziach, a gdy praca wymaga struktury, protokół może wyświetlać panele kontrolne, formularze, procesy zatwierdzania, wykresy, panele konfiguracji oraz elementy sterujące opracowane przez ludzi wewnątrz czatu — bez rezygnacji z warstwy MCP, od której już korzystają agenci.
Dlatego właśnie MCP Apps to coś więcej niż tylko ładniejsze odpowiedzi: serwery ewoluują z punktów końcowych skierowanych do maszyn w przenośne warstwy interakcji zarówno dla agentów, jak i ludzi.
W dokumencie instrukcyjnym swojego serwera wyraźnie opisz możliwości awaryjne: jakie narzędzia deklarują zasoby interfejsu użytkownika, które hosty potrafią je renderować oraz jak wygląda tekst/struktura awaryjna, gdy aplikacje są niedostępne. Taka dokumentacja zapobiega zgłoszeniom wsparcia w stylu „MCP nie działa”, gdy rzeczywistym problemem jest host bez włączonej rozszerzenia.
Dalsza lektura
Główna dokumentacja dotycząca rozszerzenia Apps jest dostępna pod adresem apps.extensions.modelcontextprotocol.io (sekcje przeglądowe i API). Opisy chronologiczne znajdują się na blog.modelcontextprotocol.io – dotyczą one propozycji z 2025 roku, ogłoszenia o wdrożeniu w 2026 roku oraz wersji kandydackiej Extensions Track. Blog Machine Learning firmy AWS później przedstawił wzorzec hostowania Bedrock AgentCore, który pozostaje niezależny od konkretnego hosta.
Jeśli obecnie zarządzasz kilkoma serwerami MCP, oprzej się pokusie tworzenia prywatnego mini-frameworka dla każdego zespołu. Wolij wspólne narzędzia hosta do obsługi cyklu życia iframe, wspólne typy TypeScript dla danych przekazywanych przez narzędzia wykorzystywane przez aplikacje oraz krótką listę kontrolną przy projektowaniu: Czy to narzędzie wymaga interfejsu użytkownika? Czy istnieje już aplikacja, która mogłaby je przejąć? Jaka jest alternatywa, gdy host nie może wyświetlić aplikacji? Kto odpowiada za autoryzację żądań uruchamianych przez przyciski? Te cztery pytania pomagają uniknąć nadmiernego rozprzestrzeniania się aplikacji w niewłaściwym momencie.
Szkolenie również ma znaczenie. Agenci, którzy nagle widzą mniej narzędzi, ponieważ niektóre operacje przeniosły się do obszaru dostępnego wyłącznie w aplikacji, będą zachowywać się inaczej. Aktualizuj instrukcje systemowe oraz zestawy testów przy dzieleniu poziomów dostępu, a także utrzymuj test „złotej ścieżki”, który otwiera aplikację, kliknie w bezpieczną akcję i sprawdzi, czy pojawi się wiersz audytu w tle. Bez tego testu regresje pozostają ukryte w iframe, dopóki klient nie zgłosi uszkodzonego przycisku.
Gdy te elementy będą w miejscu, aplikacje MCP przestaną być postrzegane jako nowość i zaczną wyglądać jak zwykłe elementy interfejsu produktowego dla platform agentów. Dzięki temu zamknie się pętla wdrażania dzięki jasnym rozwiązaniom awaryjnym i mierzalnemu wykorzystaniu.
Literatura pokrewna
- Protokół Contextu Modelu dla Początkujących z FastMCP i Ollama — Poznaj role w MCP: host, klient, serwer, transport — a następnie połącz lokalny model qwen3:8b z serwerem narzędzia pogodowego za pomocą FastMCP i STDIO.
- Jak Protokół Contextu Modelu Pozwala Agentom AI Odkrywać i Wywoływać Narzędzia — Jasne wyjaśnienie MCP: jak hosty, klienci i serwery umożliwiają aplikacjom AI odkrywanie narzędzi, wywoływanie ich za pomocą ustrukturyzowanych danych wejściowych oraz wskazanie ich ograniczeń.