MCP eller CLI: to måder at give AI adgang til jeres systemer
Byg MCP, når forbindelsen skal leve længere end agenten. Giv agenten en shell, når agenten selv er forbindelsen.
MCP og CLI er to måder at give en AI-agent adgang til jeres systemer. MCP er en struktureret protokol: typede værktøjer, styret adgang, en liste enhver kompatibel klient kan slå op i. CLI er shell-adgang, altså bash og de samme kommandoer, en udvikler i forvejen bruger. MCP skalerer på tværs af hold. CLI er billigere i tokens. De fleste opsætninger bruger begge dele.
Valget, ingen tager
Før eller siden rammer ethvert AI-projekt den samme forgrening: hvordan rører modellen egentlig ved de systemer, den skal arbejde i.
De fleste artikler springer direkte til MCP. Protokollen er ny, og der bliver talt højere om den. Den anden vej, at give agenten en shell og de kommandolinjeværktøjer, jeres udviklere allerede bruger, er ældre, har ingen kampagne bag sig og er tit den bedre. Anthropic byggede selv Claude Code på det princip. Værktøjskassen består af Read, Write, Edit, Bash, Glob, Grep og en håndfuld til (Anthropic engineering, »Building agents with the Claude Agent SDK«). Ingen MCP nødvendig for at komme i luften.
Kender man kun den ene mulighed, ender man enten med at overbygge eller med at slække på styringen. Vælg i stedet fra integration til integration.
Hvad MCP er
MCP (Model Context Protocol) er et typet lag mellem en agent og et system. Systemets operationer bliver til navngivne værktøjer med et defineret input og et defineret output.
I bygger en MCP-server én gang til jeres CRM eller jeres dokumentarkiv, registrerer den i en hvilken som helst MCP-klient (Claude, ChatGPT, Gemini, Cursor, VS Code), og agenten får en liste, den kan slå op i. Hvert værktøj har sit eget skema. Protokollen står for login, transport og opdagelse, så modellen slipper for det.
Grundlaget har vi skrevet om før, i vores artikel om, hvad MCP er. Til denne sammenligning er det formen, der tæller. MCP er vejen, når en integration skal kunne styres, genbruges på tværs af hold eller stilles til rådighed for klienter, der intet ved om jeres miljø.
Hvad »giv AI'en en CLI« betyder
CLI-adgang vil sige, at agenten kører kommandoer i en shell: bash, curl, grep, git, gh, psql. Samme ordforråd som en udvikler på sin egen maskine.
Der er intet skema. Agenten læser man-siden, kører --help, prøver et kald og læser svaret. Findes værktøjet ikke, installerer den det. Skal tre værktøjer kædes sammen, piper den dem. Anthropics egen formulering fra Claude Agent SDK-artiklen: »Claude needs the same tools that programmers use every day.« Filsystemet bliver i sig selv til kontekst. Logfiler bliver undersøgt med grep og tail i stedet for at blive hældt ind i modellen.
Det ligner mere den måde, mennesker arbejder på, end den måde API'er er tegnet på. Det er hele pointen.
Hvor MCP vinder
MCP vinder, når integrationen går på tværs af hold, skal kunne styres, eller skal overleve at agenten bliver skrevet om.
Tre konkrete tilfælde. Udbredelse: en MCP-server, der er sat op én gang, kan bruges af alle på holdet fra enhver understøttet klient, uden opsætning hos den enkelte (systemprompt.io's vejledning til Claude Code). Tilstand: forbindelsespuljer til databaser, OAuth-sessioner med refresh-tokens, WebSocket-abonnementer. Kald fra en shell er som udgangspunkt tilstandsløse. MCP kan holde en session åben. Sikkerhed: typede input og output gør det læsbart, hvad en agent må. I kan skrive »læseadgang til de her tre værktøjer, skriveadgang til ingen« og revidere det bagefter.
Bloomberg, Block og Amazon gik internt MCP-først af netop de grunde. Block byggede alene 60 interne MCP-servere (ifølge Anthropics egne artikler). Skal de samme data nå mange agenter på mange hold, er MCP den billigste vej i år to, også selv om den er den langsomste i uge et.
Hvor CLI vinder
CLI vinder, når værktøjet allerede findes, agenten har en shell, og I ikke har brug for mere styring, end shellen selv håndhæver.
Tokens er det første argument. Udvikleren Mario Zechner satte de to op mod hinanden i august 2025: GitHubs CLI brugte markant mindre kontekst end GitHubs MCP-server til den samme opgave. Armin Ronacher kørte samme sammenligning og nåede samme resultat. gh kom hurtigere frem til svaret, brugte mindre kontekst og var lettere at fejlsøge end MCP-udgaven. I sin opfølgning skrev han, at en MCP med tredive værktøjer som regel burde være ét værktøj, der kører kode.
Anthropic udgav en version af det samme argument i november 2025. Artiklen »Code execution with MCP« beskriver et arbejdsforløb, der brugte omkring 150.000 tokens, når værktøjerne blev kaldt direkte, og omkring 2.000 tokens, da agenten fik et filsystem og selv skrev den kode, der kaldte de samme MCP-servere. En reduktion på 98,7 % (Anthropic, 4. november 2025).
- tokens, da agenten kaldte værktøjerne direkte150.000
- tokens for det samme arbejde skrevet som kode2.000
- mindre kontekst for det samme resultat98,7 %
Pointen er ikke, at MCP var forkert. Pointen er, at det som regel betaler sig at skubbe arbejdet ned i kode, ofte shell-kode, frem for at sende hvert mellemresultat gennem modellen.
CLI vinder også de korte enkeltopgaver: hent et endpoint med curl, grep en log, kør en git-kommando, læs en fil. At bygge en MCP-server til den slags er en udgift, et hold på fem aldrig skal betale.
Byttehandlen på én linje
MCP er det, I bygger, når integrationen skal leve længere end agenten. CLI er det, I griber, når agenten selv er integrationen.
Det er den linje, vi bruger hos Ellypsis, når en kunde spørger. Skal den samme forbindelse være til rådighed for en salgsagent i dag, en supportagent til næste kvartal og en indkøbsagent til næste år, så MCP. Skal én agent tale med ét system i ét forløb, og har systemet allerede et fungerende kommandolinjeværktøj, så shell.
En anden prøve virker lige så godt. Kan den, der bygger integrationen, ikke sige på én sætning, hvilken styring der bliver håndhævet, er MCP den sikreste vej, også selv om den er langsommere.
Sådan ser det ud i en mellemstor virksomhed
I en virksomhed med 50 til 200 ansatte er svaret sjældent rent MCP eller rent CLI. Det er som regel begge dele, med en klar deling.
Agenter, der kun arbejder indenfor, kører i et afgrænset miljø, og de værktøjer, de skal bruge, findes allerede som kommandolinjeværktøjer: git, psql, curl, leverandørernes egne værktøjer, virksomhedens egne scripts. Vi giver agenten en shell, afgrænser mappen og lader den arbejde. Der går timer, fra den bliver sat op, til den leverer noget brugbart.
Integrationer, der går på tværs af hold eller ud til leverandører, går gennem MCP. CRM'et. ERP'et. Dokumentarkivet. Det er de systemer, hvor syv forskellige agenter før eller siden vil have adgang, hvor et revisionsspor betyder noget, og hvor et typet lag er byggeprisen værd. Vi bygger MCP-serveren én gang, registrerer den i alle relevante klienter og behandler den som infrastruktur, der skal holde.
Én ting er værd at sige højt: spørgsmålet er sjældent »MCP eller CLI« i det abstrakte. Det er, hvilke integrationer der er MCP-investeringen værd, og hvilke der klarer sig fint med et kald i en shell. De fleste opsætninger rammer forkert ved at gå helt ud i den ene grøft.
Vil I have grundlaget først: vores artikel om, hvad MCP er
Erstatter MCP kommandolinjeværktøjer for AI-agenter?
Nej. MCP og CLI løser overlappende, men forskellige problemer. MCP giver typet og styret adgang på tværs af klienter. CLI giver agenten shell-adgang med det samme, med værktøjer der allerede findes. Anthropics egen Claude Code har både bash og en lille indbygget værktøjskasse ved siden af MCP-understøttelsen. De fleste opsætninger i drift bruger begge dele.
Hvornår skal en lille virksomhed bygge en MCP-server frem for at bruge en CLI?
Byg MCP, når den samme integration skal betjene flere agenter, flere hold eller AI-klienter uden for jeres eget miljø, og når styringen betyder noget: typede rettigheder, revisionsspor, OAuth. Brug CLI, når én agent skal have fat i et system, der allerede har et fungerende kommandolinjeværktøj. For de fleste førstegangsopsætninger er CLI hurtigst til værdi.
Hvorfor udgiver Anthropic artikler, der lyder som argumenter mod MCP?
Anthropics artikel fra november 2025, 'Code execution with MCP', er ikke imod MCP. Den handler om, at det er spild at læsse alle værktøjsdefinitioner ind i konteksten og sende hvert resultat gennem modellen. I deres eget eksempel faldt et arbejdsforløb fra 150.000 til 2.000 tokens, da agenten i stedet selv skrev koden, der kaldte MCP-serverne.
Er det farligt at give en AI shell-adgang?
Shell-adgang er en risiko og kræver afgrænsning. Agenten kan køre alt, hvad shellen kan køre. God praksis: kør agenten i en container, en VM eller et isoleret arbejdsområde, giv den mindst mulig adgang til filsystemet, kræv godkendelse af kommandoer, der sletter eller ændrer, og log hver eneste kommando. Claude Code er bygget sådan som standard. MCP flytter noget af det over i typede rettigheder, men disciplinen er den samme.
Bruger MCP altid flere tokens end CLI?
Ofte, men ikke altid, og afstanden bliver mindre. En opsætning med flere MCP-servere læsser værktøjsdefinitionerne ind på forhånd og betaler en kontekstpris, før agenten går i gang. Den udgift har CLI ikke. Anthropics Tool Search, der kom i beta i november 2025, henter definitionerne efter behov og skærer prisen betydeligt ned. Sammenlign per arbejdsforløb, ikke per protokol.