MCP har vundet — bare ikke over CLI'en

Peter Steinberger sagde sidste år, at de fleste MCP-servere burde have været CLI'er. Han havde ret — og alligevel har MCP vundet.

For et år siden lød en af de skarpeste indvendinger mod Model Context Protocol sådan:

De fleste MCP-servere ville være bedre som CLI'er.

Peter Steinberger formulerede argumentet i overskriften “Free the CLI from its MCP shackles”. Agenter er allerede gode til at kalde kommandolinjeværktøjer. CLI'er kan indlæses efter behov, kædes sammen og testes af både mennesker og maskiner. Hvorfor bruge plads i modellens kontekst på endnu et lag værktøjsdefinitioner?

Det var en god kritik.

Men det var også den forkerte kamp.

MCP skulle ikke slå CLI'en. MCP skulle slå den specialbyggede integration mellem hvert AI-produkt og hvert eksternt system.

Og den kamp ser ud til at være afgjort.

Væksten er til at få øje på

Den 28. august pegede Vercel-stifter Guillermo Rauch på, at MCP vokser eksplosivt. Ikke kun på Vercels egen platform, men også målt på downloads af deres open source-pakke mcp-handler, der bruges til at bygge MCP-servere.

Tallene fra npm understøtter retningen:

mcp-handler · månedlige npm-downloads

Maj–august 2026 · august til og med 29/8

Fra 1,23 mio. i maj til 3,45 mio. i august: +180 %. Kilde: npm downloads API. Downloads er et økosystemsignal, ikke et mål for unikke brugere.

Vercels Josh Soupy skrev samtidig, at antallet af MCP-værktøjskald på Vercel var vokset 564 procent på tre måneder: 43 procent i juni, 117 procent i juli og 114 procent i august.

Og den officielle TypeScript-SDK for MCP? 52,1 millioner npm-downloads på den seneste hele uge og knap 204 millioner på 30 dage.

Man skal være forsigtig med npm-tal. En download er ikke et menneske. CI-kørsler, caches og transitive afhængigheder tæller med. Og Vercels tal for værktøjskald er deres egen oplysning, ikke et offentligt datasæt, vi kan auditere.

Men tre forskellige signaler peger samme vej: flere bygger, flere installerer, og flere kalder MCP-værktøjer i produktion.

Det interessante er ikke længere, om protokollen har fået fodfæste. Det interessante er, hvorfor den fik det.

Steinberger havde ret, når det gælder kodeagenter

Peters argument var — og er — stærkt i et terminalmiljø.

En kodeagent har allerede shell, filer, pipes, exitkoder og scripts. Hvis et værktøj kan beskrive sig selv med --help, levere stabil JSON og opføre sig deterministisk, er en CLI ofte den korteste vej fra intention til handling.

En stor MCP-server kan derimod lægge snesevis af værktøjsdefinitioner ind i konteksten, før de skal bruges. Den kan gøre debugging mere indirekte. Og den kan ende som en dårligere kopi af et modent værktøj, der allerede findes — GitHub MCP versus gh er Peters eget eksempel.

Derfor er rådet stadig godt:

Byg ikke en MCP-wrapper, bare fordi du kan.

Men derfra følger ikke, at MCP er overflødigt. Det følger kun, at MCP ikke altid bør være værktøjets kerne.

Det er en vigtig forskel.

CLI og MCP løser ikke det samme problem

CLI'en er en fremragende grænseflade inde i et udviklingsmiljø.

MCP er en distributionsstandard mellem produkter.

En almindelig bruger i ChatGPT eller Claude.ai har ikke en terminal stående åben. Brugeren gider ikke installere Homebrew, redigere en JSON-fil, holde styr på en lokal proces eller lære argumenterne til fem forskellige kommandoer.

Brugeren ønsker at trykke forbind, godkende adgang og derefter sige:

Find den seneste sag fra kunden, sammenhold den med vores projektplan, og opret de tre manglende opgaver.

Her er MCP ikke et alternativ til shell-scripts. Det er det standardiserede stik mellem samtalen og systemerne bag den.

