MCP 2026-07-28 Migratiehandleiding: toestandloze servers

TL;DR: MCP 2026-07-28 verwijdert sessies op protocolniveau en de verplichte initialisatie-handshake. Productieteams moeten verborgen sessie-afhankelijkheden opsporen, protocolmetadata per verzoek opnemen, Multi Round-Trip-verzoeken implementeren, gatewaybeleid bijwerken en het nieuwe protocol via een canary uitrollen voordat legacy-gedrag wordt uitgefaseerd.

De Model Context Protocol-specificatie die op 28 juli 2026 is uitgebracht, introduceert de grootste architectuurwijziging in MCP sinds ondersteuning voor remote transport is toegevoegd.

Het protocol gebruikt nu een stateless request-responsekern. De vereiste uitwisseling van initialize en notifications/initialized is verwijderd, Mcp-Session-Id is verwijderd, en elk verzoek bevat de protocolinformatie die nodig is om het te verwerken.

De release introduceert ook Multi Round-Trip-verzoeken, HTTP-routeringsheaders, cachebare lijstresponsen, strikter autorisatiegedrag, een extensiekader en een formele uitfaseringslevenscyclus. Zie de officiële MCP 2026-07-28 release-aankondiging en de volledige wijzigingsgeschiedenis van de specificatie voor details op protocolniveau.

Deze wijzigingen maken het eenvoudiger om remote MCP-servers achter standaard HTTP-infrastructuur te schalen. Ze maken een bestaande applicatie niet automatisch stateless.

Een productieserver kan nog steeds vertrouwen op in-memory werkruimten, sticky routing, sessiegebonden credentials, langlopende streams of door de server geïnitieerde interacties. Deze gids richt zich op het vinden en vervangen van die afhankelijkheden.

Voor een meer introductieve implementatiewalkthrough, lees How to Create an MCP Server for Claude Code voordat je met de migratie begint.

Wie moet migreren?

De benodigde inspanning hangt af van hoe MCP in je systeem wordt gebruikt.

Een lokale server die geen state over verzoeken heen bewaart, heeft mogelijk alleen een SDK-upgrade en compatibiliteitstests nodig.

Een remote deployment met sessies, OAuth, streaming of door de server geïnitieerde verzoeken vereist een gefaseerde migratie.

Wat is er veranderd in MCP 2026-07-28?

1. Inventariseer de bestaande implementatie

Zoek voordat je upgradet in de client, server, gateway en deploymentconfiguratie naar oudere protocolveronderstellingen.

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

Beantwoord vervolgens de volgende vragen:

1. Wijst de server calls af totdat de initialisatie is voltooid?
2. Selecteert een session ID een gebruiker, credential, workspace of conversatie?
3. Kan een andere serverinstantie een workflow voortzetten die door de eerste is gestart?
4. Vereist de load balancer sessie-affiniteit?
5. Voert een tool een side-effect uit voordat bevestiging wordt gevraagd?
6. Parseert de gateway de body om de methode of tool te identificeren?
7. Worden OAuth-credentials opgeslagen zonder de uitgevende autorisatieserver?
8. Vertrouwt de client op SSE-reconnectie of bericht-herlevering?
9. Variëren tool- of resourcelijsten per verbinding?
10. Welke verouderde features ontvangen nog productieverkeer?

Verwijder Mcp-Session-Id niet totdat je begrijpt wat de applicatie erachter opslaat.

Een server die de header verwijdert maar state in lokaal geheugen behoudt, kan tijdens ontwikkeling werken en vervolgens intermitterend falen zodra verzoeken over meerdere instanties worden verdeeld.

2. Vervang verborgen sessiestate

MCP 2026-07-28 verwijdert sessies op protocolniveau, niet applicatiestate.

State die over calls heen nodig is, moet een van drie patronen gebruiken.

Expliciete handles

Geef vanuit één tool een door de server uitgegeven handle terug en vereis deze in latere calls.

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

Een later verzoek geeft de handle door als een gewone parameter:

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

