MCP 2026-07-28 Migreringsvejledning: Tilstandsløse servere

TL;DR: MCP 2026-07-28 fjerner sessions på protokolniveau og det obligatoriske initialiserings-handshake. Produktionsteams bør finde skjulte session-afhængigheder, tage protokolmetadata pr. forespørgsel i brug, implementere Multi Round-Trip-forespørgsler, opdatere gateway-politikker og kanarie-udrulle den nye protokol, før den gamle adfærd udfases.

Model Context Protocol-specifikationen, udgivet den 28. juli 2026, introducerer den største arkitekturændring i MCP siden understøttelse af fjerntransport blev tilføjet.

Protokollen bruger nu en tilstandsløs request-response-kerne. Den påkrævede udveksling initialize og notifications/initialized er fjernet, Mcp-Session-Id er fjernet, og hver forespørgsel bærer de protokoloplysninger, der er nødvendige for at behandle den.

Udgivelsen introducerer også Multi Round-Trip Requests, HTTP-rutningsheadere, cachebare liste-svar, strengere autorisationsadfærd, et udvidelsesframework og en formel udfasningslivscyklus. Se den officielle MCP 2026-07-28-udgivelsesmeddelelse og fulde specifikationsændringslog for detaljer på protokolniveau.

Disse ændringer gør det lettere at skalere fjern-MCP-servere bag standard HTTP-infrastruktur. De gør ikke automatisk en eksisterende applikation tilstandsløs.

En produktionsserver kan stadig være afhængig af in-memory workspaces, sticky routing, session-bundne legitimationsoplysninger, langlivede streams eller server-initierede interaktioner. Denne vejledning fokuserer på at finde og erstatte disse afhængigheder.

For en mere introducerende implementeringsgennemgang, læs How to Create an MCP Server for Claude Code før du starter migreringen.

Hvem skal migrere?

Arbejdsbyrden afhænger af, hvordan MCP bruges i dit system.

En lokal server, der ikke bevarer tilstand på tværs af forespørgsler, kræver muligvis kun en SDK-opgradering og kompatibilitetstest.

En fjern-udrulning, der bruger sessioner, OAuth, streaming eller server-initierede forespørgsler, kræver en trinvis migration.

Hvad ændrede sig i MCP 2026-07-28?

1. Gennemgå den eksisterende implementering

Før opgradering, søg i klient, server, gateway og udrulningskonfiguration efter ældre protokolantagelser.

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

Besvar derefter følgende spørgsmål:

1. Afviser serveren kald, indtil initialisering er fuldført?
2. Vælger en session-ID en bruger, legitimationsoplysning, workspace eller samtale?
3. Kan en anden serverinstans fortsætte en arbejdsgang, som den første startede?
4. Kræver load balanceren session-affinitet?
5. Udfører et værktøj en sideeffekt, før det anmoder om bekræftelse?
6. Parser gatewayen kroppen for at identificere metoden eller værktøjet?
7. Er OAuth-legitimationsoplysninger gemt uden deres udstedende autorisationsserver?
8. Er klienten afhængig af SSE-genforbindelse eller meddelelsesgenlevering?
9. Varierer værktøjs- eller ressourcelister efter forbindelse?
10. Hvilke udfasede funktioner modtager stadig produktionstrafik?

Fjern ikke Mcp-Session-Id, før du forstår, hvad applikationen gemmer bag den.

En server, der fjerner headeren men bevarer tilstand i lokal hukommelse, kan fungere under udvikling og fejle sporadisk, når forespørgsler fordeles på flere instanser.

2. Erstat skjult sessionstilstand

MCP 2026-07-28 fjerner sessioner på protokolniveau, ikke applikationstilstand.

Tilstand, der kræves på tværs af kald, bør bruge et af tre mønstre.

Eksplicitte handles

Returnér et serveroprettet handle fra ét værktøj og kræv det i senere kald.

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

En senere forespørgsel videregiver handlet som et almindeligt argument:

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

