Protokół Model Context Protocol osiągnął kamień milowy w infrastrukturze: jego wersja z 28.07.2026 przesuwa protokół w kierunku rdzenia bezstanowego. W przypadku zespołów tworzących systemy agentów, serwery narzędzi, integracje IDE lub warstwy orkiestracji obejmujące wiele modeli nie jest to kosmetyczna aktualizacja specyfikacji. Zmienia założenia dotyczące sesji, inicjalizacji, skalowania, kompatybilności i zarządzania.

Kandydat do wydania MCP opisał specyfikację z 28 lipca jako dodanie bezstanowego rdzenia protokołu, struktury rozszerzeń, zadań, aplikacji MCP, wzmacniania autoryzacji i formalnej polityki wycofywania. Oficjalny blog MCP ostrzegł również, że wydanie zawiera przełomowe zmiany. GitHub, który obsługuje jedną z najbardziej widocznych implementacji serwerów MCP, przed wydaniem ostatecznej wersji oznajmił, że jego serwer MCP obsługuje już nową specyfikację i 28 lipca określił protokół jako „przejdzie w stan bezstanowy”.

Praktyczne znaczenie jest proste: MCP ma kształt mniej przypominający lokalną warstwę integracji obciążającą sesje, a bardziej protokół internetowy umożliwiający zdalny dostęp do narzędzi. Ma to znaczenie, ponieważ systemy agentów nie są już ograniczone do narzędzi programistycznych dla komputerów stacjonarnych. Coraz częściej działają w usługach w chmurze, systemach CI, przepływach pracy obsługi klienta, narzędziach do śledzenia problemów i platformach automatyzacji przedsiębiorstwa.

Co zmieniło się w MCP

Główną zmianą jest przejście na bezstanowy rdzeń protokołu. Z dziennika zmian GitHuba wynika, że ​​nowy rdzeń usuwa sesje i inicjuje, co ma na celu ułatwienie skalowania zdalnych wdrożeń MCP. To znacząca zmiana architektoniczna. Protokoły stanowe mogą dobrze działać w przypadku narzędzi lokalnych i środowisk kontrolowanych, ale komplikują skalowanie poziome, wykonywanie bezserwerowe, przełączanie awaryjne, wdrażanie brzegowe i równoważenie obciążenia.

Bezstanowy rdzeń zapewnia wdrażającym większą swobodę w uruchamianiu serwerów MCP za zwykłą infrastrukturą sieciową. Żądania mogą być dystrybuowane pomiędzy instancjami bez zachowywania długotrwałej sesji na określonym backendzie. W przypadku dużych organizacji może to zmniejszyć złożoność operacyjną. W przypadku mniejszych zespołów może to ułatwić wdrażanie hostowanych serwerów MCP przy użyciu zarządzanych obliczeń zamiast niestandardowej, długotrwałej infrastruktury.

W szerszej wersji 28.07.2026 wprowadzono także strukturę rozszerzeń i zadania, zgodnie z materiałami kandydującymi do wydania. Dodatki te sugerują, że MCP staje się coraz bardziej modułowe i wyraźniej mówi o dłuższej pracy. Aplikacje MCP i utwardzanie autoryzacji zmierzają w tym samym kierunku: protokół dojrzewa od wczesnego kleju ekosystemowego do bardziej formalnej warstwy interakcji agent-narzędzie.

Kosztem tego dojrzewania jest praca nad zgodnością. Blog MCP scharakteryzował tę wersję jako zawierającą przełomowe zmiany, a materiały TypeScript i C# SDK opublikowane wokół tej wersji skupiają się na obsłudze migracji i koncepcjach bezstanowych. Każdy zespół obsługujący serwer MCP, osadzający MCP w rozszerzeniu IDE lub kierujący wywołania agenta przez infrastrukturę wewnętrzną powinien traktować tę wersję jako wydarzenie inżynieryjne, a nie aktualizację standardów w tle.

Dlaczego bezstanowe MCP jest ważne dla programistów i operatorów

Narzędzia agenta mają problem ze skalowaniem, który wygląda inaczej niż zwykłe skalowanie API. Pojedyncze żądanie użytkownika może wywołać wiele wywołań narzędzi, obrotów modelu, ponownych prób, odczytów plików, zapytań wyszukiwania i etapów zatwierdzania. Gdy protokół narzędzia zakłada trwałe sesje, operatorzy produkcji muszą zachować stan tych interakcji lub opracować obejścia protokołu.

Usuwając sesje z rdzenia, MCP lepiej sprawdza się w środowiskach, w których obciążenia agentów są masowe, rozproszone i asynchroniczne. Funkcje bezserwerowe, procesy brzegowe, wdrożenia Kubernetes i systemy wieloregionowe – wszystkie korzyści, gdy żądania mogą być obsługiwane niezależnie. Nie eliminuje to stanu z aplikacji agentowych; przenosi stan do baz danych aplikacji, kolejek zadań, systemów tożsamości lub jawnych warstw przepływu pracy, zamiast osadzać go w rdzeniu protokołu.

Dla programistów zmiana powinna ostatecznie ułatwić korzystanie ze zdalnych serwerów narzędzi. W przypadku zespołów zajmujących się platformami może to uprościć obserwowalność i planowanie wydajności. Zamiast debugować nieprzejrzyste zachowanie powinowactwa sesji, operatorzy mogą skupić się na śladach na poziomie żądań, opóźnieniach wywołań narzędzi, decyzjach dotyczących autoryzacji i wzorcach błędów.