Dit maakt de afhankelijkheid zichtbaar in het toolcontract en stelt elke compatibele serverinstantie in staat het verzoek te verwerken.

Gedeelde opslag

Gebruik een database, distributed cache, object store of duurzaam taken­systeem wanneer:

• meerdere workers dezelfde state nodig hebben;
• de workflow een herstart moet overleven;
• de state te groot is voor een handle;
• de workflow langer duurt dan één verzoek;
• transactioneel of eenmalig gedrag vereist is.

Beschermde requestState

MRTR kan een ondoorzichtige requestState teruggeven die de client echoot bij het retrieden van het oorspronkelijke verzoek.

Omdat de waarde via de client loopt, moet je deze beschermen met een HMAC of geauthenticeerde encryptie. Bind hem aan de geauthenticeerde principal, de oorspronkelijke operatie, belangrijke parameters, vervaltijd en een nonce wanneer replay-bescherming nodig is.

Vertrouw een niet-ondertekende requestState nooit alleen omdat de client hem ongewijzigd heeft teruggestuurd.

3. Neem zelfvoorzienende verzoeken en discovery in gebruik

Moderne MCP-verzoeken bevatten protocolcontext in _meta.

Een Streamable HTTP tool-call kan er als volgt uitzien:

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

Servers die zich op het nieuwe protocol richten, moeten server/discover implementeren, dat ondersteunde versies, mogelijkheden en serveridentiteit adverteert. Clients kunnen dit aanroepen vóór een andere operatie of gebruiken om te bepalen of een legacy fallback nodig is.

Lees de officiële documentatie van server/discover voor het responsecontract.

TypeScript SDK-versieonderhandeling

Het upgraden van de TypeScript SDK alleen schakelt een client niet automatisch over naar het nieuwe protocol.

Een client die de v2 SDK gebruikt, moet expliciet kiezen:

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

await client.connect(transport);

In de automatische modus peilt de SDK met server/discover en kan terugvallen op de oudere initialisatiestroom wanneer hij een legacyserver bereikt.

Teams die nog @modelcontextprotocol/sdk v1 gebruiken, moeten eerst de officiële TypeScript SDK v1-naar-v2 migratiehandleiding volgen. Teams die al v2 gebruiken, moeten de aparte 2026-07-28 protocolondersteuningsgids gebruiken.

4. Vervang door de server geïnitieerde verzoeken door MRTR

Eerdere MCP-implementaties konden verzoeken zoals elicitation/create, sampling/createMessage of roots/list van de server naar de client sturen.

Het nieuwe protocol vervangt dat model door Multi Round-Trip Requests.

De flow is:

1. De client stuurt het oorspronkelijke verzoek.
2. De server retourneert resultType: "input_required".
3. De client verzamelt de gevraagde informatie of goedkeuring.
4. De client retryt de oorspronkelijke operatie met een nieuwe JSON-RPC-ID.
5. De retry bevat inputResponses en de oorspronkelijke requestState.
6. De server voltooit het verzoek of start een nieuwe ronde.

Voorbeeldrespons:

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

De client retryt de oorspronkelijke operatie:

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

Een productie-MRTR-implementatie moet definiëren:

• maximaal aantal rondes;
• vervaltijd van request-state;
• annulerings- en weigeringsgedrag;
• validatie van response-schema;
• autorisatiecontroles bij elke retry;
• replay-bescherming;
• idempotentie voor side-effects;
• gedrag wanneer een client de gevraagde capability niet ondersteunt.

Vermijd het voltooien van een aankoop, verwijdering, creditsafschrijving of externe write voordat input_required is geretourneerd.

Gebruik een gefaseerde operatie of idempotency key zodat retries de actie niet kunnen dupliceren. Zie de officiële MRTR-specificatie voor het volledige interactiemodel.

5. Update gateways, caching en autorisatie

De infrastructuurwijzigingen zijn nauw verbonden en moeten samen getest worden.

Valideer MCP-routeringsheaders

