MCP 2026-07-28 migreringsveiledning: tilstandsløse servere

TL;DR: MCP 2026-07-28 fjerner øktsstøtte på protokollnivå og det obligatoriske initieringshåndtrykket. Produksjonsteam bør finne skjulte øktavhengigheter, ta i bruk protokollmetadata per forespørsel, implementere Multi Round-Trip Requests, oppdatere gateway-policyer og canary-teste den nye protokollen før de avvikler eldre atferd.

Spesifikasjonen for Model Context Protocol som ble utgitt 28. juli 2026 introduserer den største arkitektoniske endringen i MCP siden støtte for ekstern transport ble lagt til.

Protokollen bruker nå en tilstandsløs kjerne for forespørsel og svar. Den påkrevde utvekslingen initialize og notifications/initialized er fjernet, Mcp-Session-Id er fjernet, og hver forespørsel bærer protokollinformasjonen som trengs for å behandle den.

Utgivelsen introduserer også Multi Round-Trip Requests, HTTP-ruteringsoverskrifter, bufrede liste-responser, strengere autorisasjonsatferd, et utvidelsesrammeverk og en formell avskrivningslivssyklus. Se den offisielle MCP 2026-07-28-kunngjøringen og komplett endringslogg for spesifikasjonen for protokolldetaljene.

Disse endringene gjør det enklere å skalere eksterne MCP-servere bak standard HTTP-infrastruktur. De gjør ikke automatisk en eksisterende applikasjon tilstandsløs.

En produksjonsserver kan fortsatt være avhengig av in-memory-arbeidsområder, klebrig ruting, øktbundne legitimasjoner, langlivede strømmer eller serverinitierte interaksjoner. Denne veiledningen fokuserer på å finne og erstatte disse avhengighetene.

For en mer introduksjonspreget implementasjonsgjennomgang, les How to Create an MCP Server for Claude Code før du starter migreringen.

Hvem må migrere?

Arbeidsomfanget avhenger av hvordan MCP brukes i systemet ditt.

En lokal server som ikke bevarer tilstand mellom forespørsler, kan kun kreve en SDK-oppgradering og kompatibilitetstesting.

En ekstern utrulling som bruker økter, OAuth, strømming eller serverinitierte forespørsler, krever en trinnvis migrering.

Hva endret seg i MCP 2026-07-28?

1. Kartlegg den eksisterende implementasjonen

Før du oppgraderer, søk i klient, server, gateway og utrullingskonfigurasjon etter eldre protokollantakelser.

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

Svar deretter på følgende spørsmål:

1. Avviser serveren kall til initieringen er fullført?
2. Velger en økt-ID en bruker, legitimasjon, et arbeidsområde eller en samtale?
3. Kan en annen serverinstans fortsette en arbeidsflyt som den første startet?
4. Krever lastbalansereren øktsaffinitet?
5. Utfører et verktøy en sideeffekt før det ber om bekreftelse?
6. Parser gatewayen kroppen for å identifisere metode eller verktøy?
7. Er OAuth-legitimasjoner lagret uten den utstedende autorisasjonsserveren?
8. Er klienten avhengig av SSE-gjenoppkobling eller meldingslevering på nytt?
9. Varierer verktøy- eller ressurslister etter forbindelse?
10. Hvilke utfasede funksjoner mottar fortsatt produksjonstrafikk?

Fjern ikke Mcp-Session-Id før du forstår hva applikasjonen lagrer bak den.

En server som fjerner overskriften men beholder tilstand i lokalminne kan fungere under utvikling og feile av og til når forespørsler fordeles på flere instanser.

2. Erstatt skjult økttilstand

MCP 2026-07-28 fjerner økter på protokollnivå, ikke applikasjonstilstand.

Tilstand som trengs på tvers av kall bør bruke ett av tre mønstre.

Eksplisitte håndtak

Returner et serverutstedt håndtak fra ett verktøy og krev det i senere kall.

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