Istnieje również aspekt zarządzania. W miarę jak MCP staje się coraz bardziej powszechne wśród asystentów kodowania i agentów korporacyjnych, firmy będą potrzebować zasad dotyczących narzędzi, do których agenci mogą dzwonić, do jakich danych mogą uzyskać dostęp i którzy użytkownicy lub usługi mogą z nich korzystać. Dlatego też zaostrzenie uprawnień w nowej wersji nie jest przypadkowe.Odzwierciedla to rzeczywistość, w której dostęp do narzędzi stanowi obecnie granicę bezpieczeństwa, a nie tylko wygodę programisty.

Kogo dotyczy

Grupy najbardziej bezpośrednio dotknięte to konserwatorzy serwerów MCP, użytkownicy SDK, zespoły platform agentów i organizacje udostępniające wewnętrzne narzędzia agentom AI. Jeśli serwer zależy od zachowania sesji lub starszych przepływów inicjalizacji, będzie wymagał przetestowania pod kątem nowej specyfikacji. Jeśli aplikacja obsługuje wiele wersji MCP, może wymagać negocjacji wersji, warstw zgodności lub planu migracji etapowej.

W grę wchodzą także dostawcy IDE i narzędzi dla programistów. MCP coraz częściej pojawia się obok agentów kodujących, agentów niestandardowych i funkcji zarządzania modelami. Bezstanowy rdzeń protokołu ułatwia tym produktom niezawodne wywoływanie narzędzi zdalnych, ale tylko wtedy, gdy ich integracja jest zgodna ze specyfikacją.

Firmy korzystające z automatyzacji agentów powinny zwracać na to uwagę, nawet jeśli nigdy nie czytały specyfikacji MCP. Zmiana może mieć wpływ na niezawodność agentów łączących się z repozytoriami, systemami biletowymi, bazami danych, wewnętrznymi bazami wiedzy lub narzędziami wdrożeniowymi. Podczas okien migracji prawdopodobnymi awariami są nie tylko oczywiste awarie. Mogą obejmować brakujące możliwości narzędzia, zmienione zachowanie uwierzytelniania lub agenci podążający innymi ścieżkami, ponieważ serwer narzędzi nie zachowuje się już zgodnie z oczekiwaniami.

W przypadku bramy AI API, takiej jak Model Gate, połączenie jest praktyczne. Ujednolicony interfejs API AI w coraz większym stopniu opiera się na routingu modeli, zarządzaniu kluczami API, analityce użycia i zarządzaniu interfejsem API zespołu. Ponieważ systemy agentów dodają wywołania narzędzi MCP obok zwykłych wywołań modeli, warstwy bramy i obserwowalności będą musiały uwzględniać obie strony przepływu pracy: który model został użyty, jakie narzędzia zostały wywołane, ile kosztowały, kto je autoryzował i gdzie wystąpiły awarie.

Priorytety migracji i pytania otwarte

Pierwszym priorytetem migracji jest testowanie zgodności. Zespoły powinny inwentaryzować klientów i serwery MCP, identyfikować zależności w sesjach lub inicjować zachowanie oraz testować pod kątem zestawów SDK z dnia 2026-07-28 lub materiałów dotyczących zgodności, jeśli są dostępne. Systemy produkcyjne powinny przeprowadzać aktualizację na etapie, zwłaszcza jeśli agenci wykonują działania powodujące skutki uboczne, takie jak tworzenie żądań ściągnięcia, modyfikowanie problemów, wysyłanie zapytań do danych klientów lub wykonywanie przepływów pracy wdrożeniowych.

Drugim priorytetem jest obserwowalność. Infrastrukturę bezstanową można łatwiej skalować, ale rozproszone systemy agentów nadal wymagają identyfikatorów korelacji, przechwytywania śladów, dzienników żądań i zdarzeń związanych z zasadami. Bez nich zespoły mogą zamienić złożoność sesji na złożoność debugowania. Analityka użycia powinna rozróżniać wywołania modeli i wywołania narzędzi, zwłaszcza gdy przepływy pracy agentów są rozliczane, ograniczone stawkami lub kontrolowane przez zespół.

Trzeci priorytet to przegląd autoryzacji. Jeśli nowa specyfikacja zaostrza semantykę autoryzacji, osoby wdrażające nie powinny po prostu przenosić starych założeń dotyczących dostępu do nowej wersji. Powinni ponownie sprawdzić zakresy tokenów, delegowanie użytkowników, konta usług, dzienniki inspekcji i zachowanie odmowy. Dostęp do narzędzi powinien być domyślnie najniższy, szczególnie w przypadku zdalnych wdrożeń MCP.

Niektóre szczegóły warto sprawdzić, zanim organizacje podejmą nieodwracalne decyzje projektowe. Badania dostępne dla tego artykułu obejmowały kandydata do wydania, stronę specyfikacji, materiały dotyczące migracji SDK i notatkę dotyczącą wdrożenia GitHub. Ostateczne brzmienie normatywne specyfikacji z dnia 28.07.2026 r. należy sprawdzić bezpośrednio przed podaniem dokładnych wymagań protokołu w normach wewnętrznych lub dokumentacji klienta.

Nawet przy tym zastrzeżeniu kierunek jest jasny. MCP staje się protokołem bardziej zorientowanym na produkcję dla infrastruktury agentów. Bezstanowy rdzeń powinien ułatwić skalowanie zdalnych wdrożeń, ale zmusza także ekosystem do oczyszczenia założeń z wcześniejszych wdrożeń. W przypadku zespołów pracujących z agentami jest to rodzaj zmiany protokołu, który zasługuje na bilet sprintu, a nie tylko zakładkę.