Tillbaka till blogg
Blogg

Hur MCP-servrar tyst äter upp din Claude-tokenbudget och hur du stoppar det

Aug 7, 2026·7 min read·Jigar Mehta
#MCP#Claude Code#Token#Budget#Servers
Hur MCP-servrar tyst äter upp din Claude-tokenbudget och hur du stoppar det

Anslut fem MCP-servrar till Claude Code, skriv ingenting, och du kan redan ha använt 50 000 tokens innan modellen har läst en enda rad av din prompt. Ingen felmeddelande. Ingen varning. Bara en långsammare, dyrare och tystare dummere session, och de flesta team får aldrig reda på varför.

Vi tillbringar mycket tid tillsammans med ingenjörer som bygger med Claude Code dagligen, och det här är kostnadproblemet som överraskar nästan alla. Inte för att det är dunkelt. För att det är osynligt genom design. MCP-servrar gör exakt det de ska göra. Ingen berättade för dig vad det kostar.

Vad MCP faktiskt laddar in i kontext

Model Context Protocol (MCP) är Anthropics öppna standard för att ansluta Claude till externa verktyg: GitHub, Slack, databaser, interna API:er, vad din stack än behöver. Varje server du ansluter registrerar sina verktyg, och varje verktyg levereras med ett namn, en beskrivning och ett parameterschema. Det där är delen som ingen läser två gånger innan man klickar på anslut.

Här är delen som spelar roll: dessa definitioner laddas in i kontext, och beroende på din konfiguration kan denna inladdning ske på varje enskild sväng, inte bara en gång i början av sessionen. En server med två rena verktyg kostar nästan ingenting. En server med nittio kostar riktiga pengar och riktigt engagemang, oavsett om du använder den denna session eller inte.

Spridningen mellan servrar är enorm. En minimal SQLite-server kan köras under 500 tokens. Den fullständiga GitHub MCP-servern har däremot oberoende mätts till ungefär 26 000 till 55 000 tokens med bara verktygsdefiniioner, någonstans mellan 13 och 27 procent av ett 200 000-tokens kontextfönster, innan du ens har bett den göra något.

De två olika räkningarna du betalar

Det hjälper att dela upp detta i två kostnader eftersom lösningarna är olika för varje.

  • Fast kostnad: själva verktygsdefiniitionerna. Varje ansluten server injicerar namn, beskrivningar och scheman vid sessionstart. Det här är delen som överraskar folk, för den betalas oavsett om verktygen någonsin används.

  • Rörlig kostnad: resultaten. Varje verktyganrop returnerar sin fullständiga utmatning in i kontexten, inte en sammanfattning. En databasfråga med 10 000 rader, en omfattande loggfil, ett uppsvällt JSON-svar — allt sitter i fönstret för resten av sessionen, och Claude läser hela konversationen på nytt vid varje efterföljande meddelande. Meddelande 50 kostar mer än meddelande 5, rent och bart på grund av vad som kom före det.

Anslut tre eller fyra servrar utan att tänka på någon av dessa kostnader, och det är realistiskt att bränna långt över hälften av ditt kontextfönster på overhead innan det faktiska arbetet börjar.

Varför det här inte bara är ett kostnadsproblem

Tokenutgifter är beloppet som visas på en faktura, så det är delen folk märker först. Det är inte den mest skadliga delen.

Utmatningskvaliteten försämras när för många verktygsdefiniitioner konkurrerar om modellens uppmärksamhet. Team som kör tyngre MCP-konfigurationer har rapporterat att modellen börjar jaga irrelevanta verktyg mitt i uppgiften, tryggt föreslå något som att skapa ett GitHub-problem som lösningen på en databastimeout. Fler inladdade verktyg betyder inte mer kapacitet. Efter en viss punkt betyder det att modellen resonerar över en rörig yta istället för ditt faktiska problem.

För en grundare eller teknikledare omformuleras frågan. Det är inte "kan vi tillåta oss de extra tokens?" Det är "Gör vi tyst varje session sämre genom att lämna åtta MCP-servrar anslutna som vi använder två gånger i månaden?"

Lösningen som Anthropic redan skickade, och de som du fortfarande äger

De goda nyheterna är att själva protokollet har utvecklats. Anthropic skickade en sökfunktion för verktyg som skjuter upp inladdningen av fullständiga scheman tills ett verktyg faktiskt behövs, istället för att dumpa varje definition direkt. Rapporterade tidiga resultat visar att startkostnad för tokens sjunker med ungefär 83 procent när detta är aktivt, och en allmänt citerad produktionsmätning gick från ungefär 51 000 tokens overhead ner till 8 500 efter aktivering av den, en minskning på nästan 83 procent, utan att skriva om en enda prompt.

Det är infrastrukturlösningen. Den är inte universellt påslagen överallt ännu, och den ersätter inte goda vanor.