Dette gør afhængigheden synlig i værktøjskontrakten og tillader enhver kompatibel serverinstans at behandle forespørgslen.

Delt lagring

Brug en database, distribueret cache, objektlager eller et holdbart task-system, når:

• flere arbejdere har brug for den samme tilstand;
• arbejdsgangen skal overleve en genstart;
• tilstanden er for stor til et handle;
• arbejdsgangen varer længere end en enkelt forespørgsel;
• transaktionel eller engangsadfærd er påkrævet.

Beskyttet requestState

MRTR kan returnere en ugennemsigtig requestState-værdi, som klienten ekkoer, når den prøver den oprindelige forespørgsel igen.

Da værdien passerer gennem klienten, skal den beskyttes med en HMAC eller godkendt kryptering. Bind den til den autentificerede principal, den oprindelige operation, vigtige parametre, udløbstid og et nonce, når der kræves replay-beskyttelse.

Stol aldrig på en usigneret requestState-værdi, blot fordi klienten returnerede den uændret.

3. Indfør selvstændige forespørgsler og discovery

Moderne MCP-forespørgsler inkluderer protokolkontekst i _meta.

Et Streamable HTTP-værktøjskald kan se sådan ud:

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": {}
      }
    }
  }
}

Servere, der målretter den nye protokol, skal implementere server/discover, som annoncerer understøttede versioner, kapabiliteter og serveridentitet. Klienter kan kalde den før en anden operation eller bruge den til at afgøre, om et legacy-fallback er påkrævet.

Læs den officielle server/discover documentation for svar-kontrakten.

TypeScript SDK versionforhandling

Opgradering af TypeScript SDK alene skifter ikke automatisk en klient til den nye protokol.

En klient, der bruger v2 SDK, skal eksplicit vælge til:

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

await client.connect(transport);

I automatisk tilstand sonderer SDK med server/discover og kan falde tilbage til det ældre initialiseringsflow, når den når en legacy-server.

Teams, der stadig bruger @modelcontextprotocol/sdk v1, bør først følge den officielle TypeScript SDK v1-til-v2 migrationsvejledning. Teams, der allerede bruger v2, bør bruge den separate 2026-07-28-protokol supportvejledning.

4. Erstat server-initierede forespørgsler med MRTR

Tidligere MCP-implementeringer kunne sende forespørgsler som elicitation/create, sampling/createMessage eller roots/list fra serveren til klienten.

Den nye protokol erstatter denne model med Multi Round-Trip Requests.

Forløbet er:

1. Klienten sender den oprindelige forespørgsel.
2. Serveren returnerer resultType: "input_required".
3. Klienten indsamler den anmodede information eller godkendelse.
4. Klienten prøver den oprindelige operation igen med et nyt JSON-RPC-ID.
5. Retryet inkluderer inputResponses og den oprindelige requestState.
6. Serveren fuldfører forespørgslen eller starter en ny runde.

Eksempelsvar:

{
  "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"
  }
}

Klienten prøver den oprindelige operation igen:

{
  "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"
  }
}

En produktionsklar MRTR-implementering bør definere:

• maksimalt antal runder;
• udløb for request-state;
• annullerings- og afvisningsadfærd;
• validering af svarskemaer;
• autorisationskontrol ved hver retry;
• replay-beskyttelse;
• idempotens for sideeffekter;
• adfærd når en klient ikke understøtter den anmodede kapabilitet.

Undgå at fuldføre et køb, en sletning, kreditsfradrag eller ekstern skrivning, før du returnerer input_required.

Brug en trinvis operation eller en idempotency-nøgle, så retries ikke kan duplikere handlingen. Se den officielle MRTR-specifikation for den fulde interaktionsmodel.

5. Opdater gateways, caching og autorisation

Infrastrukturændringerne er nært beslægtede og bør testes sammen.

Validér MCP-rutningsheadere

Streamable HTTP POST-forespørgsler inkluderer nu:

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

