MCP er rørleggerarbeid, ikke intelligens

Dette er en teknisk tekst, skrevet for deg som bygger eller skal kjøpe agentløsninger.

Kort oppsummert: MCP er en integrasjonsprotokoll, ikke en agentplattform. Juli-revisjonen løste mye av det som var protokollens ansvar, som sesjoner, ruting og autorisasjon, men ikke det en protokoll aldri kan løse: kontekstkostnad, unødvendige modellrunder og store datamengder gjennom modellen. Bruk MCP som ytre grense, og bygg kjernen selv.

MCP har fått skylden for mye den aldri skulle løse. Jeg har selv vært skeptisk til Model Context Protocol siden jeg først tok det i bruk. Ikke fordi ideen er dårlig, men fordi protokollen lenge gjorde en nødvendig oppgave mer komplisert enn den trengte å være.

Så kom revisjonen 28. juli 2026, som David Soria Parra, en av MCPs hovedvedlikeholdere, kaller den viktigste siden fjern-MCP ble lansert. Den ryddet opp i mye av det jeg hadde vært skeptisk til, men ikke i alt. Bakgrunnen min er todelt: Jeg bygger Capassa, en fintech-plattform med egne AI-agenter, og jeg bistår i tillegg kunder med nettverksinfrastruktur i helsesektoren. Det gir meg to ganske ulike perspektiver på samme protokoll, og begge har gjort meg opptatt av hva som fungerer i produksjon, ikke bare i en demo.

MCP er rørleggerarbeid

MCP gjør ikke en språkmodell smartere. Det er en protokoll basert på JSON-RPC som standardiserer hvordan applikasjoner oppdager og bruker verktøy, ressurser og promptmaler fra eksterne tjenester. Den gjør integrasjoner mer forutsigbare og gir virksomheter et naturlig sted å samle tilgangskontroll, policy og logging, forutsatt at de faktisk bygger kontrollene rundt protokollen. Det er verdifullt, på samme måte som HTTP og OAuth er verdifullt. Men det er rørleggerarbeid. Planlegging, minne, feilhåndtering og orkestrering, mye av det som får en agent til å fungere, kommer ikke av at den bruker MCP. Det må bygges i systemet rundt.

Mye av skuffelsen jeg har hørt rundt MCP skyldes at folk forventet intelligens fra et rør. Derfor er det nyttig å skille mellom det som er protokollens ansvar og det som er ditt: Protokollen kan fikses, men agentdesign er ditt ansvar. Mitt standpunkt i én setning: MCP er riktig som ytre grense, men sjelden det beste utgangspunktet for den indre kjernen i en agent du selv kontrollerer.

Det protokollen kunne fikse, og som juli faktisk fikset

Noen av innvendingene mine handlet om protokollen selv. Sesjoner: Tidligere versjoner krevde et initialize-håndtrykk, og i Streamable HTTP kunne serveren tildele en Mcp-Session-Id som klienten måtte sende med senere forespørsler (spesifikasjonen fra november 2025). Den var ikke obligatorisk, men når den holdt tilstand, måtte man ta hensyn til ruting og lagring på tvers av serverinstanser, og det er mer kompleksitet enn jeg ønsker i et system som skal skaleres horisontalt. Autorisasjon: OAuth-støtten var et viktig skritt, men det var krevende å få klientregistrering, identitet og tilgangskontroll til å fungere godt sammen. Dynamic Client Registration (DCR) er ikke i seg selv en sikkerhetsfeil, for registrering gir ikke automatisk tilgang, men det er en komponent som må håndteres riktig, og i regulerte miljøer er slike detaljer helt avgjørende.

Juli-revisjonen gjorde kjernen i MCP statsløs og fjernet flere av de praktiske hindringene ved drift i større skala. Dette er endringene jeg mener betyr mest:

To detaljer er spesielt interessante. Den ene er anbefalingen om eksplisitte håndtak: Hvis en tjeneste må bevare tilstand mellom kall, kan den returnere en identifikator som agenten sender med neste gang. Det er bedre enn tilstand som er skjult i transporten, både for feilsøking og for agentens mulighet til å holde rede på arbeidsflyten. Den andre er at de fire utviklerbibliotekene (SDK-ene) på høyeste støttenivå, Tier 1, for TypeScript, Python, Go og C#, hadde støtte for den nye versjonen ved lansering. En spesifikasjon er lite verdt dersom verktøyene rundt den ikke henger med. Detaljene står i utgivelsesinnlegget og endringsloggen.

Det en protokoll aldri kan løse

Andre innvendinger handler ikke om protokollen, og ingen revisjon løser dem. Tre utfordringer ligger hos den som bygger agenten.

