MCP 2026-07-28 Przewodnik migracji: Serwery bezstanowe

TL;DR: MCP 2026-07-28 usuwa sesje na poziomie protokołu oraz obowiązkowy handshake inicjalizacyjny. Zespoły produkcyjne powinny wykryć ukryte zależności od sesji, przyjąć metadane protokołu per żądanie, wdrożyć Multi Round-Trip Requests, zaktualizować polityki bram/gatewayów i przeprowadzić kanarkowe wdrożenie nowego protokołu przed wycofaniem zachowań legacy.

Specyfikacja Model Context Protocol wydana 28 lipca 2026 wprowadza największą zmianę architektury MCP od czasu dodania wsparcia dla zdalnego transportu.

Protokół korzysta teraz z bezstanowego rdzenia request–response. Wymiana initialize i notifications/initialized została usunięta, Mcp-Session-Id zniknęło, a każde żądanie niesie informacje protokołowe potrzebne do jego przetworzenia.

Wydanie wprowadza także Multi Round-Trip Requests, nagłówki routingu HTTP, keszowalne odpowiedzi list, ostrzejsze zachowanie autoryzacji, framework rozszerzeń oraz formalny cykl wycofywania. Zobacz oficjalny komunikat o wydaniu MCP 2026-07-28 oraz pełny changelog specyfikacji po szczegóły na poziomie protokołu.

Zmiany ułatwiają skalowanie zdalnych serwerów MCP za standardową infrastrukturą HTTP. Nie czynią jednak istniejącej aplikacji automatycznie bezstanową.

Serwer produkcyjny może nadal polegać na pamięciowych workspace’ach, lepkim routingu, poświadczeniach powiązanych z sesją, długo żyjących strumieniach lub interakcjach inicjowanych przez serwer. Ten poradnik koncentruje się na wykrywaniu i zastępowaniu tych zależności.

Bardziej wprowadzające omówienie implementacji znajdziesz w How to Create an MCP Server for Claude Code przed rozpoczęciem migracji.

Kto musi migrować?

Poziom wysiłku zależy od sposobu użycia MCP w Twoim systemie.

Lokalny serwer, który nie zachowuje stanu między żądaniami, może wymagać jedynie aktualizacji SDK i testów kompatybilności.

Zdalne wdrożenie używające sesji, OAuth, streamingu lub żądań inicjowanych przez serwer wymaga etapowej migracji.

Co się zmieniło w MCP 2026-07-28?

1. Audyt istniejącej implementacji

Przed aktualizacją przeszukaj klienta, serwer, gateway oraz konfigurację wdrożenia pod kątem starszych założeń protokołu.

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

Następnie odpowiedz na następujące pytania:

1. Czy serwer odrzuca wywołania, dopóki inicjalizacja nie zostanie ukończona?
2. Czy ID sesji wybiera użytkownika, poświadczenie, workspace lub konwersację?
3. Czy inna instancja serwera może kontynuować workflow rozpoczęty przez pierwszą?
4. Czy load balancer wymaga przypinania sesji?
5. Czy narzędzie wykonuje efekt uboczny przed uzyskaniem potwierdzenia?
6. Czy gateway parsuje ciało, aby zidentyfikować metodę lub narzędzie?
7. Czy poświadczenia OAuth są przechowywane bez ich serwera autoryzacji (issuer)?
8. Czy klient polega na wznawianiu SSE lub ponownym doręczeniu wiadomości?
9. Czy listy narzędzi lub zasobów różnią się w zależności od połączenia?
10. Które funkcje zdeprecjonowane wciąż otrzymują ruch produkcyjny?

Nie usuwaj Mcp-Session-Id, dopóki nie zrozumiesz, co aplikacja przechowuje pod nim.

Serwer, który usunie nagłówek, ale zachowa stan w pamięci lokalnej, może działać podczas developmentu i okresowo zawodzić, gdy żądania zostaną rozproszone na wiele instancji.

2. Zastąp ukryty stan sesji

MCP 2026-07-28 usuwa sesje na poziomie protokołu, nie stan aplikacji.

Stan potrzebny między wywołaniami powinien korzystać z jednego z trzech wzorców.

Jawne uchwyty (Explicit Handles)

Zwróć przez narzędzie uchwyt nadany przez serwer i wymagaj go w kolejnych wywołaniach.

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Workspace created."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

Późniejsze żądanie przekazuje uchwyt jako zwykły argument:

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

