Tilbage til Blog
Blog

Hvordan MCP-servere stilfærdigt opæder dit Claude Token Budget – og hvordan du stopper det

Aug 7, 2026·7 min read·Jigar Mehta
#MCP#Claude Code#Token#Budget#Servers
Hvordan MCP-servere stilfærdigt opæder dit Claude Token Budget – og hvordan du stopper det

Forbind fem MCP-servere til Claude Code, skriv ikke noget, og du kan allerede have brugt 50.000 tokens, før modellen har læst en eneste linje af dit prompt. Ingen fejl. Ingen advarsel. Bare en langsommere, dyrere, stilfærdigt dummere session, og de fleste teams finder aldrig ud af hvorfor.

Vi tilbringer meget tid omkring ingeniører, der bygger med Claude Code dagligt, og dette er omkostningsproblemet, der overrasker næsten alle. Ikke fordi det er uklart. Fordi det er usynligt efter design. MCP-servere gør præcis, hvad de skal. Ingen fortalte dig, hvad det koster.

Hvad MCP faktisk indlæser i konteksten

Model Context Protocol (MCP) er Anthropics åbne standard for at forbinde Claude til eksterne værktøjer: GitHub, Slack, databaser, interne API'er, hvad end din stack har brug for. Hver server, du forbinder, registrerer sine værktøjer, og hvert værktøj har et navn, en beskrivelse og et parameterskema. Det er den del, som ingen læser to gange, før de klikker på forbind.

Her er den vigtige del: disse definitioner indlæses i konteksten, og afhængigt af din konfiguration kan denne indlæsning ske ved hver eneste tur, ikke kun en gang ved sessionsstart. En server med to enkle værktøjer koster næsten intet. En server med halvfems koster rigtige penge og rigtig opmærksomhed, uanset om du bruger det i sessionen eller ej.

Spredningen mellem servere er enorm. En minimal SQLite-server kan køre under 500 tokens. Den fulde GitHub MCP-server er derimod blevet uafhængigt målt til cirka 26.000 til 55.000 tokens af værktøjsdefinitioner alene, et sted mellem 13 og 27 procent af et 200.000-token-kontekstvindue, før du har bedt den om at gøre noget.

De to forskellige regninger, du betaler

Det hjælper at dele dette op i to omkostninger, fordi løsningerne er forskellige for hver.

  • Faste omkostninger: værktøjsdefinitionerne selv. Hver forbundet server injicerer navne, beskrivelser og skemaer ved sessionstart. Dette er den del, der overrasker mennesker, fordi den betales, uanset om værktøjerne nogensinde bliver brugt.

  • Variable omkostninger: resultaterne. Hvert værktøjskald returnerer dets fulde output i konteksten, ikke et resumé. En database-forespørgsel med 10.000 rækker, en udvidet logfil, et federe JSON-svar — det hele sidder i vinduet for resten af sessionen, og Claude genlæser hele samtalen ved hver efterfølgende besked. Besked 50 koster mere end besked 5, udelukkende på grund af hvad der kom før.

Forbind tre eller fire servere uden at tænke over nogen af omkostningerne, og det er realistisk at brænde godt over halvdelen af dit kontekstvindue på overhead, før det faktiske arbejde starter.

Hvorfor dette ikke blot er et omkostningsproblem

Token-forbrug er det beløb, der vises på en regning, så det er den del, mennesker bemærker først. Det er ikke den mest skadelige del.

Outputkvaliteten forringes, når for mange værktøjsdefinitioner konkurrerer om modellens opmærksomhed. Teams, der kører tungere MCP-setups, har rapporteret, at modellen begynder at jage irrelevante værktøjer midt i opgaven, og selv er overbevist om at foreslå noget som at oprette et GitHub-problem som fix for en databasetimeout. Flere indlæste værktøjer betyder ikke mere evne. Ud over et vist punkt betyder det, at modellen ræsonnerer over en rodet overflade i stedet for dit faktiske problem.

For en grundlægger eller ingeniørleder omdefinerer dette spørgsmålet. Det er ikke "kan vi tillade os de ekstra tokens?" Det er "Gør vi stilfærdigt hver session værre ved at have otte MCP-servere forbundet, som vi bruger to gange om måneden?"

Løsningen Anthropic allerede har leveret, og dem du stadig ejer

Det gode nyt er, at protokollen selv er udviklet. Anthropic har leveret en værktøjssøgningsfunktion, der udskyder indlæsning af fulde skemaer, indtil et værktøj faktisk er nødvendigt, i stedet for at dumpe hver definition på forhånd. Tidlige resultatrapporter viser, at opstartstokenomkostninger falder med cirka 83 procent, når dette er aktivt, og en meget citeret produktionsmåling gik fra cirka 51.000 tokens overhead ned til 8.500 efter aktivering af det, en reduktion på tæt på 83 procent, uden at omskrive et eneste prompt.

Det er infrastrukturløsningen. Den er ikke universelt aktiveret som standard alle steder endnu, og den erstatter ikke gode vaner.