Streamable HTTP POST-verzoeken bevatten nu:

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

Met deze headers kunnen gateways verkeer routeren, meten, autoriseren en rate-limiten zonder elke JSON-body te parsen.

Ze kunnen beleidscontroles ondersteunen zoals:

• toolspecifieke rate-limits;
• aparte policies voor list- en execution-methoden;
• toegewijde workerpools voor dure tools;
• beperkte toegang tot risicovolle operaties;
• latency- en foutmetrics per tool;
• toerekening van infrastructuurkosten.

De waarden worden nog steeds door de client aangeleverd. Vergelijk ze met de JSON-RPC-body voordat je beleid toepast.

Een verzoek mag niet kunnen claimen dat het een low-risk tool in Mcp-Name is terwijl het in de body een andere tool aanroept. Mismatches tussen header en body moeten worden afgewezen en gelogd.

Gebruik autorisatiebewuste cachekeys

Het nieuwe protocol voegt ttlMs en cacheScope toe aan cachebare resultaten, waaronder:

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

Een cachekey moet normaal gesproken bevatten:

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

Herbruik geen private cache-entry tussen gebruikers of tenants alleen omdat de TTL nog niet is verlopen.

Deterministische toolordering is ook belangrijk. Een stabiele catalogus voorkomt onnodige cache misses en kan het hergebruik van modelprompt-caches verbeteren wanneer tooldefinities in prompts worden ingevoegd.

Versterk OAuth-issuerafhandeling

Tijdens de autorisatiemigratie:

• valideer een geretourneerde iss-waarde tegen de issuer die voor de flow is vastgelegd;
• sleutel opgeslagen clientcredentials per issuer;
• hergebruik credentials nooit met een andere autorisatieserver;
• stel een passend application_type in tijdens DCR;
• bereid nieuwe integraties voor op Client ID Metadata Documents.

Dynamic Client Registration blijft beschikbaar voor backward compatibility, maar is niet langer de voorkeursregistratiemethode.

6. Migreer notifications, tasks en verouderde features

Het oudere HTTP GET-notificatiepad en de flow resources/subscribe of resources/unsubscribe zijn vervangen door subscriptions/listen.

Clients openen een langlevende POST-responsestream en kiezen de notificatiecategorieën die ze nodig hebben. Verzoekspecifieke voortgangs- en lognotificaties blijven gekoppeld aan de responsestream voor het verzoek dat ze beschrijven.

Gebruik voor multi-instantie-deployments een gedeelde eventbus wanneer notificaties die op de ene serverinstantie worden gegenereerd, een abonnement moeten bereiken dat met een andere is verbonden.

Tasks-extensie

Langdurig werk is verplaatst van het experimentele core-protocol naar:

io.modelcontextprotocol/tasks

De extensie gebruikt:

• tasks/get voor polling;
• tasks/update voor client-naar-serverupdates;
• duurzame task-handles;
• subscriptions/listen voor opted-in updates.

De oudere patronen tasks/result en tasks/list moeten niet worden meegenomen in een nieuwe implementatie.

Verouderde features

De volgende features zijn verouderd:

Verouderde functionaliteit blijft beschikbaar tijdens het uitfaseringsvenster, maar nieuwe implementaties moeten deze niet adopteren. Het MCP-levenscyclusbeleid biedt een minimale uitfaseringsperiode van twaalf maanden; dit betekent niet dat elke feature dezelfde bevestigde verwijderingsdatum heeft.

Bekijk het officiële register van verouderde features voordat je een uitfaseringsdeadline instelt.

7. Rol de migratie veilig uit

Wijzig clients, servers, gateways, caching en autorisatie niet in één onbewaakte release.

Aanbevolen migratievolgorde

1. Inventariseer protocolversies, SDK’s, sessies, SSE-verkeer, DCR-clients en verouderde methoden.
2. Upgrade SDK’s buiten productie.
3. Voeg server/discover en versieonderhandeling toe.
4. Vervang verborgen sessie-afhankelijkheden.
5. Implementeer en beveilig MRTR.
6. Voeg gevalideerde routeringsheaders en gescope­te caches toe.
7. Test autorisatie-issuergrenzen.
8. Rol het moderne protocol via een canary uit naast het legacypad.
9. Schaf ouder gedrag pas af na het beoordelen van telemetrie.