Fyra saker som är värda att göra denna vecka

  1. Kör /context. Se exakt var dina tokens går innan du gissar. Det här tar trettio sekunder och överraskar vanligtvis folk.

  2. Granska dina anslutna servrar. De flesta utvecklare har tre eller fyra MCP-servrar inladdade som de touchar en gång i veckan. Koppla från dem. Anslut igen när uppgiften faktiskt behöver dem.

  3. Vitlistning av verktyg; ladda inte hela servrar. Om du använder fem operationer av femtio på en server, exponera bara de fem. Detta ensamt kan skära en servers overhead med ungefär 80 till 90 procent.

  4. Förbehandle innan det når kontexten. En hook som grep:ar en 10 000-rads logg för ordet "error" och returnerar bara matchningar. Det här förvandlar tiotusentals tokens till några hundra. Claude behöver inte höet, bara nålen.

FAQ: MCP, Tokenkostnader och Building a Team That Gets This Right

F. Kostar det tokens att ansluta en MCP-server även om jag aldrig använder den denna session?

Ja, i en standardkonfiguration. Verktygsdefiniitionerna laddas in vid sessionstart oavsett om du anropar verktyget. Uppskjuten inladdning ändrar detta, men bara där det är aktivt konfigurerat.

F. Är ett större kontextfönster lösningen för MCP-overhead?

Nej. Ett större fönster ger bara overhead mer plats att gömma sig. Overheaden är fortfarande en verklig kostnad, och förståelse vid stora kontextstorlekar varierar betydligt mellan modeller, så ett fullt fönster presterar sällan lika bra som ett magert.

F. Hur vet vi om en kandidat verkligen förstår det här, jämfört med bara att veta hur man ansluter en server?

Be dem att gå igenom en Claude Code-kostnadsrevision de faktiskt har kört och vad de kopplade från. Ingenjörer som har träffat ett uppsvällt kontextfönster i produktion talar specifikt om vad de skär bort. Ingenjörer som inte har gör det tenderar att tala om MCP abstrakt.

F. Var hittar vi ingenjörer som redan bygger med denna disciplin?

Det här är en av de praktiska signalerna vi letar efter när vi granskar utvecklare för MyNextDeveloper-klienter, för kostnadsmedveten kontextinjöring säger mer om hur någon faktiskt arbetar med AI-verktyg dag för dag än en resumerad rad om "AI-erfarenhet" någonsin kommer att göra.

Nyckelresultat

  • MCP-servrar laddar fullständiga verktygsscheman in i kontexten, ibland på varje sväng, oavsett om verktygen används eller inte.

  • GitHub MCP-servern ensam har uppmätts mellan ungefär 26 000 och 55 000 tokens overhead innan din första prompt.

  • Överbelastat sammanhang kostar inte bara pengar. Det försämrar utmatningskvaliteten, ibland synligt.

  • Uppskjuten verktygsbelastning, vitlistning och förbehandlingskrokar är de praktiska, tillgängliga lösningarna idag.

  • Kör /context innan du antar att du vet var dina tokens går. De flesta gör det inte.

Varför det spelar roll

MCP-servrar är genuint användbara, och ingenting av detta är ett argument mot att ansluta dem. Det är ett argument mot att ansluta dem och glömma bort att de finns där. Overheaden är mätbar, lösningarna är tillgängliga, och de team som drar iväg är de som behandlar kontexten som en budget istället för en efterhandstanke.

Den sortens disciplin visas inte på ett CV, men det visas snabbt i hur någon faktiskt arbetar. Det är exakt den sortens omdöme vi granskar på MyNextDeveloper när vi matchar grundare med ingenjörer som redan bygger på det här sättet, inte de som fortfarande lär sig det på din bekostnad.

TL;DR

Varje MCP-server ansluten till Claude Code laddar sitt fullständiga verktygsschema in i kontexten, ibland på varje sväng, oavsett om du använder den eller inte. GitHub MCP-servern ensam har uppmätts mellan ungefär 26 000 och 55 000 tokens overhead innan du har skrivit en enda prompt. Det här är inte bara ett kostnadsproblem: överbelastat sammanhang försämrar också utmatningskvaliteten, ibland causing modellen jaga irrelevanta verktyg mitt i uppgiften. Anthropics uppskjutna verktygladdningsfunktion hjälper, men vitlistning av verktyg, frånkoppling av oanvända servrar och förbehandling av bullrig verktygsutmatning ligger fortfarande på dig. Kör /context innan du antar att du vet var dina tokens faktiskt går.

Vill du bygga ett högpresterande fjärrteam?

Kolla in MyNextDeveloper, en plattform där du kan hitta de bästa 3% av mjukvaruingenjörer som är djupt passionerade för innovation. Våra on-demand, dedikerade och grundliga mjukvaru-talentlösningar ger en omfattande lösning för alla dina mjukvaru behov.

Besök vår webbplats för att utforska hur vi kan hjälpa dig att samla ditt perfekta team.