Specyfikacja MCP 2026-07-28: co się zmieniło (sesje, handshake, uchwyty) i jak to migruje Twoje serwery
Damian GębalaAutorSpecyfikacja MCP 2026-07-28 usuwa sesje i handshake: każde żądanie staje się samowystarczalne. Zmiany są duże, ale dotyczą głównie serwerów HTTP, które trzymały stan między wywołaniami - w badaniu 1000 otwartych repozytoriów z serwerami MCP 90,0% w ogóle nie odwoływało się do identyfikatora sesji. Jeśli korzystasz z narzędzi MCP, prawdopodobnie nie musisz robić nic. Jeśli budujesz własne, masz co najmniej dwanaście miesięcy na uporządkowanie stanu.
Model Context Protocol (MCP) to standard, przez który asystent AI podłącza się do Twoich narzędzi i systemów zamiast pisać osobny kod do każdego. Poniżej rozbijam nową wersję specyfikacji na części, które realnie zmieniają pracę Twojego serwera, i wyraźnie oddzielam to, co jest normą, od tego, czego źródła w ogóle nie opisują.
Co dokładnie zmieniła specyfikacja 2026-07-28
Rewizja wyszła 28 lipca 2026, a punktem odniesienia jest wersja 2025-11-25, nie 2025-06-18 - to ważne, bo wiele starszych materiałów porównuje te dwie daty i myli obraz zmian. Wersja kandydacka została zamknięta 21 maja 2026, a utrzymywanie jej przez dziesięć tygodni było oknem na walidację przez ekosystem SDK.
Oficjalny changelog dzieli zmiany na duże i drobne, a nie na „dodane / zmienione / usunięte”, więc kto opiera się na starych schematach porównań, łatwo pominie pozycje. Dużych zmian jest dziewięć. Ich rdzeń: rdzeń protokołu przestaje być dwukierunkowy i stanowy, a staje się zwykłym request/response. Sam zespół MCP nazywa to jedną z najczęściej proszonych rzeczy przez ludzi budujących serwery produkcyjne - powód jest prosty: sesje psują skalowanie.
Kontekst ma znaczenie, bo bez niego łatwo ocenić zmianę jako katastrofę. Protokół ma około półtora roku i od listopada 2024 jest open source, a od grudnia 2025 zarządza nim Agentic AI Foundation pod Linux Foundation. Przy skali, na której działa, nie dało się dołożyć kolejnych dwunastu miesięcy zgodności wstecznej do każdej sesji. Stąd decyzja o czystym cięciu zamiast o kolejnym mechanizmie kompatybilności.
Sesje zniknęły wraz z nagłówkiem Mcp-Session-Id
W wersji 2025-11-25 klient łączący się po Streamable HTTP najpierw musiał założyć sesję, dostać nagłówek Mcp-Session-Id i wysyłać go z każdym kolejnym żądaniem. Efekt: serwer wiedział, z kim rozmawia, ale żądanie przywiązywało się do konkretnej instancji.
Od 2026-07-28 ten nagłówek nie istnieje, a pojęcia sesji nie ma w protokole w żadnej warstwie. Listy narzędzi, zasobów i promptów przestały zależeć od połączenia. Serwer, który potrzebuje pamiętać stan między wywołaniami, dostaje go w postaci uchwytu, który sam wystawia i który klient przekazuje mu z powrotem jako zwykły argument narzędzia.
To zmiana, która porządkuje bałagan, jaki wcześniej deklaratywnie opisuje SEP 2567. W praktyce do sesji przyklejało się pięć różnych rzeczy: wynegocjowane możliwości i wersja protokołu, stan pośredni elicitation i sampling, stan aplikacji (koszyk, sesja przeglądarki Playwright, otwarty deskryptor bazy), zmienne zawartość list oraz subskrypcje zasobów. Po usunięciu sesji trzy z nich znikają razem z nią, a pozostałe muszą dostać inne rozwiązanie.
Praktyczna konsekwencja dla utrzymania usług jest mocna. Zwykły serwer za load balancerem działał w trybie „przypnij klienta do instancji”, więc wdrożenie nowej wersji wymagało sticky routingu albo współdzielonego magazynu sesji. Po zmianie dowolne żądanie może trafić na dowolną instancję, a liczba elementów do utrzymania maleje.
Handshake initialize zniknął, pojawiło się server/discover
Drugą nieodwracalną zmianą jest koniec pary initialize / notifications/initialized. Zamiast jednego wstępnego uścisku dłoni każde żądanie niesie w polu _meta własną wersję protokołu i własne możliwości, a serwer wpisuje swoją tożsamość w _meta wyniku. Klucze są ściśle określone: io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities, io.modelcontextprotocol/clientInfo i io.modelcontextprotocol/serverInfo. Niezgodność wersji zwraca błąd UnsupportedProtocolVersionError.
Żeby klient nie musiał zgadywać, wprowadzono jedną nową metodę: server/discover. Serwer musi ją zaimplementować, a klient może - ale nie musi - wywołać ją przed czymkolwiek innym. Na STDIO służy też jako próba zgodności wstecznej: odpytywujesz nowy serwer, a gdy nie odpowie, spadasz na starą ścieżkę.
To ostatnie zdanie nie jest teorią. Klient OpenAI Agents SDK przy starcie wysyła sondę server/discover w najnowszej wersji protokołu, a jeśli starszy serwer jej nie obsługuje, wraca do handshake initialize i bierze wersję wynegocjowaną tam. Praktyczny wniosek: instalacja nowego SDK nie zmusza Cię do nowego protokołu na każdym połączeniu.
Uchwyty to nie API - i to najczęstsze nieporozumienie
Nagłówek artykułu obiecuje uchwyty, więc warto powiedzieć wprost, czym one nie są. SEP 2567 stwierdza dosłownie, że nie ma metody handles/*, nie ma typu handle w schemacie i nie ma pojęcia uchwytu na poziomie protokołu. Z perspektywy protokołu uchwyt to zwykły string w wyniku narzędzia i zwykły string w jego argumencie, nieodróżnialny od każdej innej danej. To wzorzec projektowania narzędzi, który specyfikacja dokumentuje i zaleca, a nie mechanizm, który implementuje.
W praktyce wygląda to tak: narzędzie create_basket zwraca basket_id o wartości bsk_a1b2c3, a narzędzia add_item oraz checkout przyjmują basket_id jako argument. Taki wzorzec nie jest wymyślany na nowo - obecność w popularnych serwerach jest udokumentowana: Linear z create_issue i numerem zgłoszenia, Notion z tworzeniem stron, GitHub z numerem pull requesta, Stripe z identyfikatorem klienta. Różnica polega na tym, że wcześniej identyfikatorszachowywał transport, a teraz musisz wystawić go sam.
Cena tej decyzji spoczywa po Twojej stronie, bo stan, który trzymała sesja, musi dziś istnieć gdzieś, gdzie przeżyje restart kontenera. W praktyce oznacza to jedno z czterech rozwiązań: uchwyty oparte na zewnętrznym magazynie (Redis, Postgres, magazyn obiektów), żeby każda replika umiała je rozwiązać; zakodowanie wystarczającej informacji w samym uchwycie, żeby przetrwał zgon procesu; ponowne nawiązanie strumieni subskrypcji przez klienta po restarcie; albo przyjęcie, że klient ponowi przerwane żądanie z nowym identyfikatorem zamiast oczekiwać wznowienia strumienia.
Jest jeszcze jedna zmiana, która łamie serwery bazodanowe bez uprzedzenia. Wzorzec, w którym wywołanie connect_database sprawiało, że query i list_tables pojawiały się w kolejnych wynikach tools/list, jest zabroniony: wyniki mogą zmieniać się w czasie, ale nie mogą różnić się per połączenie ani zmieniać w wyniku innych wywołań. Zamiast tego udostępniasz query i list_tables bezwarunkowo, a query przyjmuje argument connection_id zwrócony przez connect_database. Wywołanie bez poprawnego connection_id kończy się błędem wskazującym, żeby model najpierw założył połączenie.
MRTR: jak serwer zadaje pytanie, nie mając sesji
Statelessny protokół musi jakoś zadawać pytania w trakcie obsługi. Odpowiedzią jest wzorzec Multi Round-Trip Requests (MRTR), który zastępuje dotychczasowe żądania inicjowane przez serwer, takie jak roots/list, sampling/createMessage czy elicitation/create.
Mechanizm wygląda następująco: serwer zwraca wynik oznaczony resultType: input_required wraz z polem inputRequests opisującym, czego potrzebuje, oraz polem requestState. Klient zbiera odpowiedzi i ponawia oryginalne wywołanie z wypełnionym inputResponses i przekazanym requestState. Ponieważ wszystko, czego serwer potrzebuje, siedzi w ładunku, wywołanie może podjąć dowolna instancja.
Jedna zmiana w tym mechanizmie jest ważniejsza, niż się wydaje, i nie widać jej w skrótach: żądania inicjowane przez serwer mogą być wysyłane wyłącznie wtedy, gdy serwer aktywnie obsługuje żądanie klienta. Wcześniej to było zalecenie, teraz jest wymogiem. Użytkownik nigdy nie dostanie pytania z zewłucza - każde elicitation da się powiązać z czymś, co on albo jego agent sam uruchomił.
Do tego każdy wynik niesie teraz obowiązkowe pole resultType: complete dla zwykłych wyników albo input_required dla wyników pośrednich MRTR. Klienci muszą traktować wyniki ze starszych serwerów, które tego pola nie zawierają, jako complete. To jedyna jawna reguła kompatybilności wstecznej w całym changelogu dotycząca wyników.
Nagłówki, load balancer i cache
Ruch po serwerach opiera się teraz na nagłówkach HTTP. Na każdym POST do transportu Streamable HTTP wymagane są nagłówki Mcp-Method i Mcp-Name, a serwer odrzuca żądania, w których nagłówki nie zgadzają się z treścią. Do tego dochodzi obsługa własnych nagłówków z parametrów narzędzia przez x-mcp-header.
Tu jest pierwsza poważna rozbieżność między źródłami, i warto ją znać, zanim napiszesz test. Oficjalny changelog czytelnie wymaga obu nagłówków na żądaniach POST Streamable HTTP, bez wyjątku per metoda. Przewodnik konfiguracyjny firmy AgentCat podaje węższy zakres: nagłówki MCP-Protocol-Version i Mcp-Method na każdym POST, a Mcp-Name tylko na tools/call, resources/read i prompts/get, gdzie odzwierciedla params.name albo params.uri. Changelog jest normatywny, ale nie rozstrzyga tej kwestii wprost - jeśli piszesz gateway, przetestuj oba warianty na swoim SDK.
Praktyczny efekt jest taki, że load balancer, gateway i limiter mogą podejmować decyzje bez rozbierania ciała żądania. Metoda i nazwa narzędzia są w nagłówkach, więc autoryzacja per narzędzie nie musi już parsować JSON-a.
Drugi mechanizm dotyczy list. Wyniki z tools/list, prompts/list, resources/list, resources/read i resources/templates/list muszą nieść pola ttlMs i cacheScope przez nowy interfejs CacheableResult. ttlMs to podpowiedź o świeżości w milisekundach, cacheScope przyjmuje public albo private i decyduje, czy pośrednik może współdzielić odpowiedź między użytkowników. Do tego specyfikacja zaleca deterministyczną kolejność narzędzi w tools/list, żeby klient mógł cache'ować katalog i nie rozsypywać cache'a promptów w modelu.
Ostrzeżenie: klient OpenAI Agents SDK nadal udostępnia własne cache_tools_list z ręcznym invalidate_tools_cache i w dokumentacji nie ma wzmianki o respektowaniu ttlMs. Nie zakładaj, że Twoja biblioteka klienta wdrożyła nowe pola, bo serwer je wysyła.
Co dokładnie usunięto
Poniżej lista z changelogu, bez dopisywania niczego, czego źródła nie wymieniają. Czterna pozycje na końcu to nie twarde usunięcia, tylko zmiana sposobu działania.
| Element | Co się stało |
|---|---|
| Mcp-Session-Id i sesja protokołu | usunięte, stan przeniesiony na uchwyty |
| initialize i notifications/initialized | usunięte, zastąpione przez _meta i server/discover |
| Endpoint HTTP GET | usunięty, zastąpiony przez subscriptions/listen |
| resources/subscribe i resources/unsubscribe | usunięte, zastąpione przez subscriptions/listen z czterema typami: toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions |
| ping | usunięty |
| logging/setLevel | usunięty, poziom logowania idzie per żądanie w io.modelcontextprotocol/logLevel |
| notifications/roots/list_changed | usunięty |
| tasks/result | usunięty na rzecz odpytywania tasks/get oraz nowego tasks/update |
| tasks/list | usunięty, bo nie da się go bezpiecznie zakresować bez sesji |
| Last-Event-ID i identyfikatory zdarzeń SSE | usunięte, przerwany strumień gubi żądanie w toku |
| notifications/elicitation/complete | usunięty, wprowadzony w 2025-11-25 |
| elicitationId w żądaniach trybu URL | usunięty, korelację kodujesz we własnym requestState |
| Kody błędów -32002 na brak zasobu | zmieniony na -32602 Invalid Params; trzy kolejne kody przenumerowane na -32020, -32021 i -32022 |
| Serwery inicjujące żądania jako osobny mechanizm | zastąpione przez MRTR; obecnie tylko w trakcie obsługi żądania klienta |
Zniknęły też subskrypcje zasobów, ale same zasoby zostały. To częste nieporozumienie, bo nazwy są zbyt podobne. Zniknęło też wznawianie strumienia SSE i ponowne dostarczanie wiadomości: przerwany strumień odpowiedzi gubi żądanie w locie, a klient musi wysłać je ponownie jako nowe żądanie z nowym identyfikatorem.
Co jest zdeprecjonowane i ile masz czasu
Specyfikacja przyjęła politykę cyklu życia funkcji z trzema stanami - aktywna, zdeprecjonowana, usunięta - oraz minimalnym dwunastomiesięcznym oknem między deprecacją a najwcześniejszym usunięciem. W praktyce to oznacza, że funkcje oznaczone jako zdeprecjonowane działają i będą działać we wszystkich wersjach specyfikacji opublikowanych w ciągu roku od tej rewizji, a samo usunięcie wymaga osobnego SEP-u.
| Zdeprecjonowane | Zastępnik wskazany w specyfikacji |
|---|---|
| Roots | przekazywanie katalogów i plików przez parametry narzędzi, identyfikatory URI zasobów lub konfigurację serwera |
| Sampling | integracja bezpośrednio z API dostawcy modelu |
| Logging | logowanie na stderr dla stdio albo OpenTelemetry |
| Transport HTTP+SSE | Streamable HTTP; faktycznie zdeprecjonowany już w wersji 2025-03-26, w 2026-07-28 trafił do formalnego stanu Deprecated |
| Wartości includeContext: thisServer i allServers | pominięcie pola albo wartość none; usunięte najpóźniej razem z funkcją Sampling |
| Dynamic Client Registration (RFC 7591) | Client ID Metadata Documents; DCR zostaje dla zgodności wstecznej, ale bez podanego terminu usunięcia |
Jedno ostrzeżenie interpretacyjne: to deprecacje adnotacyjne, więc w kodzie nie musisz nic przepisywać. Jednocześnie changelog mówi wprost, że nowe implementacje nie powinny dodawać obsługi tych funkcji. Praktyczna zasada: nie burz niczego, czego nie musisz, ale nie opieraj nowego kodu na Roots, Sampling ani Logging.
Po stronie bezpieczeństwa doszedł walidacja parametru iss z RFC 9207 przed wykupieniem kodu autoryzacji, wiązanie poświadczeń klienta z identyfikatorem wydawcy, wymagane application_type przy rejestracji dynamicznej oraz udokumentowane propagowanie kontekstu OpenTelemetry przez _meta (klucze traceparent, tracestate, baggage).
Jak wygląda migracja Twojego serwera
Oficjalny changelog nie zawiera sekcji migracji ani instrukcji krok po kroku, a wpis blogowy zapowiada notatki migracyjne, ale ich treści tam nie ma. Najuczciwsze, co da się zrobić, to oprzeć się na danych z SEP 2567 i na praktycznych opisach konfiguracji transportów. Jeśli dopiero zaczynasz i nie masz pewności, czy w ogóle potrzebujesz serwera MCP, porównaj to z samym tool callingiem. Jeśli zdecydujesz się na własny serwer, minimalny przykład w Pythonie pokaże, gdzie dokładnie podpinasz te wszystkie nagłówki.
Badanie automatyczne na losowej próbce 1000 otwartych repozytoriów z serwerami MCP, sklasyfikowanych przez analizę per repo, daje taki obraz:
| Kategoria użycia sesji | Udział | Migracja |
|---|---|---|
| Brak odwołań na poziomie aplikacji do identyfikatora sesji | 90,0% | brak |
| Mapowanie sessionId na transport (boilerplate TypeScript SDK) | 3,5% | znika razem z transportem sessionless |
| Tylko konfiguracja transportu (sessionIdGenerator nigdy nieczytany) | 2,8% | usunięcie jednej opcji konstruktora |
| Stan aplikacji kluczowany sesją | 2,5% | migracja na uchwyty lub na tożsamość uwierzytelnioną |
| Sticky routing w proxy lub gatewayu | 0,7% | wymaga zaprojektowanego zamiennika |
| Wiązanie autoryzacji (claims JWT, weryfikator PKCE kluczowany sesją) | 0,5% | nonce generowane przez serwer lub podmiot tokenu |
To odpowiada na pytanie, które zadaje każdy: czy muszę panikować. Nie, chyba że prowadzisz gateway lub trzymasz stan aplikacji kluczowany sesją. Suma kolumn to 100,0%, więc tabela zamyka całą próbkę.
Trzy ścieżki migracji opisuje SEP 2567. Serwery stdio używające stanu na czas procesu mechanicznie nie psują się w domyślnym wdrożeniu, bo proces nadal istnieje i serwer z jedną instancją przeglądarki w pamięci wciąż działa z klientem stdio, który uruchamia jeden proces - ale nie powinny polegać na stanie procesu i powinny przejść na uchwyty. Te nigdy nie miały nagłówka Mcp-Session-Id, więc samo jego usunięcie ich nie dotyczy. Serwery HTTP używające Mcp-Session-Id muszą przejść na uchwyty, a migracja jest dosłownie mechaniczna: zamień mapę stanu kluczowaną sesją na mapę kluczowaną uchwytem, dodaj narzędzie create_* i dodaj uchwyt jako parametr do narzędzi stanowych. Serwery używające identyfikatora sesji jako klucza telemetrii muszą przejść na inny mechanizm zakresowania, najczęściej na podmiot uwierzytelniony (subject tokenu lub klucz API) albo na identyfikator korelacji z poziomu żądania.
Są też dwie zmiany, o których mówi się rzadko, a które potrafią zatrzymać wdrożenie. Po pierwsze, Tasks wyszły z rdzenia protokołu do oficjalnego rozszerzenia io.modelcontextprotocol/tasks: cykl życia przebudowano wokół modelu bezstanowego, serwer może odpowiedzieć na tools/call uchwytem zadania, a klient prowadzi je przez tasks/get, tasks/update i tasks/cancel, a tworzenie zadania jest decyzją serwera, nie klienta. Blokujące tasks/result i tasks/list zniknęły, a każdy, kto budował na eksperymentalnym API Tasks z 2025-11-25, musi przepisać integrację. To jedyne wezwanie do migracji, jakie pada w oficjalnym blogu. Po drugie, deklaracja, że SDK Tier 1 mówią 2026-07-28, nie znaczy, że każdy domyślnie przyjmuje ten ruch. Przykładowo SDK Go przyjmuje ruch 2026-07-28 dopiero po ustawieniu StreamableHTTPOptions.Stateless na true, a bez tego negocjuje każde połączenie w dół do sesji 2025-11-25. Sprawdź własne SDK, zanim założysz, że dual-era działa bez konfiguracji.
Bezpieczeństwo uchwytów i granica zaufania
Uchwyty przenoszą na bark aplikacji coś, czego wcześniej transport pilnował za Ciebie. Ryzyko jest nazwane wprost: przejęcie stanu przez uchwyt. Atak albo pomyłka, gdy wycieknie identyfikator, a serwer używa go jako tokenu posiadania, odsłania stan innego użytkownika. Obrona to uchwyty losowe, z ograniczonym czasem życia, powiązane po stronie serwera z uwierzytelnionym użytkownikiem, z weryfikacją każdego żądania niezależnie od uchwytu.
SEP 2567 podaje konkretne progi: co najmniej 128 bitów entropii z kryptograficznie bezpiecznego źródła, przykładowo UUIDv4 albo co najmniej 22 znaki baz64 bezpiecznego dla URL, nigdy z przewidywalnych danych wejściowych, z ograniczonym czasem życia. Dodaje też regułę, którą warto przestrzegać nawet bez sesji: uchwyt ma być nieprzezroczysty. Taki, który koduje strukturę wewnętrzną (koszyk_użytkownik42_2026-03-11), zaprasza klienta do parsowania i model do zgadywania; bsk_a1b2c3 nie.
Trzy rzeczy decydują o jakości uchwytów w praktyce. Polityka trwałości musi być w opisie narzędzia, nie w dokumentacji serwera, bo opis jest widoczny dla modelu w chwili, gdy podejmuje decyzję o utworzeniu stanu. Wygasły uchwyt powinien zwracać czytelny błąd („koszyk bsk_a1b2c3 wygasł”), a nie ogólne „nieprawidłowy argument”, bo czytelny błąd pozwala modelowi wywołać create_* ponownie, a mglisty prowadzi do pętli. I tworzenie powinno przyjmować parametry: create_context(cluster=staging) zamiast create_context() plus późniejszego ustawienia, bo to jedna runda zamiast dwóch i stan nie istnieje w wersji półskonfigurowanej.
Po stronie klienta obowiązek jest jeden i łatwo go przeoczyć: uchwyt to zwykły string, który musi przetrwać kompakcję kontekstu. Jeśli rozmowa zostanie podsumowana, a uchwyt wyląduje w części wyrzuconej, stan zostaje osierocony.
Warto przy okazji spojrzeć na stan faktyczny, nie tylko na specyfikację. Uchwyt ląduje w promptach subagentów i logach rozmów, więc traktuj go jak dane wrażliwe, a nie jak techniczny identyfikator, który nikogo nie obchodzi. Osobno, analiza serwerów MCP wystawionych w internecie z lipca 2026 od Wiz Research wykazała, że około 70% z nich zwracało pełny katalog narzędzi anonimowym wywołującym. W maju 2026 amerykańskie NSA opublikowało wytyczne bezpieczeństwa projektowego dla MCP, a w kwietniu 2026 OX Security zaraportował wstrzykiwanie poleceń przez pliki konfiguracyjne MCP w kilku środowiskach IDE z AI. Jeśli zlecasz komuś budowę serwera MCP, audyt autoryzacji jest rozdziałem, o który pytasz przed startem, a nie po wydaniu - tak jak przy checkliście bezpieczeństwa przed włączeniem AI w zespole i przy RODO i AI Act w firmie.
Czego specyfikacja nie mówi
Warto wymienić braki, bo na ich podstawie łatwo napisać artykuł zmyślający liczby. Po pierwsze, nie ma oficjalnej instrukcji migracji krok po kroku ani diffu kodu dla serwera HTTP używającego Mcp-Session-Id poza trzema zdaniami w SEP 2567. Nie ma tabeli z numerami wersji SDK, które obsługują 2026-07-28 dla TypeScript, Pythona, Go i C#. Nie ma harmonogramu przejęcia tej wersji przez konkretne klienty ani deklaracji o kosztach migracji i nakładzie pracy.
Spośród prezentowanych materiałów dwa są przycięte przy zapisie, przez co brakuje w nich pełnej sekcji o bezpieczeństwie uchwytów i referencyjnej implementacji w SEP 2567. Sama strona spisu specyfikacji zawiera jeszcze treści sprzed 28 lipca 2026, między innymi mówi o negocjacji rozszerzeń w trakcie inicjalizacji, choć inicjalizacja już nie istnieje. Dla porównania z poprzednią wersją masz pod ręką changelog 2025-06-18, ale to punkt historyczny - zmiany mierzone są względem 2025-11-25, którego changelogu w zestawie nie ma.
To wszystko oznacza jedno dla decyzji: przed wdrożeniem sprawdź rejestr zdeprecjonowanych funkcji i notatki migracyjne Twojego SDK, bo to jedyne dwa miejsca, w których naprawdę są odpowiedzi.
Co zrobić, zanim Twój serwer ruszy na produkcji
Prosta checklista, zbudowana na MUST i SHOULD z changelogu:
- Zaimplementuj server/discover i sprawdź, że klient potrafi na nim polegać zamiast na ręcznym handshake.
- Przestań wysyłać Mcp-Session-Id i usuń obsługę Last-Event-ID, jeśli jeszcze ją masz.
- Upewnij się, że tools/list zwraca ten sam zestaw niezależnie od połączenia i że kolejność jest deterministyczna.
- Dodaj ttlMs i cacheScope do wszystkich pięciu rodzajów wyników list i odczytu zasobu.
- Wysyłaj Mcp-Method i Mcp-Name oraz pilnuj, żeby zgadzały się z ciałem żądania.
- Przenieś stan aplikacji z klucza sesji na uchwyt, a uchwyt oprzyj na zewnętrznym magazynie.
- Zaktualizuj kod, który dopasowuje się do błędu -32002 na -32602.
- Przetestuj starą wersję klienta na tym samym serwerze - to jedyny test, który mówi coś o zgodności wstecznej.
Jeśli utrzymujesz serwer MCP i myślisz, co z tym zrobić, napisz do mnie - odpowiadam zwykle tego samego dnia. Odpowiem konkretnie, które z tych ośmiu punktów dotyczy Twojego przypadku, a które są do pominięcia przy stdio i jednym procesie.