Roadmapa MCP 2026-2027: specyfikacja 2026-07-28 i co dalej

Roadmapa MCP 2026 opisuje rozwój Model Context Protocol po linii specyfikacji z listopada 2025 r. Główny kierunek: od samego podłączania narzędzi do gotowości enterprise z uwierzytelnianiem, ścieżkami audytu, rejestrem i wykrywaniem. Specyfikacja 2025-11-25 wprowadziła eksperymentalne Tasks dla długotrwałych żądań, URL Mode Elicitation, tool calling w Sampling i Client ID Metadata Documents. Od 28 lipca 2026 r. obowiązuje specyfikacja 2026-07-28 z bezstanowym rdzeniem protokołu, server/discover i Tasks jako oficjalnym rozszerzeniem. To, co nastąpi później, oznaczamy w tym artykule jako prognozę.

Ten artykuł należy do hubu Przyszłość agentowej AI (2026-2028) i pogłębia temat warstwy integracji, która w 2026 roku dotyczy niemal każdego produkcyjnego systemu agentowego w firmach w Europie.

• Stan obecny (październik 2026): MCP to de facto warstwa integracji dla Agent-to-Tool. W grudniu 2025 r. Anthropic podał ponad 10 000 aktywnych publicznych serwerów i ponad 97 mln pobrań SDK miesięcznie.
• Następny krok: roadmapa maintainerów MCP z sierpnia 2026 r. stawia na pierwszym miejscu tożsamość agentów i bezpieczeństwo enterprise, prymitywy komunikacyjne dla długo działających agentów oraz jednolity transport HTTP. Od grudnia 2025 r. Agentic AI Foundation (Linux Foundation) decyduje o budżecie i strategii, a nie o kierunku technicznym.
• Największe wyzwanie: bezpieczeństwo. Protokół nie potrafi weryfikować opisów narzędzi. Dlatego sandboxing, zasada najmniejszych uprawnień i kontrolowane rejestry pozostają obowiązkiem operatora.

Punkt wyjścia: co oznacza linia specyfikacji 2025-11-25

Anthropic wprowadził Model Context Protocol 25 listopada 2024 r. jako otwarty standard do łączenia aplikacji AI z systemami zewnętrznymi, takimi jak systemy plików, bazy danych, systemy biznesowe i narzędzia deweloperskie. Technicznie MCP opiera się na JSON-RPC 2.0 przez kilka transportów: stdio lokalnie, pierwotnie Server-Sent Events, a od rewizji 2025-03-26 Streamable HTTP.

Rozwój przebiegał w wyraźnych etapach, które trzeba znać, żeby czytać roadmapę:

• Marzec 2025 (2025-03-26): doszły OAuth 2.1, Streamable HTTP, batching JSON-RPC i Tool Annotations. Dzięki temu MCP po raz pierwszy obsłużył uwierzytelnianie w rozumieniu enterprise.
• Czerwiec 2025 (2025-06-18): batching JSON-RPC został ponownie usunięty. Nowością były ustrukturyzowany output narzędzi i Elicitation. Od tego czasu serwery MCP są traktowane jako OAuth Resource Server, a klienci muszą implementować Resource Indicators zgodnie z RFC 8707.
• Listopad 2025 (2025-11-25, linia referencyjna): eksperymentalne Tasks dla długotrwałych żądań z pollingiem, URL Mode Elicitation, tool calling w Sampling, Client ID Metadata Documents jako zalecany sposób rejestracji klientów oraz wykrywanie OpenID Connect.
• Styczeń 2026: MCP Apps (SEP-1865) 26 stycznia 2026 r. stało się pierwszym oficjalnym rozszerzeniem. Dostarcza interaktywny interfejs z serwerów MCP do aplikacji hosta, takich jak Claude i ChatGPT.