Dzięki temu zależność jest widoczna w kontrakcie narzędzia i dowolna zgodna instancja serwera może przetworzyć żądanie.

Współdzielony magazyn (Shared Storage)

Użyj bazy danych, rozproszonego cache, object store lub trwałego systemu zadań, gdy:

• wielu workerów potrzebuje tego samego stanu;
• workflow musi przetrwać restart;
• stan jest zbyt duży dla uchwytu;
• workflow trwa dłużej niż pojedyncze żądanie;
• wymagana jest transakcyjność lub jednokrotne użycie.

Chronione requestState

MRTR może zwrócić nieprzezroczystą wartość requestState, którą klient odzwierciedla przy ponowieniu oryginalnego żądania.

Ponieważ wartość przechodzi przez klienta, chroń ją za pomocą HMAC lub uwierzytelnionego szyfrowania. Zwiąż ją z uwierzytelnionym podmiotem, oryginalną operacją, ważnymi parametrami, czasem wygaśnięcia oraz nonce, gdy wymagana jest ochrona przed replay.

Nigdy nie ufaj niepodpisanej wartości requestState tylko dlatego, że klient zwrócił ją bez zmian.

3. Przyjmij samowystarczalne żądania i discovery

Nowoczesne żądania MCP zawierają kontekst protokołu w _meta.

Wywołanie narzędzia w Streamable HTTP może wyglądać tak:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "stateless MCP migration"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

Serwery celujące w nowy protokół muszą zaimplementować server/discover, który ogłasza wspierane wersje, możliwości i tożsamość serwera. Klienci mogą wywołać go przed inną operacją lub użyć do określenia, czy wymagana jest ścieżka legacy.

Przeczytaj oficjalną dokumentację server/discover po kontrakt odpowiedzi.

Negocjacja wersji w TypeScript SDK

Sama aktualizacja TypeScript SDK nie przełącza automatycznie klienta na nowy protokół.

Klient używający SDK v2 musi wyraźnie włączyć:

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

W trybie automatycznym SDK sondą wywołuje server/discover i może powrócić do starszego przepływu inicjalizacji, gdy trafi na serwer legacy.

Zespoły wciąż używające @modelcontextprotocol/sdk v1 powinny najpierw postępować według oficjalnego przewodnika migracji TypeScript SDK z v1 do v2. Zespoły już korzystające z v2 powinny użyć osobnego przewodnika wsparcia protokołu 2026-07-28.

4. Zastąp żądania inicjowane przez serwer mechanizmem MRTR

Poprzednie implementacje MCP mogły wysyłać żądania takie jak elicitation/create, sampling/createMessage lub roots/list z serwera do klienta.

Nowy protokół zastępuje ten model Multi Round-Trip Requests.

Przepływ:

1. Klient wysyła oryginalne żądanie.
2. Serwer zwraca resultType: "input_required".
3. Klient zbiera żądane informacje lub zgodę.
4. Klient ponawia oryginalną operację z nowym ID JSON-RPC.
5. Ponowienie zawiera inputResponses i oryginalne requestState.
6. Serwer kończy żądanie lub zaczyna kolejną rundę.

Przykładowa odpowiedź:

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Delete project project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Klient ponawia oryginalną operację:

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Produkcja MRTR powinna zdefiniować:

• maksymalną liczbę rund;
• wygaśnięcie request-state;
• zachowanie anulowania i odrzucenia;
• walidację schematu odpowiedzi;
• kontrole autoryzacji przy każdym ponowieniu;
• ochronę przed replay;
• idempotencję dla efektów ubocznych;
• zachowanie, gdy klient nie wspiera wymaganej możliwości.

Unikaj finalizowania zakupu, usunięcia, obciążenia kredytów lub zewnętrznego zapisu przed zwróceniem input_required.

Użyj operacji etapowanej lub klucza idempotency, aby ponowienia nie duplikowały działania. Zobacz oficjalną specyfikację MRTR po pełny model interakcji.

5. Zaktualizuj bramy/gatewaye, keszowanie i autoryzację

Zmiany infrastrukturalne są ściśle powiązane i powinny być testowane razem.

Waliduj nagłówki routingu MCP

Żądania POST Streamable HTTP zawierają teraz:

• MCP-Protocol-Version
• Mcp-Method
• Mcp-Name

Te nagłówki pozwalają bramom routować, taryfikować, autoryzować i limitować ruch bez parsowania każdego ciała JSON.