En senere forespørsel sender håndtaket som et vanlig argument:

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

Dette gjør avhengigheten synlig i verktøykontrakten og lar en hvilken som helst kompatibel serverinstans behandle forespørselen.

Delt lagring

Bruk en database, distribuert cache, objektlager eller et holdbart oppgavesystem når:

• flere arbeidere trenger samme tilstand;
• arbeidsflyten må overleve en omstart;
• tilstanden er for stor for et håndtak;
• arbeidsflyten varer lenger enn én forespørsel;
• transaksjonell eller engangsatferd er påkrevd.

Beskyttet requestState

MRTR kan returnere en ugjennomsiktig requestState-verdi som klienten ekkoer når den prøver den opprinnelige forespørselen på nytt.

Fordi verdien passerer gjennom klienten, beskytt den med HMAC eller autentisert kryptering. Bind den til den autentiserte entiteten, den opprinnelige operasjonen, viktige parametere, utløpstid og en nonce når det er behov for replay-beskyttelse.

Stol aldri på en usignert requestState-verdi bare fordi klienten returnerte den uendret.

3. Ta i bruk selvstendige forespørsler og discovery

Moderne MCP-forespørsler inkluderer protokollkontekst i _meta.

Et Streamable HTTP-verktøykall kan se slik ut:

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 som retter seg mot den nye protokollen må implementere server/discover, som annonserer støttede versjoner, kapabiliteter og serveridentitet. Klienter kan kalle den før en annen operasjon eller bruke den til å avgjøre om en eldre fallback er nødvendig.

Les den offisielle server/discover documentation for responskontrakten.

TypeScript SDK-versjonsforhandling

Å oppgradere TypeScript SDK alene bytter ikke automatisk en klient til den nye protokollen.

En klient som bruker v2 SDK må eksplisitt velge det:

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

await client.connect(transport);

I automatisk modus sonderer SDK-en med server/discover og kan falle tilbake til den eldre initieringsflyten når den når en eldre server.

Team som fortsatt bruker @modelcontextprotocol/sdk v1 bør først følge den offisielle TypeScript SDK v1-til-v2-migreringsveiledningen. Team som allerede bruker v2 bør bruke den separate veiledningen for støtte av protokollen 2026-07-28.

4. Erstatt serverinitierte forespørsler med MRTR

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

Den nye protokollen erstatter dette med Multi Round-Trip Requests.

Flyten er:

1. Klienten sender den opprinnelige forespørselen.
2. Serveren returnerer resultType: "input_required".
3. Klienten samler den forespurte informasjonen eller godkjenningen.
4. Klienten forsøker den opprinnelige operasjonen på nytt med en ny JSON-RPC-ID.
5. Retryen inkluderer inputResponses og den opprinnelige requestState.
6. Serveren fullfører forespørselen eller starter en ny runde.

Eksempelrespons:

{
  "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 forsøker den opprinnelige operasjonen på nytt:

{
  "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 produksjonsimplementering av MRTR bør definere:

• maksimalt antall runder;
• utløp for request-state;
• kansellerings- og avvisningsatferd;
• validering av respons-skjema;
• autorisasjonssjekker ved hver retry;
• replay-beskyttelse;
• idempotens for sideeffekter;
• atferd når en klient ikke støtter den forespurte kapabiliteten.

Unngå å fullføre et kjøp, en sletting, kredittbelastning eller ekstern skriving før du returnerer input_required.

Bruk en trinnvis operasjon eller idempotency-nøkkel slik at retries ikke kan duplisere handlingen. Se den offisielle MRTR-spesifikasjonen for hele interaksjonsmodellen.

5. Oppdater gateways, caching og autorisasjon

Infrastrukturendringene henger tett sammen og bør testes samlet.

Valider MCP-ruteringsoverskrifter

Streamable HTTP POST-forespørsler inkluderer nå:

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

Disse overskriftene lar gateways rute, måle, autorisere og rate-limite trafikk uten å parse hver JSON-kropp.

De kan støtte kontroller som:

• verktøyspesifikke rate-limiter;
• separate policyer for liste- og eksekveringsmetoder;
• dedikerte worker-pooler for dyre verktøy;
• begrenset tilgang til høyrisikooperasjoner;
• ventetid- og feilmetrikk per verktøy;
• kostnadsattributtering for infrastruktur.

Verdiene leveres fortsatt av klienten. Sammenlign dem med JSON-RPC-kroppen før du anvender policy.

En forespørsel skal ikke kunne hevde et lavrisikoverktøy i Mcp-Name samtidig som den kaller et annet verktøy i kroppen. Mismatch mellom overskrifter og kropp bør avvises og logges.

Bruk autorisasjonsbevisste cache-nøkler

Den nye protokollen legger til ttlMs og cacheScope i bufrede resultater inkludert:

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

En cache-nøkkel bør normalt inkludere:

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

Gjenbruk ikke en privat cache-oppføring på tvers av brukere eller leietakere bare fordi TTL ikke har utløpt.

Deterministisk verktøysortering er også viktig. En stabil katalog unngår unødvendige cache-miss og kan forbedre modellens prompt-cache-gjenbruk når verktøydefinisjoner settes inn i prompts.

Styrk håndtering av OAuth-issuer

Under autorisasjonsmigrering:

• valider en returnert iss-verdi mot issuer som er registrert for flyten;
• nøkkel-lagre klientlegitimasjoner per issuer;
• gjenbruk aldri legitimasjoner med en annen autorisasjonsserver;
• sett en passende application_type under DCR;
• forbered nye integrasjoner for Client ID Metadata Documents.

Dynamic Client Registration er fortsatt tilgjengelig for bakoverkompatibilitet, men den er frarådet som foretrukket registreringsmetode.

6. Migrer notifikasjoner, Tasks og utfasede funksjoner

Den eldre HTTP GET-varslingsbanen og flyten resources/subscribe eller resources/unsubscribe er erstattet av subscriptions/listen.

Klienter åpner en langlivet POST-responsstrøm og melder seg på varslingskategoriene de trenger. Forespørselsspesifikke fremdrifts- og loggvarsler forblir knyttet til responsstrømmen for forespørselen de beskriver.

For multiinstansutrullinger, bruk en delt hendelsesbuss når notifikasjoner generert på én serverinstans må nå et abonnement koblet til en annen.

Tasks-utvidelse

Langvarig arbeid er flyttet ut av den eksperimentelle kjerneprotokollen og inn i:

io.modelcontextprotocol/tasks

Utvidelsen bruker:

• tasks/get for polling;
• tasks/update for klient-til-server-oppdateringer;
• holdbare oppgavehåndtak;
• subscriptions/listen for valgte oppdateringer.

De eldre mønstrene tasks/result og tasks/list bør ikke tas med inn i en ny implementering.

Utfasede funksjoner

Følgende funksjoner er frarådet:

Frarådet funksjonalitet forblir tilgjengelig i avskrivningsvinduet, men nye implementeringer bør ikke ta den i bruk. MCPs livssykluspolicy gir minimum tolv måneders avskrivningsperiode; det betyr ikke at hver funksjon har samme bekreftede fjerningsdato.

Se det offisielle registeret for utfasede funksjoner før du setter en avviklingsfrist.

7. Rull ut migreringen sikkert

Ikke endre klienter, servere, gateways, caching og autorisasjon i én uovervåket utgivelse.

Anbefalt migreringsrekkefølge

1. Kartlegg protokollversjoner, SDK-er, økter, SSE-trafikk, DCR-klienter og utfasede metoder.
2. Oppgrader ikke-produksjons-SDK-er.
3. Legg til server/discover og versjonsforhandling.
4. Erstatt skjulte øktavhengigheter.
5. Implementer og sikre MRTR.
6. Legg til validerte ruteringsoverskrifter og avgrensede cacher.
7. Test autorisasjonsgrenser for issuer.
8. Canary-test den moderne protokollen ved siden av den eldre banen.
9. Avvikle eldre atferd først etter å ha vurdert telemetri.

Kompatibilitet under canary

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

Utgivelsen av en ny MCP-spesifikasjon er ikke en økosystem-omfattende bryter. Klienter, servere, SDK-er og hostede plattformer vil migrere i ulikt tempo.

Telemetri å registrere

Vellykkede one-shot tools/call-forespørsler er ikke nok for å måle migreringen. En arbeidsflyt som stadig tidsavbrytes, ber om unødvendig input eller dupliserer en ekstern skrivning, er fortsatt en produksjonsfeil.

Hvordan CometAPI passer inn i en MCP-arkitektur

MCP erstatter ikke en modell-API. De to lagene løser ulike integrasjonsproblemer.

En typisk produksjonsarkitektur ser slik ut:

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 verktøy og kontekst. Den standardiserer ikke modellprising, leverandørlegitimasjoner, inference-endepunkter eller leverandør-failover.

Dette skillet er spesielt nyttig ved migrering bort fra den utfasede Sampling-kapasiteten. Hvis en MCP-server eller agenten som bruker den fortsatt trenger modellinferenz, kan applikasjonen kalle en modell-API direkte i stedet for å være avhengig av den tidligere MCP Sampling-flyten.

Når en enhetlig modell-gateway hjelper

En enhetlig modell-gateway kan redusere operasjonelt arbeid når:

• flere MCP-servere trenger tilgang til ulike modellleverandører;
• ulike verktøy krever ulike modeller;
• team ønsker å bytte modeller uten å skrive om leverandørspesifikke integrasjoner;
• legitimasjoner, bruk og fakturering må håndteres sentralt;
• modelltilgang bør være uavhengig av endringer i MCP-transport.

CometAPI tilbyr et OpenAI-kompatibelt endepunkt som kan brukes som modelltilgangslaget bak MCP-applikasjoner. Dette holder modell-leverandørlogikk atskilt fra MCP-verktøy, ressurser og oppgaveorkestrering.

For eksempel kan et MCP-verktøy kalle en modell via samme OpenAI-kompatible klient som brukes andre steder i applikasjonen:

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 forblir ansvarlig for verktøykontrakten, autorisasjon, tilstand og resultatbehandling. Modell-gatewayen håndterer modellvalg, leverandørtilgang og inferensresponser.

Å holde disse lagene separate gir to praktiske fordeler:

1. MCP-klienter og -servere kan migrere til den nye protokollen uten å endre modellintegrasjonslaget.
2. Modellleverandører kan byttes uten å redesigne MCP-verktøy eller transportatferd.

For flere implementasjonsdetaljer, se CometAPI Quickstart, API-dokumentasjon og veiledning for multi-modell AI-applikasjoner.

MCP 2026-07-28 sjekkliste for migrering

Klient

• Oppgrader til kompatibel SDK.
• Aktiver moderne versjonsforhandling.
• Støtt server/discover.
• Inkluder protokollmetadata i hver forespørsel.
• Håndter resultType.
• Støtt eller avvis eksplisitt MRTR.
• Bruk en ny JSON-RPC-ID for retries.
• Bevar og returner requestState.
• Valider OAuth-issuere.
• Lagre legitimasjoner per issuer.
• Respekter cache-hint.
• Støtt subscriptions/listen ved behov.

Server

• Fjern initieringsporter for moderne forespørsler.
• Fjern avhengigheter til Mcp-Session-Id.
• Implementer server/discover.
• Erstatter skjult tilstand med håndtak eller delt lagring.
• Returner resultType.
• Erstatt serverinitierte forespørsler med MRTR.
• Beskytt requestState.
• Valider alle inputResponses.
• Legg til idempotens for sideeffekter.
• Returner deterministiske lister.
• Publiser konservative cache-hint.
• Migrer langvarig arbeid til Tasks-utvidelsen.

Gateway og infrastruktur

• Valider MCP-forespørselsoverskrifter.
• Sammenlign overskrifter med forespørselens kropp.
• Fjern unødvendig klebrig ruting.
• Test forespørsler på tvers av flere instanser.
• Partisjoner cacher etter autorisasjonsgrense.
• Legg til en delt varslingsbuss der det kreves.
• Spor trafikk på eldre og utfasede baner.
• Oppretthold en rollback-bane under canary.

FAQ

Hva er MCP 2026-07-28?

MCP 2026-07-28 er spesifikasjonen for Model Context Protocol som ble utgitt 28. juli 2026. Den introduserer en tilstandsløs protokollkjerne, Multi Round-Trip Requests, HTTP-ruteringsoverskrifter, bufrede resultater, autorisasjonsendringer, utvidelser og en formell avskrivningslivssyklus.

Er Mcp-Session-Id fjernet?

Ja. Den nye Streamable HTTP-protokollen bruker ikke Mcp-Session-Id.

Applikasjoner kan fortsatt bevare tilstand via eksplisitte håndtak, delt lagring, holdbare oppgaver eller beskyttede request-state-verdier.

Er MCP-initieringshåndtrykket fjernet?

Ja. Moderne forespørsler krever ikke lenger utvekslingen initialize og notifications/initialized.

Servere må implementere server/discover, selv om klienter ikke trenger å kalle den før hver operasjon.

Betyr tilstandsløs MCP at verktøy ikke kan bevare tilstand?

Nei. Tilstandsløs gjelder protokollaget.

Et verktøy kan fortsatt lagre tilstand, men forespørselsbehandling bør ikke være avhengig av skjult transportaffinitet eller én spesifikk serverprosess.

Hva er MRTR?

Multi Round-Trip Requests lar en server be om ekstra klient- eller brukerinput uten å sende en serverinitiert forespørsel over en kontinuerlig åpen toveisforbindelse.

Serveren returnerer input_required, og klienten forsøker den opprinnelige operasjonen på nytt med de forespurte responsene.

Er HTTP+SSE fjernet umiddelbart?

Nei. Den er frarådet, ikke umiddelbart fjernet.

Nye servere bør bruke Streamable HTTP, mens eksisterende systemer bør måle og migrere gjenværende HTTP+SSE-trafikk.

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

Nei. TypeScript v2 SDK krever eksplisitt konfigurasjon for versjonsforhandling for å bruke den moderne protokollen.

Bruk automatisk forhandling når klienten må fungere med både moderne og eldre servere.

Endelige anbefalinger

MCP 2026-07-28 gjør ekstern MCP-infrastruktur enklere å skalere, rute, bufre og observere. Den største migreringsrisikoen er ikke bare fjerning av en overskrift eller et håndtrykk. Det er den skjulte applikasjonstilstanden og interaksjonslogikken som fortsatt kan være avhengig av dem.

Før du ruller ut den nye protokollen:

Finn hver avhengighet av initiering og Mcp-Session-Id.

1. Flytt nødvendig tilstand til eksplisitte håndtak eller delt lagring.
2. Implementer MRTR med utløp, replay-beskyttelse og idempotens.
3. Valider MCP-overskrifter mot JSON-RPC-kroppen.
4. Partisjoner cacher etter leietaker og autorisasjonsomfang.
5. Gjør valideringen av OAuth-issuer mer robust.
6. Mål utfasede metoder og trafikk på eldre transport.
7. Canary-test moderne og eldre protokollbaner før avvikling.

Behandle migreringen som en infrastrukturendring, ikke en rutinemessig SDK-oppgradering.

Når MCP-laget er tilstandsløst og observerbart, hold modelltilgangen bak et separat grensesnitt. Dette lar verktøyprotokollen og modellleverandørlaget utvikle seg uavhengig.