Do tego dochodzi zmiana w zarządzaniu projektem: 9 grudnia 2025 r. Anthropic przekazał MCP nowo założonej Agentic AI Foundation (AAIF), funduszowi typu directed fund w ramach Linux Foundation. AAIF założyły Anthropic, Block i OpenAI; obok nich członkami Platinum są AWS, Bloomberg, Cloudflare, Google i Microsoft, a do tego m.in. Cisco, IBM, Okta, Oracle, SAP i Snowflake. Według projektu MCP kierunek techniczny i roadmapa pozostają w rękach maintainerów; zarząd fundacji decyduje o inwestycjach strategicznych, budżecie i nowych członkach. Dla decydentów w Europie oznacza to, że MCP jest standardem neutralnym wobec dostawców, a nie zakładem na jednego producenta. To znacznie zmniejsza ryzyko uzależnienia od dostawcy przy zakupach.

Specyfikacja 2026-07-28: co faktycznie pojawiło się po 2025-11-25

Kolejna specyfikacja nie jest już zapowiedzią. Release Candidate ukazał się 21 maja 2026 r., a finalna specyfikacja 2026-07-28 w dniu 28 lipca 2026 r., razem z zaktualizowanymi SDK Tier 1 dla TypeScriptu, Pythona, Go i C#. Najważniejsze zmiany według oficjalnego changelogu:

• Bezstanowy rdzeń: znika handshake złożony z initialize i notifications/initialized, a także nagłówek Mcp-Session-Id. Każde żądanie samo przenosi wersję protokołu i capabilities klienta. Jeśli serwer potrzebuje stanu przez kilka wywołań, wydaje własne uchwyty, które wracają jako zwykłe argumenty narzędzi.
• server/discover: każdy serwer musi oferować tę metodę RPC i podawać przez nią wersje protokołu, capabilities oraz swoją tożsamość. Klienci mogą ją wywołać przed pierwszym żądaniem.
• Framework rozszerzeń: klient i serwer negocjują opcjonalne rozszerzenia przez osobne pole w swoich capabilities. Tasks przechodzą z eksperymentalnego rdzenia do oficjalnego rozszerzenia io.modelcontextprotocol/tasks. Znika blokujące tasks/result; wyniki klient pobiera już tylko przez polling za pomocą tasks/get.
• Multi Round-Trip Requests (MRTR): zamiast własnych żądań serwera dla Roots, Sampling czy Elicitation serwer zwraca wynik pośredni ze statusem input_required. Klient powtarza pierwotne żądanie z brakującymi danymi.
• Wycofywane funkcje: Roots, Sampling i Logging zostały oznaczone jako przestarzałe, ale będą działać jeszcze co najmniej dwanaście miesięcy. Dynamic Client Registration oznaczono jako przestarzałe na rzecz Client ID Metadata Documents. Transport HTTP+SSE, zastąpiony już od 2025-03-26, formalnie otrzymuje status Deprecated.

To właściwy skok od protokołu do tool callingu do elementu infrastruktury. Według aktualnej roadmapy maintainerów zdalny serwer MCP nie różni się już od jakiegokolwiek innego workloadu HTTP. Jeśli przenosisz serwer z 2025-11-25 na 2026-07-28, musisz przede wszystkim przebudować logikę sesji i żądania po stronie serwera.

Gdzie MCP jest dziś (stan na październik 2026)

Liczby pokazują, że MCP wyszedł z fazy eksperymentów. Przy przekazaniu projektu Agentic AI Foundation 9 grudnia 2025 r. Anthropic podał ponad 10 000 aktywnych publicznych serwerów MCP i ponad 97 mln pobrań SDK miesięcznie w Pythonie i TypeScripcie.

W praktyce oznacza to, że SAP Joule Studio 2.0 integruje MCP natywnie (serwery MCP dla ABAP, LeanIX, Integration Suite), a Microsoft 365 Copilot, Copilot Studio, Salesforce Agentforce, n8n, LangGraph, Mastra i PydanticAI obsługują MCP. Jeśli w 2026 roku zaczynasz projekt agentowy, będziesz pisać lub wykorzystywać serwery MCP, czy to planujesz, czy nie.

Dla decyzji architektonicznej kluczowe jest rozgraniczenie względem A2A (Agent-to-Agent). MCP to podstawa dla Agent-to-Tool. Można go wprawdzie użyć niezgodnie z przeznaczeniem, by udostępnić agenta jako „serwer” z możliwościami w formie narzędzi, ale nie został do tego zbudowany. Projekt A2A działający w ramach Linux Foundation, do którego członków założycieli należą Google i Microsoft, rozgranicza oba protokoły w swojej dokumentacji tak: MCP łączy agenta z jego narzędziami, A2A łączy agentów ze sobą.