Mogą wspierać kontrole takie jak:

• ograniczenia rate limit specyficzne dla narzędzia;
• odrębne polityki dla metod listujących i wykonawczych;
• dedykowane pule workerów dla kosztownych narzędzi;
• ograniczony dostęp do operacji wysokiego ryzyka;
• metryki opóźnień i błędów per narzędzie;
• przypisywanie kosztów infrastruktury.

Wartości nadal dostarcza klient. Porównuj je z ciałem JSON-RPC przed zastosowaniem polityki.

Żądanie nie może zadeklarować niskiego ryzyka narzędzia w Mcp-Name, a wywołać inne narzędzie w ciele. Niezgodności nagłówek–ciało powinny być odrzucane i logowane.

Używaj kluczy cache świadomych autoryzacji

Nowy protokół dodaje ttlMs i cacheScope do wyników możliwych do keszowania, w tym:

• tools/list
• prompts/list
• resources/list
• resources/templates/list
• resources/read

Klucz cache zwykle powinien obejmować:

protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version

Nie używaj prywatnego wpisu cache między użytkownikami lub tenantami tylko dlatego, że TTL nie wygasł.

Deterministyczne sortowanie narzędzi również ma znaczenie. Stabilny katalog unika niepotrzebnych chybionych trafień cache i może poprawić ponowne użycie cache promptu modelu, gdy definicje narzędzi są wstawiane do promptów.

Wzmocnij obsługę issuerów OAuth

Podczas migracji autoryzacji:

• waliduj zwróconą wartość iss względem issuer’a zarejestrowanego dla przepływu;
• indeksuj przechowywane poświadczenia klienta według issuer’a;
• nigdy nie używaj poświadczeń z innym serwerem autoryzacji;
• ustaw odpowiedni application_type podczas DCR;
• przygotuj nowe integracje na Client ID Metadata Documents.

Dynamic Client Registration pozostaje dostępne dla wstecznej kompatybilności, ale jest deprecated jako preferowane podejście rejestracyjne.

6. Migruj powiadomienia, zadania i funkcje deprecated

Starsza ścieżka powiadomień HTTP GET oraz przepływ resources/subscribe lub resources/unsubscribe zostały zastąpione przez subscriptions/listen.

Klienci otwierają długo żyjący strumień odpowiedzi POST i zapisują się na potrzebne kategorie powiadomień. Powiadomienia o postępie i logi specyficzne dla żądania pozostają dołączone do strumienia odpowiedzi dla opisywanego żądania.

Dla wdrożeń wieloinstancyjnych użyj współdzielonej szyny zdarzeń, gdy powiadomienia wygenerowane na jednej instancji muszą dotrzeć do subskrypcji podłączonej do innej.

Rozszerzenie Tasks

Długo trwające prace zostały przeniesione z eksperymentalnego core protokołu do:

io.modelcontextprotocol/tasks

Rozszerzenie używa:

• tasks/get do odpytywania;
• tasks/update do aktualizacji od klienta do serwera;
• trwałych uchwytów zadań;
• subscriptions/listen do subskrybowanych aktualizacji.

Starszych wzorców tasks/result i tasks/list nie należy przenosić do nowej implementacji.

Funkcje deprecated

Następujące funkcje są deprecated:

Funkcjonalność deprecated pozostaje dostępna w oknie wycofywania, ale nowe implementacje nie powinny jej adoptować. Polityka cyklu życia MCP zapewnia minimalnie 12 miesięcy okresu deprecjacji; nie oznacza to, że każda funkcja ma tę samą potwierdzoną datę usunięcia.

Przejrzyj oficjalny rejestr funkcji deprecated przed ustaleniem terminu wycofania.

7. Wdrażaj migrację bezpiecznie

Nie zmieniaj klientów, serwerów, bram, keszowania i autoryzacji w jednym, nieobserwowanym wydaniu.

Zalecana kolejność migracji

1. Sporządź inwentaryzację wersji protokołu, SDK, sesji, ruchu SSE, klientów DCR i metod deprecated.
2. Zaktualizuj SDK w środowiskach nieprodukcyjnych.
3. Dodaj server/discover i negocjację wersji.
4. Zastąp ukryte zależności sesji.
5. Zaimplementuj i zabezpiecz MRTR.
6. Dodaj walidowane nagłówki routingu i kesze o zasięgu.
7. Przetestuj granice issuerów w autoryzacji.
8. Wdrażaj kanarkowo nowy protokół obok ścieżki legacy.
9. Wycofuj starsze zachowanie dopiero po przeglądzie telemetryki.