Fire ting værd at gøre denne uge

  1. Kør /context. Se præcis hvor dine tokens går hen, før du gætter. Dette tager tredive sekunder og overrasker normalt mennesker.

  2. Kontroller dine forbundne servere. De fleste udvikler har tre eller fire MCP-servere indlæst, som de rører ved en gang om ugen. Afbryd dem. Forbind igen, når opgaven faktisk har brug for dem.

  3. Hvideliste værktøjer; indlæs ikke hele servere. Hvis du bruger fem operationer ud af halvtreds på en server, udsæt kun de fem. Dette kan alene reducere en servers overhead med cirka 80 til 90 procent.

  4. Forbehandl før det rammer konteksten. En hook, der greps en 10.000-linjet log for ordet "fejl" og returnerer kun matches. Dette omdanner titusinder af tokens til nogle få hundrede. Claude har ikke brug for høstakken, bare nålen.

OSS: MCP, tokenomkostninger og opbygning af et team, der gør det rigtigt

Sp. Koster det tokens at forbinde en MCP-server, selvom jeg aldrig bruger den i den session?

Ja, i en standardkonfiguration. Værktøjsdefinitionerne indlæses ved sessionstart, uanset om du kalder værktøjet. Udskudt indlæsning ændrer dette, men kun hvor det er aktivt konfigureret.

Sp. Er et større kontekstvindue løsningen på MCP-overhead?

Nej. Et større vindue giver bare overheaden mere plads til at gemme sig. Overheaden er stadig en reel omkostning, og forståelse ved store kontekststørrelser varierer betydeligt mellem modeller, så et fuldt vindue klarer sig sjældent så godt som et magert.

Sp. Hvordan ved vi, hvis en kandidat faktisk forstår dette, i stedet for bare at vide, hvordan man forbinder en server?

Bed dem om at gennemgå en Claude Code-omkostningsrevision, de faktisk har kørt, og hvad de afbrød som følge. Ingeniører, der har ramt et oppustet kontekstvindue i produktion, taler specifikt om hvad de skar. Ingeniører, der ikke har, taler normalt om MCP abstrakt.

Sp. Hvor finder vi ingeniører, der allerede bygger med denne disciplin?

Dette er et af de praktiske signaler, vi leder efter, når vi undersøger udvikler til MyNextDeveloper-kunder, fordi omkostningsbevidst kontekstengineering siger mere om, hvordan en person faktisk arbejder med AI-værktøjer dag efter dag, end en linjer på CV'et om "AI-erfaring" nogensinde gør.

Vigtige takeaways

  • MCP-servere indlæser fulde værktøjsskemaer i konteksten, nogle gange ved hver tur, uanset om værktøjerne bliver brugt eller ej.

  • GitHub MCP-serveren alene er blevet målt til cirka 26.000 til 55.000 tokens overhead, før dit første prompt.

  • Overbelastet kontekst koster ikke blot penge. Det forringer outputkvaliteten, nogle gange synligt.

  • Udskudt værktøjsindlæsning, hvidelister og forbehandlingshooks er de praktiske, tilgængelige løsninger i dag.

  • Kør /context, før du antager, at du ved, hvor dine tokens går hen. De fleste gør det ikke.

Hvorfor det betyder noget

MCP-servere er genuint nyttige, og intet af dette er et argument mod at forbinde dem. Det er et argument mod at forbinde dem og glemme, at de er der. Overheaden er målbar, løsningerne er tilgængelige, og de teams, der ligger forude, er dem, der behandler konteksten som et budget i stedet for en sidegeledanke.

Den slags disciplin vises ikke på et CV, men den vises hurtigt i, hvordan en person faktisk arbejder. Det er præcis den slags dømmekraft, vi skrer for ved MyNextDeveloper, når vi matcher grundlægger med ingeniører, der allerede bygger på denne måde, ikke dem, der stadig lærer det på din regning.

TL;DR

Hver MCP-server, der er forbundet til Claude Code, indlæser sit fulde værktøjsskema i konteksten, nogle gange ved hver tur, uanset om du bruger det eller ej. GitHub MCP-serveren alene er blevet målt til cirka 26.000 til 55.000 tokens overhead, før du har skrevet et eneste prompt. Dette er ikke blot et omkostningsproblem: overbelastet kontekst forringer også outputkvaliteten, nogle gange får modellen til at jage irrelevante værktøjer midt i opgaven. Anthropics udskudte værktøjsindlæsningsfunktion hjælper, men hvidelister af værktøjer, afbrydelse af ubrugte servere og forbehandling af støjende værktøjsoutput er stadig dit ansvar. Kør /context, før du antager, at du ved, hvor dine tokens faktisk går hen.

Leder du efter at opbygge et højtydende fjernteknologiteam?

Tjek MyNextDeveloper, en platform hvor du kan finde de bedste 3 % af softwareingeniører, der er dybt passioneret om innovation. Vores on-demand, dedikerede og grundige softwaretalentløsninger giver en omfattende løsning til alle dine softwarebehov.

Besøg vores websted for at udforske, hvordan vi kan hjælpe dig med at sammensætte dit perfekte team.