Roadmapa MCP 2026-2027: priorytety i prognoza

Priorytety maintainerów zostały opublikowane, kolejne etapy to prognoza, nie fakt. W roadmapach AI harmonogram jest znacznie mniej pewny niż kierunek.

Roadmapa maintainerów MCP z 9 marca 2026 r. wyznaczała cztery obszary priorytetowe, w tym gotowość enterprise z czterema lukami: ścieżki audytu, uwierzytelnianie zintegrowane z SSO, zachowanie gatewayów i przenośność konfiguracji. Według maintainerów od tamtej pory we wszystkich czterech obszarach nastąpił wyraźny postęp; większość tych zmian trafiła do specyfikacji 2026-07-28. W obszarze gotowości enterprise chodziło przede wszystkim o uwierzytelnianie: Client ID Metadata Documents są teraz preferowaną ścieżką rejestracji, Dynamic Client Registration oznaczono jako przestarzałe, a Enterprise-Managed Authorization jest dostępne jako stabilne rozszerzenie. Na temat ścieżek audytu, zachowania gatewayów i przenośności konfiguracji nowa roadmapa nie podaje stanu prac. Roadmapa z 22 sierpnia 2026 r. wyznacza pięć priorytetów:

• Prymitywy komunikacyjne dla agentów: zdarzenia po stronie serwera przez webhooki i kanały; rozszerzenie Tasks ma dojrzeć na tyle, by można je było włączyć do specyfikacji.
• Jednolity transport HTTP: również lokalne serwery mają w przyszłości obsługiwać Streamable HTTP, przesyłany przez stdio, tak aby pozostał tylko jeden transport.
• Tożsamość agentów i bezpieczeństwo enterprise: standard wiarygodnych tożsamości agentów oparty na DPoP i Workload Identity Federation zamiast na wklejanych kluczach API i długotrwałych tokenach.
• Ulepszone prymitywy: jednolity format wyników narzędzi i stopniowe wykrywanie narzędzi.
• Lepsze SDK: ergonomia, zgodność ze specyfikacją i dokumentacja.

Z tego można wyprowadzić oczekiwany przebieg:

Nasza ocena kolejnych etapów:

• 2027: serwery MCP stają się standardową integracją w przedsiębiorstwach. Rozszerzenia gotowości enterprise (SSO, ścieżki audytu, polityki gatewayów) się stabilizują. Firmy powinny zakładać, że ich duzi dostawcy SaaS będą dostarczać oficjalne zdalne serwery MCP jako domyślny standard przy zakupach.
• 2028: wzorce odpowiadające MCP obejmują AI niebazującą na LLM (widzenie komputerowe, natywna obsługa głosu, robotyka). Architektura „Agentic Mesh” się konsoliduje: MCP dla Agent-to-Tool, A2A lub protokoły następcze dla Agent-to-Agent.

Otwarte problemy: bezpieczeństwo, rejestr, zaufanie

Największym nierozwiązanym problemem jest bezpieczeństwo. Ataki udokumentowane w 2025 roku celują zwykle w tę samą słabość: hosty przekazują modelowi opisy narzędzi bez weryfikacji. Invariant Labs w kwietniu 2025 r. krytykowało, że model bezpieczeństwa MCP zakłada wiarygodne opisy narzędzi. Specyfikacja 2026-07-28 stwierdza, że opisy zachowania narzędzi należy traktować jako niewiarygodne, dopóki nie pochodzą z zaufanego serwera. MCP nie jest w stanie wyegzekwować tego na poziomie protokołu. Dlatego składniowo poprawne opisy łatwo uchodzą za bezpieczne, nawet jeśli zawierają ukryte instrukcje. Najważniejsze wzorce ataków:

• Pośredni prompt injection przez opisy serwerów MCP.
• Tool poisoning: Invariant Labs zademonstrowało to w kwietniu 2025 r. na przykładzie proof of concept z WhatsAppem.
• Server squatting z nazwami look-alike: serwery o łudząco podobnych nazwach.
• Full-schema poisoning (CyberArk): każda część schematu narzędzia jest potencjalnym punktem wstrzyknięcia, także poza opisem.
• GitHub MCP „Toxic Agent Flow”: złośliwe issue na GitHubie nakłania agenta do wycieku danych z prywatnych repozytoriów.

W 2026 roku zabezpieczenie to odpowiedzialność operatora, a nie protokołu: sandboxing, tokeny o ograniczonym zakresie, zasada najmniejszych uprawnień, a przede wszystkim żadnej autonomicznej instalacji serwerów MCP z niezweryfikowanego rejestru. Właśnie tu zaczyna się drugie wyzwanie: rejestr i wykrywanie. Koncerny prowadzą dziś wewnętrzne rejestry serwerów MCP ze ścisłą kontrolą dostępu i umieszczają serwery za OAuth 2.1. Dla wykrywalności ponad granicami dostawców jako prawdopodobna forma rysuje się katalog OASF od AGNTCY, wciąż na liście obserwacyjnej, a nie jako przyjęty standard.

Przykład z praktyki: warstwa narzędzi MCP w koncernie z regionu DACH (Niemcy, Austria, Szwajcaria)

Jak to wygląda w konkretach, pokazuje setup referencyjny dla koncernu z regionu DACH (AI Center of Excellence, 10-30 etatów, hub-and-spoke). Warstwa narzędzi jest tu w całości budowana na MCP, z wewnętrznym rejestrem i obowiązkowym OAuth 2.1. Nasza zalecana kolejność wdrożenia:

1. Ustandaryzować politykę serwerów MCP (rejestr, dostęp, OAuth 2.1).
2. Wprowadzić A2A najpierw w obrębie jednego środowiska (np. tylko Salesforce).
3. Rozszerzyć na drugie środowisko (np. SAP).
4. Opublikować rejestr AgentCard.
5. Tożsamość między dostawcami (AGNTCY) dodać dopiero wtedy, gdy uzasadni to wolumen.

Praktyczny, obowiązkowy krok od pierwszego dnia: przeprowadzić jeden trace ID przez każde zadanie A2A i każde wywołanie MCP. W przeciwnym razie powstają luki audytowe, w których logów jednego środowiska nie da się skorelować z logami innego. Bez tej dyscypliny system wieloagentowy w praktyce nie nadaje się do zbadania w razie zapytania organu nadzorczego. Koszty pierwszego roku platformy zależą przede wszystkim od tego, czy rozbudowuje się setup oparty na jednym dostawcy, czy buduje prawdziwy mesh wielu dostawców z suwerennym hostingiem.

Co to oznacza dla agencji i B2B

Dla agencji i dostawców produktów AI-native MCP jest dźwignią produktyzacji: wspólne repozytorium serwerów MCP dla wszystkich projektów klientów, plus wertykalne serwery na zamówienie (np. serwer do keyword researchu SEO albo wewnętrzny serwer CMS). Kto buduje tu porządnie, sprzedaje integracje zamiast pojedynczych rozwiązań.

Dla decydentów B2B kluczowa jest kwestia zakupowa: czy umowa z Agentforce, Joule lub Copilot Studio gwarantuje zgodność ze standardami MCP i co dzieje się przy wyjściu? MCP jako neutralny wobec dostawców standard pod egidą Linux Foundation to najlepsze dostępne lekarstwo na uzależnienie od platformy, ale tylko wtedy, gdy zarządzanie rejestrem, zabezpieczenie OAuth 2.1 i dyscyplina ścieżek audytu są uwzględnione od samego początku. Jak wdrażamy to w projektach, pokazuje nasza strona o integracji agentów AI w firmach.

Jeśli chcesz śledzić dalszy rozwój roadmapy MCP, wydania specyfikacji i dyskusję o bezpieczeństwie bez samodzielnego researchu co tydzień: nasz newsletter zbiera istotne zmiany wokół agentowej AI dla firm w Europie. Precyzyjnie, bez hype'u, z wyraźnym oddzieleniem faktów od prognoz.