Kompatybilność podczas kanarkowego wdrożenia

Modern client + modern server
→ Use MCP 2026-07-28

Modern client + legacy server
→ Probe and fall back when supported

Legacy client + dual-version server
→ Continue on the legacy path

Unsupported combination
→ Return a clear protocol-version error

Wydanie nowej specyfikacji MCP nie jest przełącznikiem dla całego ekosystemu. Klienci, serwery, SDK i platformy hostowane będą migrować w różnym tempie.

Telemetria do rejestrowania

Udane jednorazowe wywołania tools/call nie wystarczą do pomiaru migracji. Workflow, który wielokrotnie przekracza czas, prosi o niepotrzebne dane lub duplikuje zewnętrzny zapis, nadal jest porażką produkcyjną.

Jak CometAPI wpisuje się w architekturę MCP

MCP nie zastępuje API modelu. Te dwie warstwy rozwiązują różne problemy integracyjne.

Typowa architektura produkcyjna wygląda tak:

Application or agent
        ↓
MCP clients and servers
Tools, resources, approvals, tasks
        ↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models

MCP standaryzuje sposób, w jaki agenci wchodzą w interakcję z narzędziami i kontekstem. Nie standaryzuje cen modeli, poświadczeń dostawców, endpointów inferencji ani failoveru dostawców.

To rozdzielenie staje się szczególnie użyteczne przy migracji z deprecjonowanej możliwości Sampling. Jeśli serwer MCP lub agent, który go konsumuje, nadal potrzebuje inferencji modelu, aplikacja może wywołać API modelu bezpośrednio zamiast polegać na dawnym przepływie MCP Sampling.

Kiedy pomaga ujednolicona brama modeli

Ujednolicona brama modeli może zmniejszyć prace operacyjne, gdy:

• kilka serwerów MCP potrzebuje dostępu do różnych dostawców modeli;
• różne narzędzia wymagają różnych modeli;
• zespoły chcą zmieniać modele bez przepisywania integracji specyficznych dla dostawcy;
• poświadczenia, użycie i rozliczanie muszą być zarządzane centralnie;
• dostęp do modeli powinien pozostać niezależny od zmian transportu MCP.

CometAPI dostarcza endpoint kompatybilny z OpenAI, który może służyć jako warstwa dostępu do modeli za aplikacjami MCP. Utrzymuje to logikę dostawców modeli oddzielnie od narzędzi MCP, zasobów i orkiestracji zadań.

Na przykład narzędzie MCP może wywoływać model przez ten sam kompatybilny z OpenAI klient używany w innych miejscach aplikacji:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Summarize the supplied resource clearly and concisely."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

Serwer MCP pozostaje odpowiedzialny za kontrakt narzędzia, autoryzację, stan i obsługę wyników. Brama modeli obsługuje wybór modeli, dostęp do dostawców i odpowiedzi inferencji.

Utrzymanie tych warstw oddzielnie daje dwie praktyczne korzyści:

1. Klienci i serwery MCP mogą migrować do nowego protokołu bez zmiany warstwy integracji modeli.
2. Dostawców modeli można zmieniać bez przeprojektowywania narzędzi MCP lub zachowania transportu.

Więcej szczegółów implementacyjnych: CometAPI Quickstart, dokumentacja API oraz przewodnik po aplikacjach multi-model AI.

Lista kontrolna migracji MCP 2026-07-28

Klient

• Zaktualizuj do kompatybilnego SDK.
• Włącz nowoczesną negocjację wersji.
• Wspieraj server/discover.
• Dołączaj metadane protokołu do każdego żądania.
• Obsługuj resultType.
• Wspieraj lub wyraźnie odrzuć MRTR.
• Używaj nowego ID JSON-RPC dla ponowień.
• Zachowuj i zwracaj requestState.
• Waliduj issuerów OAuth.
• Przechowuj poświadczenia według issuer’a.
• Respektuj wskazówki cache.
• Wspieraj subscriptions/listen, gdy potrzebne.

Serwer

