Opiekunowie protokołu Model Context Protocol (MCP) opublikowali zaktualizowany plan działania, który będzie kształtował następną wersję specyfikacji protokołu, który stał się de facto standardem łączenia modeli sztucznej inteligencji z zewnętrznymi narzędziami i danymi. Post z 22 sierpnia, którego autorami są główni opiekunowie Davida Soria Parra i Den Delimarsky, przedstawia pięć priorytetowych obszarów — od podstawowych komunikatów agentowych po standaryzowaną tożsamość agenta — i pojawia się zaledwie kilka tygodni po przełomowej zmianie specyfikacji protokołu z dnia 28.07.2026 r.
Aktualizacja natychmiast przyciągnęła uwagę społeczności programistów, a ogłoszenie planu działania zebrało w Hacker News ponad 240 głosów pozytywnych i ponad 140 komentarzy w ciągu kilku dni. Dla programistów budujących aplikacje agentowe dokument sygnalizuje, gdzie główni opiekunowie protokołu i grupy robocze spędzą czas na przeglądaniu i które propozycje będą najszybciej przechodzić przez kolejkę. Więcej kontekstu na ten temat znajdziesz w naszych wiadomości AI.
Co zmieniła się już lipcowa specyfikacja
Przed ustaleniem nowych priorytetów opiekunowie podsumowali poprzedni plan działania opublikowany w marcu 2026 r., który skupiał się na czterech obszarach: ewolucja i skalowalność transportu, komunikacja z agentami, dojrzewanie zarządzania i gotowość przedsiębiorstwa. Jak wynika z wpisu na blogu, „znaczący postęp” osiągnięto na wszystkich czterech frontach, a większość zmian pojawi się w wydaniu specyfikacji 28.07.2026 r.
Najbardziej konsekwentną zmianą było usunięcie sesji na poziomie protokołu i uzgadniania inicjalizacji, śledzone jako SEP-2575 i SEP-2567. Ta zmiana oznacza, że serwer MCP może teraz skalować w poziomie bez wstrzymywania stanu — to zasadnicza zmiana, która sprawia, że zdalne serwery MCP zachowują się jak zwykłe usługi sieciowe. Klienci mogą także wywołać nowy punkt końcowy `server/discover`, aby poznać obsługiwane wersje i możliwości serwera, zanim zrobią cokolwiek innego, a wyniki list można przechowywać w pamięci podręcznej zgodnie z SEP-2549.
Po stronie komunikacji agenta konstrukcja Zadania została przerobiona na oficjalne rozszerzenie (SEP-2663), podczas gdy nowy wzorzec Multi Round-Trip Requests (SEP-2322) zastąpił żądania inicjowane przez serwer, dzięki czemu przebiega jak praca wywoływania na serwerach bezstanowych. Dojrzało również zarządzanie: w projekcie formalnie przyjęto drabinkę współautorów, grupy robocze oceniają obecnie własne propozycje ulepszeń, a specyfikacja zyskała odpowiednią politykę dotyczącą cyklu życia funkcji i wycofywania.
Prace nad gotowością korporacyjną koncentrowały się na autoryzacji, weryfikacji wystawcy wysyłki, poświadczeniach klienta powiązanych z wystawcą i dokumentach metadanych identyfikatora klienta jako preferowanej ścieżce rejestracji klienta, przy czym autoryzacja zarządzana przez przedsiębiorstwo została promowana do wersji stabilnej jako rozszerzenie.
Pięć priorytetów na następny cykl wydawniczy
1. Podstawowe metody przesyłania wiadomości agentowych
W pierwszym priorytecie uznaje się, że „nowoczesne obciążenia agentowe nie pasują już do standardowego wzorca żądania i odpowiedzi”. Pętle działają dłużej, serwery przesyłają strumieniowo wyniki, a programiści potrzebują możliwości sterowania pracą w trakcie. MCP rozwija się w kierunku tych wymagań dzięki zadaniom, subskrypcjom i operacjom nasłuchiwania oraz powiadomieniom o postępie — ale opiekunowie chcą, aby dobrze ze sobą współpracowały.
Planowane prace obejmują zdarzenia inicjowane przez serwer, dostarczane za pośrednictwem webhooków i kanałów, „aby klienci nie musieli odpytywać wyników”, przegląd kompozycji obejmujący grupy robocze Agenci, Transporty oraz Wyzwalacze i zdarzenia, a także dojrzewanie rozszerzenia Zadania, aby mogło przejść do podstawowej specyfikacji.
2. Ujednolicenie transportu natywnego dla protokołu HTTP
Opiekunowie napisali, że w lipcowej wersji „zdalny serwer MCP nie różni się teraz od żadnego innego obciążenia HTTP”, dzięki czemu serwery MCP są łatwe do hostowania w infrastrukturze, z której organizacje już korzystają w swoich interfejsach API. Podejście to „sprawdziło się, że można je skalować” i w planie działania zaproponowano obecnie jego rozciągnięcie, aby objąć lokalne serwery posługujące się strumieniowym protokołem HTTP za pośrednictwem standardowego wejścia i wyjścia. Jak argumentuje post, ujednolicenie w jednym transporcie jeszcze bardziej uprościłoby zarówno rozwój serwera MCP, jak i klienta.
3. Tożsamość agenta i zabezpieczenia dostosowane do potrzeb przedsiębiorstwa
Być może najbardziej przyszłościowy priorytet ma na celu wyeliminowanie luki pomiędzy obecnym sposobem autoryzacji MCP a faktycznym działaniem agentów. Obecna autoryzacja opiera się na osobie zatwierdzającej dostęp w przeglądarce — jest to w porządku w przypadku klientów interaktywnych, ale coraz bardziej odbiega od rzeczywistości.
„Coraz więcej rozmówców to agenci działający jako obciążenia w chmurze z własną tożsamością, działający w imieniu nieobecnego użytkownika lub delegujący węższe uprawnienia podagentom” – napisali opiekunowie. Celem jest ustandaryzowany sposób, w jaki serwery MCP będą rozpoznawać tożsamości agentów i ufać im, „oparty na istniejących standardach, a nie wklejanych kluczach API i długotrwałych tokenach”.
Konkretnie prace obejmują sfinalizowanie demonstracji dowodu posiadania (DPoP) i jego przyjęcie, zdefiniowanie opartej na opiniach ścieżki tożsamości agenta i delegowania za pośrednictwem Workload Identity Federation, grant ID-JAG na autoryzację zarządzaną przez przedsiębiorstwo oraz standardową wymianę tokenów. Zespół będzie także w dalszym ciągu współpracować z grupami roboczymi IETF OAuth i WIMSE, aby pomóc w ewolucji podstawowych standardów.
4. Ulepszone elementy podstawowe i progresywne odkrywanie narzędzi
Wywoływanie narzędzi pozostaje częścią MCP, z którą większość programistów styka się w pierwszej kolejności, i według postu „dobrze się sprawdza”. Jednak obsługa wyników nie jest zadowalająca: odpowiedź „narzędzia/wywołanie” może nieść ten sam wynik w więcej niż jednej formie, a twórcy serwerów nie mają możliwości sprawdzenia, którą formę dany klient umieści przed modelem. Plan działania ma na celu ujednolicenie w ramach jednej jasnej umowy.
Opiekunowie zwrócili także uwagę na problem skali. „Połączenie z serwerem zawierającym sto narzędzi oznacza, że model płaci za całą tę powierzchnię, zanim użytkownik zada choć jedno pytanie, a wybór narzędzi staje się coraz gorszy w miarę powiększania się listy” – napisali. Odpowiedzią jest stopniowe odkrywanie, umożliwiające serwerowi zaoferowanie małego punktu wejścia i ujawnienie większej części swojego katalogu w miarę zawężania konwersacji.
5. Ulepszone doświadczenie programisty SDK
Na koniec opiekunowie zobowiązali się do inwestycji w zestawy SDK, dzięki którym większość programistów ma doświadczenie z MCP — w ich ergonomię, zgodność ze specyfikacją oraz dokumentację na każdej obsługiwanej platformie i języku. Zauważyli, że stawka wzrosła teraz, gdy wielu programistów tworzy klientów i serwery MCP „wskazując agenta w naszych bibliotekach”, gdzie przejrzyste interfejsy API i dokładna dokumentacja decydują o tym, czy wygenerowany kod będzie działać przy minimalnym tarciu.
Co to oznacza dla ekosystemu
Plan działania obejmuje praktyczną strukturę zachęt: Propozycje ulepszeń specyfikacji (SEP), które mieszczą się w obszarach priorytetowych, są poddawane przyspieszonemu przeglądowi i mają największe szanse na akceptację, podczas gdy propozycje wykraczające poza zakres nie są automatycznie odrzucane, ale otrzymują ostatnią chwilę czasu konserwatora. Każdy obszar priorytetowy ma wyznaczonych głównych opiekunów i jedną lub więcej grup roboczych, z których każda ma miejsce dla większej liczby autorów, a eksperymentalny mechanizm rozszerzania w ramach SEP-2133 pozwala grupom testować pomysły przed formalnymi propozycjami.
Odkąd firma Anthropic wprowadziła MCP o otwartym kodzie źródłowym pod koniec 2024 r., protokół rozprzestrzenił się w całej branży, a główni dostawcy sztucznej inteligencji i twórcy narzędzi przyjęli go jako powszechny sposób zapewniania modelom dostępu do systemów zewnętrznych. Sierpniowy plan działania sugeruje, że następna faza protokołu będzie w mniejszym stopniu definiowana przez podstawową łączność, a w większym przez trudniejsze problemy ery agentywności: identyfikacja, kto — lub co — faktycznie dzwoni, utrzymywanie długoterminowej pracy w sterowaniu i oswajanie mnóstwa narzędzi, którymi muszą się poruszać agenci.
Dla programistów i zespołów platformowych stawiających na MCP przekaz jest jasny: bezstanowa operacja HTTP jest obecnie zakładanym punktem odniesienia, a środek ciężkości protokołu przesuwa się w stronę agentów, którzy działają autonomicznie, noszą własne weryfikowalne tożsamości i odkrywają możliwości stopniowo, a nie wszystkie na raz.
---
Bądź na Bieżąco z AINajnowsze wiadomości, analizy i przełomy w dziedzinie AI — wszystko w jednym miejscu.
Czytaj więcej wiadomości AI →