Kontekstkostnaden forsvinner ikke. Når en agent presenterer mange verktøydefinisjoner for modellen samtidig, tar de plass i kontekstvinduet: Tjue servere med femti verktøy hver gir potensielt tusen definisjoner, og det kan koste både tokens, tid og presisjon. Mellomlagring reduserer gjentatte katalogoppslag, men ikke nødvendigvis mengden verktøyinformasjon som sendes til modellen. Et stort verktøylandskap må fortsatt kurateres, søkes i eller lastes dynamisk.

Unødvendige modellrunder er fortsatt dyre. MCP tvinger ikke alle operasjoner gjennom en ny modellbeslutning, og klienter kan gjøre flere kall programmatisk. Men hvis en agent lar modellen planlegge hvert eneste delsteg i en prosess på tretti trinn, blir løsningen fort treg, kostbar og sårbar for feil. Mange av disse stegene bør være vanlig programlogikk.

Modellen er en dårlig kanal for store datamengder. For et regnskap med 40 000 bilag eller en nettverkstopologi med 3 000 noder er det sjelden fornuftig å sende rådata gjennom modellen. Den trenger relevante avvik, nøkkeltall og forklaringer, ikke hvert bilag eller hver konfigurasjonslinje. En agent kan ha tilgang til hele regnskapet, men spørsmålet er hva som skjer med dataene underveis: Skal 40 000 bilag gjennom språkmodellen, eller skal kode filtrere dem først og gi modellen bare avvikene? Det kan løses med verktøy som filtrerer på serversiden, direkte API-kall eller kontrollert kodeeksekvering. Poenget er ikke at MCP forbyr slike løsninger, men at MCP heller ikke erstatter dem. Det er samme tankegang som i KI kan gi et perfekt svar. På feil tall.: Det er ikke tilgangen til data som avgjør, men at modellen får riktig informasjon i riktig sammenheng.

Jeg er ikke alene om dette synet. Anthropic beskriver nøyaktig samme problem i «Code execution with MCP», der mellomresultater blir værende i et kjøremiljø i stedet for å passere modellen, og i deres eget eksempel falt tokenbruken fra 150 000 til 2 000. Cloudflare har kommet frem til det samme under navnet Code Mode. Anthropic er også ærlig om prisen: Kode som agenten skriver må kjøres i en sikker sandkasse med ressursgrenser og overvåking, og det er driftskostnader som direkte verktøykall slipper. At Roots, Sampling og Logging nå er deprekert, tolker jeg som et signal om at vedlikeholderne ønsker en tydeligere grense mellom protokoll og agentlogikk. Det er en fornuftig retning. MCP trenger ikke å være hele agentplattformen for å være nyttig.

Er du kjøper og ikke bygger, er poenget det samme: Antallet integrasjoner en KI-løsning har, sier lite om hvor pålitelig den er. Spør ikke hvor mange systemer den kobles til, men hva den gjør med dataene på veien, og hvem som kontrollerer det.

Mitt standpunkt i praksis

Bruk MCP når du skal eksponere funksjonalitet til klienter og miljøer du ikke styrer: Claude, Copilot, kunders egne agenter eller andre avdelingers systemer, og når standardisert oppdagelse av verktøy og et felles integrasjonspunkt gir reell verdi. Med en statsløs protokollkjerne og en mer moden autorisasjonsmodell passer MCP nå langt bedre bak eksisterende gateway, WAF og identitetsinfrastruktur, selv om sikkerheten aldri kommer gratis med protokollen.

Ikke bruk MCP automatisk mellom din egen agent og alle dine egne tjenester. Direkte funksjonskall, vanlige API-er og et tynt orkestreringslag vil ofte være enklere å drifte og feilsøke, og når datamengdene krever det, bør beregningene utføres utenfor modellen, med tydelige tilgangsgrenser og sporbarhet.

Det gir en enkel arbeidsdeling: MCP utad, der andre AI-klienter skal få tilgang, og direkte tjenestekall innad, der kode tar den tunge databehandlingen. MCP blir inngangen til kapasitetene, ikke motoren som styrer dem. Bygger du nye integrasjoner, ville jeg valgt 2026-07-28 og planlagt migrering av eldre implementasjoner. Deprekerte funksjoner har et minimumsvindu på tolv måneder, men det er liten grunn til å bygge nye avhengigheter til mekanismer protokollen er på vei bort fra.

Til slutt

Skepsisen min var berettiget, men den er mindre nå. Juli-revisjonen viser et prosjekt som er villig til å gjøre brytende endringer for å rette grunnleggende svakheter, og det er et godt tegn. Det som står igjen, er ikke nødvendigvis feil ved MCP. Det er grensene for hva en integrasjonsprotokoll bør gjøre. Forstår du de grensene, kan MCP bli en viktig del av en robust agentarkitektur. Forventer du intelligens fra et rør, blir du skuffet igjen.