• Usuń bramki inicjalizacji dla modern-request.
• Usuń zależności od Mcp-Session-Id.
• Zaimplementuj server/discover.
• Zastąp ukryty stan uchwytami lub współdzielonym magazynem.
• Zwracaj resultType.
• Zastąp żądania serwer→klient mechanizmem MRTR.
• Chroń requestState.
• Waliduj wszystkie inputResponses.
• Dodaj idempotencję dla efektów ubocznych.
• Zwracaj deterministyczne listy.
• Publikuj konserwatywne wskazówki cache.
• Migruj długo trwające prace do rozszerzenia Tasks.

Gateway i infrastruktura

• Waliduj nagłówki żądań MCP.
• Porównuj nagłówki z ciałem żądania.
• Usuń niepotrzebny lepki routing.
• Testuj żądania na wielu instancjach.
• Partycjonuj cache według granic autoryzacji.
• Dodaj współdzieloną szynę powiadomień, gdy wymagane.
• Śledź ruch legacy i deprecated.
• Utrzymuj ścieżkę rollback podczas kanarkowania.

FAQ

Czym jest MCP 2026-07-28?

MCP 2026-07-28 to specyfikacja Model Context Protocol wydana 28 lipca 2026. Wprowadza bezstanowy rdzeń protokołu, Multi Round-Trip Requests, nagłówki routingu HTTP, keszowalne wyniki, zmiany w autoryzacji, rozszerzenia i formalny cykl wycofywania.

Czy Mcp-Session-Id zostało usunięte?

Tak. Nowy protokół Streamable HTTP nie używa Mcp-Session-Id.

Aplikacje nadal mogą zachowywać stan poprzez jawne uchwyty, współdzielony magazyn, trwałe zadania lub chronione wartości request-state.

Czy handshake inicjalizacji MCP został usunięty?

Tak. Nowoczesne żądania nie wymagają wymiany initialize i notifications/initialized.

Serwery muszą zaimplementować server/discover, choć klienci nie muszą go wywoływać przed każdą operacją.

Czy bezstanowy MCP oznacza, że narzędzia nie mogą zachować stanu?

Nie. Bezstanowość dotyczy warstwy protokołu.

Narzędzie może nadal przechowywać stan, ale przetwarzanie żądań nie powinno zależeć od ukrytej zależności transportu lub jednego konkretnego procesu serwera.

Czym jest MRTR?

Multi Round-Trip Requests pozwala serwerowi poprosić o dodatkowe dane od klienta lub użytkownika bez wysyłania żądania inicjowanego przez serwer przez ciągle otwarte, dwukierunkowe połączenie.

Serwer zwraca input_required, a klient ponawia oryginalną operację z żądanymi odpowiedziami.

Czy HTTP+SSE jest usunięte od razu?

Nie. Jest deprecated, a nie natychmiast usunięte.

Nowe serwery powinny używać Streamable HTTP, a istniejące systemy powinny zmierzyć i migrować pozostały ruch HTTP+SSE.

Czy klienci TypeScript SDK v2 używają MCP 2026-07-28 automatycznie?

Nie. SDK v2 dla TypeScript wymaga jawnej konfiguracji negocjacji wersji, aby użyć nowoczesnego protokołu.

Użyj negocjacji automatycznej, gdy klient musi działać zarówno z nowoczesnymi, jak i legacy serwerami.

Końcowe rekomendacje

MCP 2026-07-28 ułatwia skalowanie, routing, keszowanie i obserwowalność zdalnej infrastruktury MCP. Głównym ryzykiem migracji nie jest tylko usunięcie nagłówka czy handshake’u. To ukryty stan aplikacji i logika interakcji, które mogą nadal od nich zależeć.

Przed wdrożeniem nowego protokołu:

Znajdź każdą zależność od inicjalizacji i Mcp-Session-Id.

1. Przenieś wymagany stan do jawnych uchwytów lub współdzielonego magazynu.
2. Zaimplementuj MRTR z wygaśnięciem, ochroną replay i idempotencją.
3. Waliduj nagłówki MCP względem ciała JSON-RPC.
4. Partycjonuj cache według tenantów i zakresu autoryzacji.
5. Utwardź walidację issuerów OAuth.
6. Mierz metody deprecated i ruch legacy transportu.
7. Kanarkuj ścieżki nowoczesnego i legacy protokołu przed wycofaniem.

Traktuj migrację jako zmianę infrastrukturalną, a nie rutynową aktualizację SDK.

Gdy warstwa MCP będzie bezstanowa i obserwowalna, utrzymuj dostęp do modeli za oddzielnym interfejsem. Pozwoli to warstwie protokołu narzędzi i warstwie dostawców modeli rozwijać się niezależnie.