Compatibiliteit tijdens de 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

De release van een nieuwe MCP-specificatie is geen ecosysteem-brede omschakeling. Clients, servers, SDK’s en gehoste platformen migreren met verschillende snelheden.

Telemetrie om vast te leggen

Geslaagde one-shot tools/call-verzoeken zijn niet genoeg om de migratie te meten. Een workflow die herhaaldelijk time-out, onnodige input vraagt of een externe write dupliceert, is nog steeds een productiefout.

Hoe CometAPI past in een MCP-architectuur

MCP vervangt geen model-API. De twee lagen lossen verschillende integratieproblemen op.

Een typische productiearchitectuur ziet er zo uit:

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

MCP standaardiseert hoe agenten met tools en context interacteren. Het standaardiseert niet model­prijzen, providercredentials, inferentie-endpoints of provider-failover.

Deze scheiding is vooral nuttig bij migratie weg van de verouderde Sampling-capability. Als een MCP-server of de consumerende agent nog modelinferentie nodig heeft, kan de applicatie rechtstreeks een model-API aanroepen in plaats van te vertrouwen op de vroegere MCP Sampling-flow.

Wanneer een unified model gateway helpt

Een unified model gateway kan het operationele werk verminderen wanneer:

• meerdere MCP-servers toegang tot verschillende modelproviders nodig hebben;
• verschillende tools verschillende modellen vereisen;
• teams van model willen wisselen zonder providerspecifieke integraties te herschrijven;
• credentials, gebruik en billing centraal moeten worden beheerd;
• modeltoegang onafhankelijk moet blijven van MCP-transportwijzigingen.

CometAPI biedt een OpenAI-compatibele endpoint die kan worden gebruikt als de modeltoegangslaag achter MCP-applicaties. Dit houdt modelproviderlogica gescheiden van MCP-tools, resources en task-orchestratie.

Bijvoorbeeld, een MCP-tool kan een model aanroepen via dezelfde OpenAI-compatibele client die elders in de applicatie wordt gebruikt:

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

De MCP-server blijft verantwoordelijk voor het toolcontract, autorisatie, state en resultverwerking. De modelgateway verzorgt modelselectie, provider-toegang en inferentie­responsen.

Het gescheiden houden van deze lagen biedt twee praktische voordelen:

1. MCP-clients en -servers kunnen naar het nieuwe protocol migreren zonder de modelintegratielaag te wijzigen.
2. Modelproviders kunnen worden veranderd zonder MCP-tools of transportgedrag te herontwerpen.

Voor meer implementatiedetails, zie de CometAPI Quickstart, API-documentatie en de gids voor multi-model AI-applicaties.

MCP 2026-07-28 migratiechecklist

Client

• Upgrade naar een compatibele SDK.
• Schakel moderne versieonderhandeling in.
• Ondersteun server/discover.
• Neem protocolmetadata op in elk verzoek.
• Verwerk resultType.
• Ondersteun MRTR of wijs het expliciet af.
• Gebruik een nieuwe JSON-RPC-ID voor retries.
• Bewaar en retourneer requestState.
• Valideer OAuth-issuers.
• Sla credentials per issuer op.
• Respecteer cachehints.
• Ondersteun subscriptions/listen indien nodig.

Server

• Verwijder initialisatiepoorten voor moderne verzoeken.
• Verwijder afhankelijkheden van Mcp-Session-Id.
• Implementeer server/discover.
• Vervang verborgen state door handles of gedeelde opslag.
• Retourneer resultType.
• Vervang door de server geïnitieerde verzoeken door MRTR.
• Bescherm requestState.
• Valideer alle inputResponses.
• Voeg idempotentie toe voor side-effects.
• Retourneer deterministische lijsten.
• Publiceer conservatieve cachehints.
• Migreer langdurig werk naar de Tasks-extensie.