Disse headere gør det muligt for gateways at route, måle, autorisere og rate-limite trafik uden at parse hver JSON-krop.

De kan understøtte kontroller som:

• værktøjsspecifikke rate limits;
• separate politikker for liste- og eksekveringsmetoder;
• dedikerede worker-pools til dyre værktøjer;
• begrænset adgang til højrisiko-operationer;
• latenstid- og fejlmetrik efter værktøj;
• attribuering af infrastruktur-omkostninger.

Værdierne leveres stadig af klienten. Sammenlign dem med JSON-RPC-kroppen, før der anvendes politik.

En forespørgsel må ikke kunne påstå et lavrisikoværktøj i Mcp-Name, mens den påkalder et andet værktøj i kroppen. Uoverensstemmelser mellem header og krop bør afvises og logges.

Brug autorisationsbevidste cache-nøgler

Den nye protokol tilføjer ttlMs og cacheScope til cachebare resultater, inklusive:

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

En cache-nøgle bør normalt omfatte:

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

Genbrug ikke en privat cache-post på tværs af brugere eller tenants, blot fordi TTL ikke er udløbet.

Deterministisk værktøjsrækkefølge er også vigtig. Et stabilt katalog undgår unødvendige cache-miss og kan forbedre modellens prompt-cache-genbrug, når værktøjsdefinitioner indsættes i prompts.

Styrk håndtering af OAuth-udsteder

Under autorisationsmigration:

• validér en returneret iss-værdi mod den udsteder, der er registreret for forløbet;
• indekser gemte klientlegitimationsoplysninger efter udsteder;
• genbrug aldrig legitimationsoplysninger med en anden autorisationsserver;
• angiv en passende application_type under DCR;
• forbered nye integrationer til Client ID Metadata Documents.

Dynamic Client Registration er fortsat tilgængelig for bagudkompatibilitet, men er udfaset som foretrukken registreringsmetode.

6. Migrér notifikationer, Tasks og udfasede funktioner

Den ældre HTTP GET-notifikationssti og resources/subscribe- eller resources/unsubscribe-flowet er blevet erstattet af subscriptions/listen.

Klienter åbner en langlivet POST-svarstream og vælger de notifikationskategorier, de har brug for. Forespørgselsspecifikke fremskridts- og lognotifikationer forbliver knyttet til den svarstream, der beskriver forespørgslen.

For udrulninger med flere instanser, brug en delt event-bus, når notifikationer genereret på én serverinstans skal nå et abonnement, der er forbundet til en anden.

Tasks-udvidelse

Langvarigt arbejde er flyttet ud af den eksperimentelle kerneprotokol og ind i:

io.modelcontextprotocol/tasks

Udvidelsen bruger:

• tasks/get til polling;
• tasks/update til klient-til-server-opdateringer;
• holdbare task-handles;
• subscriptions/listen til opt-in-opdateringer.

Det ældre tasks/result- og tasks/list-mønster bør ikke videreføres i en ny implementering.

Udfasede funktioner

Følgende funktioner er udfaset:

Udfaset funktionalitet forbliver tilgængelig i udfasningsperioden, men nye implementeringer bør ikke adoptere den. MCP-livscykluspolitikken giver mindst tolv måneders udfasningsperiode; det betyder ikke, at hver funktion har samme bekræftede fjernelsesdato.

Gennemgå det officielle register over udfasede funktioner, før der fastsættes en udfasningsdeadline.

7. Rul migrationen sikkert ud

Foretag ikke ændringer i klienter, servere, gateways, caching og autorisation i én uovervåget release.

Anbefalet migrationsrækkefølge

1. Kortlæg protokolversioner, SDK’er, sessioner, SSE-trafik, DCR-klienter og udfasede metoder.
2. Opgradér ikke-produktions-SDK’er.
3. Tilføj server/discover og versionsforhandling.
4. Erstat skjulte sessionafhængigheder.
5. Implementér og sikr MRTR.
6. Tilføj validerede rutningsheadere og afgrænsede caches.
7. Test autorisations-udstedergrænser.
8. Kanarie-udrul den moderne protokol side om side med legacy-stien.
9. Udfas ældre adfærd kun efter gennemgang af telemetri.

