MCP 2026-07-28 spec: AgentCore Gateway

Jeg har set den hidtidige MCP-arkitektur skabe nok problemer til at genkende mønsteret med det samme. Hver forbindelse mellem en agent og en MCP-server skulle holde en session i live, ofte via en vedvarende SSE-forbindelse. Det virker fint til udvikling og mindre opsætninger, men det skalerer dårligt. En server, der skal huske tilstanden for tusindvis af samtidige agent-sessioner, bliver et flaskehalspunkt, og enhver netværksafbrydelse tvinger klienten til at genopbygge hele sessionen fra bunden.

Med 2026-07-28-specifikationen bliver selve protokollen statsløs. Hvert kald bærer nu den kontekst, det har brug for, i stedet for at læne sig op ad en server, der husker samtalens historik. Det betyder, at en MCP-server kan skaleres horisontalt uden delt tilstand, og at en agent kan skifte server midt i en opgave uden at miste kontekst. I praksis flytter man ansvaret for kontinuitet fra infrastrukturen til protokollen selv, og det er den type ændring, jeg først mærker, når jeg forsøger at drifte noget i stor skala.

Jeg har altid oplevet MCP som en relativt smal protokol: værktøjer, ressourcer og prompts, defineret ret stramt. Den nye specifikation introducerer et formelt extensions-system, hvor leverandører kan tilføje kapaciteter uden at bryde kompatibiliteten med klienter, der ikke kender dem. En agent, der taler ren MCP, kan stadig arbejde mod en server med extensions, den ikke forstår, fordi extensions er opt-in og selvbeskrivende.

Det åbner for noget, jeg allerede ser efterspørgsel efter blandt danske virksomheder: specialiserede branchespecifikke MCP-servere, der tilbyder domænespecifik funktionalitet, uden at det kræver en ny protokolversion hver gang nogen vil bygge noget nyt. En sundhedsvirksomhed kan tilføje compliance-metadata som extension, en finansvirksomhed kan tilføje transaktionssporing, og ingen af delene tvinger resten af økosystemet til at opdatere.

Autorisationslaget har været et af de svageste punkter i MCP siden starten. Tidlige implementeringer lod ofte token-håndtering være op til den enkelte klient, hvilket gav inkonsistent sikkerhedspraksis på tværs af værktøjer. 2026-07-28-specifikationen strammer det markant: token-scoping er nu en del af selve protokollen, ikke en implementeringsdetalje, og en server kan kræve, at et kald bærer et token med præcis de rettigheder, kaldet reelt har brug for.

Det lyder som et teknisk detaljepunkt, men det er faktisk kernen i, om jeg tør lade en agent få adgang til produktionssystemer. Når jeg sætter en agent op til at røre rigtige data, er token-scoping det første, jeg selv graver i, før jeg lader den røre noget som helst. En strammere protokolstandard for token-scoping gør den vurdering markant nemmere, fordi svaret ikke længere afhænger af, hvordan den enkelte leverandør har valgt at implementere det.

Det mest praktiske ved denne opdatering, set fra min stol, er hvor lidt den kræver af eksisterende brugere. AgentCore Gateway understøtter allerede 2026-07-28-specifikationen, og opgraderingen fra en tidligere protokolversion sker via ét enkelt API-kald, der peger gatewayen mod den nye spec-version. Der er ingen ny infrastruktur at rulle ud, og ingen af de eksisterende MCP-serverforbindelser skal genopsættes manuelt.

Det er en bevidst designbeslutning fra AWS' side: gatewayen fungerer som oversættelseslag mellem klient og server, så en agent kan tale den nyeste protokolversion, selv om en given MCP-server endnu ikke er opdateret, og omvendt. For teams, der allerede har bygget agenter oven på AgentCore, betyder det, at man kan tage de nye statsløse fordele i brug uden at vente på, at hver enkelt integration bliver opdateret først.

Den gode nyhed er, at bagudkompatibiliteten er tænkt ind fra start. Eksisterende MCP-servere, der endnu ikke understøtter 2026-07-28-specifikationen, fortsætter med at virke gennem gatewayens oversættelseslag. Man behøver altså ikke opdatere alle sine værktøjsintegrationer på én gang for at få gavn af opgraderingen på gateway-niveau.

Der, hvor man reelt bør handle, er hvis man selv drifter MCP-servere med høj samtidighed. Her giver den statsløse protokol en reel driftsgevinst: man kan skalere serverne horisontalt uden at bygge delt tilstand eller sticky sessions ind i infrastrukturen. Og hvis man arbejder med agenter, der har adgang til følsomme data, er det værd at gennemgå, om ens token-scoping allerede matcher den strammere autorisationsmodel, eller om det er en opgave, der skal løftes, når man opgraderer. Det er den slags opgradering, jeg selv holder øje med. Ikke fordi den ændrer noget i morgen, men fordi den bestemmer, hvad der holder den dag belastningen stiger, eller sikkerhedskravene skærpes.