Vendepunktet er distribution

Anthropic lancerede MCP i november 2024 med lokal understøttelse i Claude Desktop. Allerede i maj 2025 blev det udvidet til remote MCP gennem Claude Integrations på web og desktop. Ved lanceringen kunne brugere koble Claude til ti tjenester som Jira, Confluence, Zapier, Cloudflare, Asana, Sentry, PayPal og Linear. En måned senere var Integrations tilgængeligt på Pro, Max, Team og Enterprise.

OpenAI's nuværende pluginarkitektur går endnu længere. Den officielle dokumentation beskriver plugins som pakker, brugere kan finde, installere, dele og udgive i ChatGPT og Codex. Et plugin kan bestå af skills, en MCP-server eller begge dele. ChatGPT og Codex deler endda ét fælles plugin-directory.

Det er det afgørende skift.

MCP er ikke længere primært noget, en udvikler putter ind i en lokal konfigurationsfil. Det er ved at blive infrastrukturen bag en knap i de AI-produkter, almindelige mennesker allerede bruger.

Når samme server kan forbindes fra Claude, ChatGPT, Codex og andre klienter, slipper leverandøren for at bygge tre integrationer — én til Claude, én til ChatGPT og én til agenterne. Man bygger en MCP-server og lader klienterne konkurrere om brugeroplevelsen.

Sådan bliver standarder til standarder: ikke fordi de altid er den teknisk smukkeste løsning, men fordi de fjerner nok dobbeltarbejde for begge sider af markedet.

Fra protokol til platform

MCP har nu de kedelige ting, som en standard skal have for at blive siddende:

en offentlig specifikation og SDK'er
remote transport over HTTPS
en autorisationsmodel
et officielt registry med standardiseret metadata og namespace-verifikation
en formel governance-model under LF Projects
understøttelse hos konkurrerende AI-platforme

Registret er stadig i preview-fasen, og sikkerhed er fortsat et reelt problem. En standard gør det lettere at forbinde software; den gør ikke automatisk den software troværdig. Dårlige værktøjsbeskrivelser, for brede rettigheder og prompt injection forsvinder ikke, fordi forbindelsen følger en specifikation.

Men det er netop et tegn på modning, at diskussionen har flyttet sig. Vi diskuterer ikke længere kun, hvordan en klient kan starte en lokal proces. Vi diskuterer discovery, OAuth, registries, scopes, UI, enterprise-policy og governance.

Det er platformproblemer.

Den arkitektur, der overlever

Den sjove detalje er, at Peters eget Peekaboo 2.0 næsten beskriver den arkitektur, jeg tror vinder.

Han byggede værktøjet som en Swift-CLI med en tynd TypeScript-wrapper til MCP. Da han ville frigøre funktionaliteten fra en MCP-only tilgang, gjorde han CLI'en til den centrale motor — men beholdt MCP-serveren.

Det er præcis pointen.

Byg en deterministisk kerne, som kan testes og bruges direkte. Giv coding agents adgang via CLI, når det er den bedste lokale grænseflade. Læg et tyndt MCP-lag ovenpå, når værktøjet skal kunne opdages, godkendes og bruges på tværs af ChatGPT, Claude og den næste klient.

Det er ikke CLI eller MCP.

Det er CLI under MCP.

Har MCP så vundet?

Ja — hvis “vundet” betyder, at markedet har valgt et fælles integrationssprog, som konkurrenterne nu bygger distribution, registries og brugeroplevelser ovenpå.

Nej — hvis det betyder, at enhver funktion skal eksponeres som et MCP-værktøj, eller at en MCP-wrapper altid er bedre end en CLI.

Peter havde ret i, at vi gjorde for mange lokale værktøjer til tunge MCP-servere.

Han tog fejl, hvis konklusionen var, at det gjorde selve protokollen irrelevant.

MCP vandt ikke, fordi agenter pludselig blev dårlige til CLI'er.

MCP vandt, fordi normale brugere aldrig skulle lære dem.