Kompatibilitet under kanarieudrulningen

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

Udgivelsen af en ny MCP-specifikation er ikke en økosystem-omfattende afbryder. Klienter, servere, SDK’er og hostede platforme vil migrere i forskellige hastigheder.

Telemetri der skal registreres

Vellykkede engangskald til tools/call er ikke nok til at måle migreringen. En arbejdsgang, der gentagne gange får timeout, anmoder om unødvendigt input eller duplikerer en ekstern skrivning, er stadig en produktionsfejl.

Hvordan CometAPI passer ind i en MCP-arkitektur

MCP erstatter ikke en model-API. De to lag løser forskellige integrationsproblemer.

En typisk produktionsarkitektur ser sådan ud:

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

MCP standardiserer, hvordan agenter interagerer med værktøjer og kontekst. Den standardiserer ikke modelpriser, leverandørlegitimationsoplysninger, inferensendpoints eller leverandør-failover.

Denne opdeling bliver særligt nyttig, når der migreres væk fra den udfasede Sampling-kapabilitet. Hvis en MCP-server eller agenten, der forbruger den, stadig har brug for modelinferens, kan applikationen kalde en model-API direkte i stedet for at afhænge af det tidligere MCP Sampling-flow.

Hvornår en samlet model-gateway hjælper

En samlet model-gateway kan reducere driftsarbejdet, når:

• flere MCP-servere har brug for adgang til forskellige modelleverandører;
• forskellige værktøjer kræver forskellige modeller;
• teams vil skifte modeller uden at omskrive leverandørspecifikke integrationer;
• legitimationsoplysninger, forbrug og fakturering skal administreres centralt;
• modeladgang bør forblive uafhængig af ændringer i MCP-transport.

CometAPI leverer et OpenAI-kompatibelt endpoint, der kan bruges som modellaget bag MCP-applikationer. Dette holder modellogik adskilt fra MCP-værktøjer, ressourcer og task-orkestrering.

For eksempel kan et MCP-værktøj kalde en model gennem den samme OpenAI-kompatible klient, der bruges andre steder i applikationen:

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 ?? "";
}

MCP-serveren forbliver ansvarlig for værktøjskontrakten, autorisation, tilstand og håndtering af resultater. Model-gatewayen håndterer modelvalg, leverandøradgang og inferenssvar.

At holde disse lag adskilt giver to praktiske fordele:

1. MCP-klienter og -servere kan migrere til den nye protokol uden at ændre modellagringslaget.
2. Modelløvere kan ændres uden at redesigne MCP-værktøjer eller transportadfærd.

For flere implementeringsdetaljer, se CometAPI Quickstart, API-dokumentation og vejledning til multimodel AI-applikationer.

MCP 2026-07-28 migrations-tjekliste

Klient

• Opgradér til et kompatibelt SDK.
• Aktivér moderne versionsforhandling.
• Understøt server/discover.
• Inkludér protokolmetadata i hver forespørgsel.
• Håndtér resultType.
• Understøt eller afvis eksplicit MRTR.
• Brug et nyt JSON-RPC-ID til retries.
• Bevar og returnér requestState.
• Validér OAuth-udsteders (issuer) værdier.
• Gem legitimationsoplysninger efter udsteder.
• Respektér cache-hints.
• Understøt subscriptions/listen efter behov.

Server

• Fjern initialiseringskontroller for moderne forespørgsler.
• Fjern afhængigheder af Mcp-Session-Id.
• Implementér server/discover.
• Erstat skjult tilstand med handles eller delt lagring.
• Returnér resultType.
• Erstat server-initierede forespørgsler med MRTR.
• Beskyt requestState.
• Validér alle inputResponses.
• Tilføj idempotens for sideeffekter.
• Returnér deterministiske lister.
• Publicér konservative cache-hints.
• Migrér langvarigt arbejde til Tasks-udvidelsen.