Gateway en infrastructuur

• Valideer MCP-verzoekheaders.
• Vergelijk headers met de requestbody.
• Verwijder onnodige sticky routing.
• Test verzoeken over meerdere instanties.
• Partitioneer caches per autorisatiegrens.
• Voeg waar nodig een gedeelde notificatiebus toe.
• Volg legacy- en verouderd verkeer.
• Behoud een rollbackpad tijdens de canary.

FAQ

Wat is MCP 2026-07-28?

MCP 2026-07-28 is de Model Context Protocol-specificatie die op 28 juli 2026 is uitgebracht. Het introduceert een stateless protocolkern, Multi Round-Trip-verzoeken, HTTP-routeringsheaders, cachebare resultaten, autorisatiewijzigingen, extensies en een formele uitfaseringslevenscyclus.

Is Mcp-Session-Id verwijderd?

Ja. Het nieuwe Streamable HTTP-protocol gebruikt Mcp-Session-Id niet langer.

Applicaties kunnen nog steeds state behouden via expliciete handles, gedeelde opslag, duurzame taken of beschermde request-statewaarden.

Is de MCP-initialisatie-handshake verwijderd?

Ja. Moderne verzoeken vereisen de uitwisseling initialize en notifications/initialized niet meer.

Servers moeten server/discover implementeren, hoewel clients dit niet voor elke operatie hoeven aan te roepen.

Betekent stateless MCP dat tools geen state kunnen behouden?

Nee. Stateless verwijst naar de protocollaag.

Een tool kan nog steeds state opslaan, maar de verwerking van verzoeken mag niet afhangen van verborgen transportaffiniteit of één specifieke server­process.

Wat is MRTR?

Multi Round-Trip Requests stellen een server in staat extra client- of gebruikersinput te vragen zonder een door de server geïnitieerd verzoek over een continu open, bidirectionele verbinding te sturen.

De server retourneert input_required, en de client retryt de oorspronkelijke operatie met de gevraagde responses.

Is HTTP+SSE onmiddellijk verwijderd?

Nee. Het is verouderd maar niet onmiddellijk verwijderd.

Nieuwe servers moeten Streamable HTTP gebruiken, terwijl bestaande systemen resterend HTTP+SSE-verkeer moeten meten en migreren.

Gebruiken TypeScript SDK v2-clients automatisch MCP 2026-07-28?

Nee. De TypeScript v2 SDK vereist een expliciete configuratie voor versieonderhandeling om het moderne protocol te gebruiken.

Gebruik automatische onderhandeling wanneer de client met zowel moderne als legacyservers moet werken.

Laatste aanbevelingen

MCP 2026-07-28 maakt remote MCP-infrastructuur gemakkelijker te schalen, routeren, cachen en observeren. Het belangrijkste migratierisico is niet simpelweg het verwijderen van een header of handshake. Het is de verborgen applicatiestate en interactielogica die daar nog van afhankelijk kan zijn.

Voordat je het nieuwe protocol uitrolt:

Zoek elke afhankelijkheid van initialisatie en Mcp-Session-Id.

1. Verplaats de vereiste state naar expliciete handles of gedeelde opslag.
2. Implementeer MRTR met verval, replay-bescherming en idempotentie.
3. Valideer MCP-headers tegen de JSON-RPC-body.
4. Partitioneer caches per tenant en autorisatiescope.
5. Versterk OAuth-issuer-validatie.
6. Meet verouderde methoden en legacy-transportverkeer.
7. Rol moderne en legacy-protocolpaden via een canary uit voordat je ze uitfaseert.

Behandel de migratie als een infrastructuurwijziging in plaats van een routinematige SDK-upgrade.

Zodra de MCP-laag stateless en observeerbaar is, houd modeltoegang achter een aparte interface. Zo kunnen het toolprotocol en de modelproviderlaag zich onafhankelijk ontwikkelen.