Gateway og infrastruktur

• Validér MCP-forespørgselsheadere.
• Sammenlign headere med forespørgslens krop.
• Fjern unødvendig sticky routing.
• Test forespørgsler på tværs af flere instanser.
• Partitioner caches efter autorisationsgrænse.
• Tilføj en delt notifikationsbus, hvor påkrævet.
• Spor legacy- og udfaset trafik.
• Oprethold en rollback-sti under kanarieudrulningen.

FAQ

Hvad er MCP 2026-07-28?

MCP 2026-07-28 er Model Context Protocol-specifikationen udgivet den 28. juli 2026. Den introducerer en tilstandsløs protokolkerne, Multi Round-Trip Requests, HTTP-rutningsheadere, cachebare resultater, autorisationsændringer, udvidelser og en formel udfasningslivscyklus.

Er Mcp-Session-Id fjernet?

Ja. Den nye Streamable HTTP-protokol bruger ikke længere Mcp-Session-Id.

Applikationer kan stadig bevare tilstand via eksplicitte handles, delt lagring, holdbare tasks eller beskyttede request-state-værdier.

Er MCP-initialiserings-handshaket fjernet?

Ja. Moderne forespørgsler kræver ikke længere udvekslingen initialize og notifications/initialized.

Servere skal implementere server/discover, selvom klienter ikke behøver at kalde den før hver operation.

Betyder tilstandsløs MCP, at værktøjer ikke kan bevare tilstand?

Nej. Tilstandsløs refererer til protokollaget.

Et værktøj kan stadig gemme tilstand, men behandlingen af en forespørgsel bør ikke afhænge af skjult transportaffinitet eller én specifik serverproces.

Hvad er MRTR?

Multi Round-Trip Requests lader en server anmode om yderligere klient- eller brugerinput uden at sende en server-initieret forespørgsel over en kontinuerligt åben tovejstilkobling.

Serveren returnerer input_required, og klienten prøver den oprindelige operation igen med de anmodede svar.

Er HTTP+SSE fjernet med det samme?

Nej. Det er udfaset, ikke straks fjernet.

Nye servere bør bruge Streamable HTTP, mens eksisterende systemer bør måle og migrere resterende HTTP+SSE-trafik.

Bruger TypeScript SDK v2-klienter MCP 2026-07-28 automatisk?

Nej. TypeScript v2 SDK kræver en eksplicit konfiguration for versionsforhandling for at bruge den moderne protokol.

Brug automatisk forhandling, når klienten skal fungere med både moderne og legacy-servere.

Endelige anbefalinger

MCP 2026-07-28 gør fjern-MCP-infrastruktur lettere at skalere, route, cache og observere. Den største migrationsrisiko er ikke blot fjernelsen af en header eller et handshake. Det er den skjulte applikationstilstand og interaktionslogik, der stadig kan afhænge af dem.

Før den nye protokol udrulles:

Find hver afhængighed af initialisering og Mcp-Session-Id.

1. Flyt den påkrævede tilstand til eksplicitte handles eller delt lagring.
2. Implementér MRTR med udløb, replay-beskyttelse og idempotens.
3. Validér MCP-headere mod JSON-RPC-kroppen.
4. Partitioner caches efter tenant og autorisationsomfang.
5. Hærd validering af OAuth-udsteder.
6. Mål udfasede metoder og legacy-transporttrafik.
7. Kanarie-udrul moderne og legacy-protokolstier før udfasning.

Behandl migreringen som en infrastrukturændring snarere end en rutinemæssig SDK-opgradering.

Når MCP-laget er tilstandsløst og observerbart, så hold modeladgang bag et separat interface. Dette lader værktøjsprotokollen og modellagets leverandører udvikle sig uafhængigt.