Verktygsöverbelastning är ett upptäcktsproblem.

Konsensusen kom snabbt, och den låter rätt: för många verktyg gör en agent sämre. Anthropics egen dokumentation sätter en siffra på det — en modells förmåga att välja rätt verktyg försämras när du överskrider 30 till 50 tillgängliga verktyg. Munin exponerar mer än 200 på en enda ändpunkt. Enligt den aritmetiken ägnade vi ett år åt att bygga exakt det branschen just lärt sig att inte bygga.

Jag tror att aritmetiken mäter fel objekt. Antalet är en egenskap hos katalogen. Försämringen är en egenskap hos vad en klient väljer att ladda in i kontextfönstret. De var samma siffra i två år, vilket är varför alla började behandla dem som en sak. 2026 gick de isär, och den intressanta designfrågan flyttade med dem.

Gör för många MCP-verktyg en AI-agent sämre?

Ja — när klienten laddar in varenda verktygsdefinition i förväg. Anthropics dokumentation om verktygssökning sätter noggrannhetströskeln vid 30 till 50 tillgängliga verktyg, och noterar att en uppsättning med fem servrar över GitHub, Slack, Sentry, Grafana och Splunk kan sluka runt 55 000 tokens i definitioner innan modellen läst förfrågan. Felet ligger i ivrig laddning, inte i katalogens storlek.

Den skillnaden är ingen debattpoäng, för fixen har redan levererats. Verktygssökningsverktyget låter en server märka definitioner med defer_loading: true; modellen söker sedan i namn, beskrivningar, argumentnamn och argumentbeskrivningar, och API:et expanderar bara det som kommer tillbaka. Anthropics dokumentation rapporterar att detta typiskt skär definitionsöverhuvudet med mer än 85 procent, genom att ladda de tre till fem verktyg en given förfrågan faktiskt behöver, och slår fast att urvalsnoggrannheten ”förblir hög även över tusentals verktyg”. Taket per förfrågan är 10 000 uppskjutna verktyg.

Den andra fixen är äldre och trubbigare. I Code execution with MCP, publicerad i november 2025, presenterade Anthropic verktygskataloger som filer en agent kan läsa vid behov, och mätte ett arbetsflöde som föll från 150 000 tokens till 2 000 — en minskning på 98,7 procent. Cloudflare nådde samma slutsats självständigt och kallade det Code Mode. Två team, två implementationer, en insikt: sluta betala för definitioner du inte använt ännu.

Varför exponerar Munin 200-något MCP-verktyg i stället för ett dussin?

För att de 200-något verktygen är primitiver, inte arbetsflöden. crm_create_contact, conv_send_message, cms_update_entry, kb_search — vart och ett gör en sak med en sorts post, och namnet säger vilken modul som äger det. En katalog av primitiver är stor och förutsägbar. En katalog av arbetsflöden är liten tills någon vill ha en kombination ingen förutsåg, och sedan växer den för alltid.

Den ärliga delen av detta: tvåhundra definitioner är mer än någon enskild konversation behöver, och en klient som laddar alla ivrigt slösar kontext på verktyg den sessionen aldrig kommer att anropa. Det är en verklig kostnad och jag tänker inte låtsas annat.

Vad som följer av det är dock att kostnaden tillhör laddningsstrategin snarare än katalogen — och laddningsstrategin är den del som blev fixad. Att krympa katalogen för att passa en ivrig klient optimerar för en begränsning som Claude Code, Claude API:et och varje körningsrigg med kodexekvering redan tagit bort. Det kostar dig också permanent det primitiverna köper: en yta där modellen resonerar om crm_change_deal_stage som en namngiven operation med sitt eget schema, sina egna behörigheter och sin egen godkännanderuta, snarare än som en gren inne i något större. Sex moduler med verklig täckning — CRM, konversationer, kunskapsbas, CMS, utgående kontakt, analys — är vad 200-något köper, och det är samma sex som delar en databas och en hyresgästkolumn.

Vad händer om du kollapsar 200-något verktyg till tolv?

Ytan krymper inte. Den flyttar sig. Ett enda crm-verktyg med en action-parameter måste fortfarande acceptera varje argument varje åtgärd behöver, så tvetydigheten vandrar ut ur verktygsvalet — där modellen får ett namn, en beskrivning och ett validerat schema — och in i argumentkonstruktionen, där den får en sträng och ett hopp.

Två andra saker följer med. Klienten förlorar förmågan att skilja en läsning från en destruktiv skrivning innan anropet görs, för det finns nu ett verktyg och det är ibland båda; godkännande-UX degraderas till att godkänna crm i allmänhet. Och behörigheter slutar kunna uttryckas per operation, för enheten token ger åtkomst till är inte längre enheten arbetet sker i.

Det här är ingen kritik mot de team som gör det. Att konsolidera ett vidsträckt tredjeparts-API bakom några få välvalda verb är genuint god ingenjörskonst, och för en server som kapslar in någon annans REST-yta är det ofta rätt val — det underliggande API:et designades inte för den här anroparen, och en tunn trogen spegel av det är sämre än en genomtänkt abstraktion. Munin är i en annan position: vi designade verktygsytan först och REST-API:et och dashboarden som klienter av den, så primitiverna är redan den genomtänkta abstraktionen. Det finns inget att konsolidera bort från.

Hur namnger du 200-något verktyg så att en agent hittar dem?

Använd namnrymd per modul och bryt aldrig prefixet. Varje Munin-verktyg börjar med den modul som äger det — crm_, conv_, kb_, cms_, analytics_, outreach_, med mindre familjer för bokningar, handel, kopplingar, webhooks, Slack, feedback, SEO, identitet och systemlarm. Ett regex mot ^crm_ returnerar hela CRM-familjen i en sökning. Anthropics vägledning om verktygssökning ber om precis det: ”använd prefix per tjänst eller resurs så att en sökning träffar hela gruppen”.

Det är en namnkonvention som gör bärande arbete, och den fungerar bara om den är absolut. I det ögonblick ett verktyg heter create_contact för att det läste bättre för sig självt slutar prefixet vara ett pålitligt index, och varje sökning måste skrivas defensivt. Vi behandlar ett saknat prefix som en bugg i samma kategori som en saknad migrering.

Deskriptorerna bär fyra fält till som finns av samma skäl — så att en klient kan snäva in katalogen utan att en människa kurerar en lista:

{
  "name":        "crm_create_contact",
  "title":       "…",
  "description": "…",
  "audiences":   ["admin"],   // eller ["self_service"], eller båda
  "scopes":      ["…"],       // vad token redan måste ha
  "danger":      null,        // ifyllt när anropet är destruktivt
  "readOnly":    false
}

// Hela katalogen är en ren JSON-array av dessa,
// publik, utan legitimation. Räkna den själv.

• audiencesVem som överhuvudtaget får se verktyget. En adminnyckel ser hela katalogen; ett delegerat slutanvändartoken ser bara självbetjänings-delmängden. Det är ett synlighetsbeslut fattat på servern, innan tools/list svarar.
• scopesVad det anropande token redan måste ha. Deklarerat per verktyg snarare än per modul, så att en nyckel utfärdad för innehållsarbete inte når CRM:et även om båda bor bakom en ändpunkt.
• dangerIfyllt när operationen är destruktiv. En klient kan bygga en godkännanderuta från det här fältet i stället för att underhålla sin egen hårdkodade lista över saker att vara försiktig med.
• readOnlyOm anropet ändrar något. Den billigaste signal en rigg har för att avgöra vad som får köra utan tillsyn och vad som väntar på en person.

Hur undviker en kundvänd agent att se alla 200-något verktyg?

audiences-fältet. En adminnyckel ser allt. Ett delegerat slutanvändartoken — det bakom en supportwidget, i samtal med din kund — ser bara verktygen märkta självbetjäning: kontrollera min egen order, slå upp min egen bokning, läsa min egen kontaktpost, söka i den publika kunskapsbasen, be om en människa. Det är en kort självbetjäningsdelmängd — under tjugo definitioner — inte tvåhundra, och insnävningen sker på serversidan innan katalogen överhuvudtaget returneras.

Det här spelar större roll än det låter. Det vanliga rådet mot verktygsöverbelastning är att konfigurera din klient noga, vilket lägger ett säkerhetsformat beslut i en konfigurationsfil som underhålls av den som satte upp agenten. Publiker flyttar in det i token. En självbetjäningsagent är inte betrodd-men-filtrerad; den kan inte räkna upp adminverktygen, så den kan inte övertalas att anropa ett.

Varför är de medföljande färdigheterna inte bara fler verktyg?

För att arbetsflöden hör hemma i dokument, inte i verktygskatalogen. Munin levererar 60 markdown-färdigheter — importera och poängsätta en leadlista, starta en supportdesk, koppla en frontend till widgeten och spåraren, migrera en hyresgäst mellan servrar — och når alla genom exakt två verktyg, skills_list och skills_read. Agenten listar titlarna, läser den den behöver, och anropar de primitiver den färdigheten namnger. Femtiosju arbetsflöden, två definitioner.

Det är progressivt avslöjande implementerat på servern, och det är samma form Anthropic beskriver när de föreslår att lägga till ett search_tools-verktyg eller lägga ut verktyg som filer på ett filsystem. Skillnaden är bara var indexet bor. En färdighet är ett dokument, så den kan bära ordning, förbehåll, fallgropen som kostar alla en eftermiddag, och skälet till att ett steg finns — inget av det ryms i en verktygsbeskrivning, och allt av det är vad en agent faktiskt behöver för att få en sexanropssekvens rätt första gången.

Det är också svaret på den uppenbara invändningen mot primitiverna. Ja, crm_import följt av crm_create_pipeline följt av crm_log_activity är fler anrop än ett import_and_score_leads-verktyg hade varit. Sekvensen är nedskriven i skill://crm/import-and-score-leads, där den kostar inget tills den läses.

Vilka MCP-klienter hanterar en stor katalog bra?

De som skjuter upp. Claude Code använder verktygssökning som standard, så en stor server kostar en lista med namn snarare än en vägg av scheman — att köra hela plattformen från en terminal är ett enda claude mcp add. På Claude API:et får du samma beteende explicit, med defer_loading på MCP-verktygsuppsättningens post och en regex- eller BM25-sökvariant. Vilken rigg som helst med en sandlåda för kodexekvering kan gå längre och läsa definitioner direkt från ett filsystem.

Ivriga klienter är den begränsning som är värd att kontrollera innan du kopplar upp något. Cursor-användare har i över ett år rapporterat att agenten bara tar emot ungefär de första 40 verktygen över alla konfigurerade servrar, medan resten tyst är otillgängliga — den här Cursor-forumtråden är den långvariga. Det är en verklig gräns och den har en tråkig fix: avgränsa anslutningen. Munin i Cursor är värt att koppla upp för CRM- och konversationsfamiljerna och inget annat, för skälet att ha Munin i en editor är att läsa ärendet som rapporterade buggen, inte att köra en utgående kampanj därifrån.

Den generella regel jag skulle ge till vem som helst som bygger en server av den här storleken: publicera hela katalogen, använd namnrymder skoningslöst, märk upp varje deskriptor så att en klient kan filtrera utan en människas hjälp, och låt klienten avgöra hur mycket av den den håller åt gången. Det är den arbetsfördelning protokollet nu är designat kring. Det är också varför det var rätt satsning att protokollet betyder mer än gränssnittet — klienterna blev smartare om katalogen utan att katalogen ändrades alls.

Vanliga frågor

Hur många MCP-verktyg är för många? Det beror helt på klienten. Med ivrig laddning sätter Anthropics dokumentation urvalsförsämring vid 30 till 50 verktyg. Med uppskjuten laddning och verktygssökning stöder samma dokumentation tusentals och sätter taket för en förfrågan vid 10 000 uppskjutna definitioner. Siffran att hålla ögonen på är hur många definitioner som når kontextfönstret, inte hur många servern publicerar.

Hur många verktyg har Munin? Mer än 200 MCP-verktyg på en ändpunkt, mcp.getmunin.com, som täcker CRM, konversationer, kunskapsbas, CMS, utgående kontakt och analys, plus ett REST-API över samma data och 60 medföljande markdown-färdigheter. Den levande katalogen är publik och utan legitimation på https://api.getmunin.com/v1/public/mcp-tools om du hellre räknar den än tar mitt ord för det — vilket är rätt instinkt, för siffran rör sig varje gång vi levererar.

Gör en stor MCP-server Claude eller ChatGPT långsammare? Bara om klienten laddar varje definition i förväg. Claude Code skjuter upp MCP-verktyg som standard; Claude API:et skjuter upp när du sätter defer_loading på verktygsuppsättningen; en rigg med kodexekvering läser definitioner vid behov. Klienter utan uppskjutning betalar för hela katalogen vid varje förfrågan, oavsett vilken server den kom från.

Ska jag bygga ett MCP-verktyg per operation, eller några få verktyg med en action-parameter? Ett per operation, om du styr det underliggande systemet och kan namnge operationerna bra. Verktyg per operation ger modellen ett schema i stället för ett fritextargument, och ger klienten en signal per anrop för godkännande och avgränsning. Konsoliderade verktyg är rimligare när du kapslar in ett tredjeparts-API vars form du inte valde.

Hur hindrar du en kundvänd agent från att nå adminverktyg? Med en publik på token snarare än ett filter i klienten. Varje Munin-verktygsdeskriptor bär en audiences-array; ett delegerat slutanvändartoken visas bara någonsin självbetjäningsdelmängden, så adminverktygen finns inte i den katalog agenten tar emot och kan inte anropas vid namn.

Var bör flerstegsarbetsflöden bo, om inte i verktygskatalogen? I dokument agenten kan läsa vid behov. Munin håller alla 60 bakom skills_list och skills_read, så ett arbetsflöde kostar två definitioner oavsett hur många arbetsflöden det finns. Ett dokument kan också bära ordning, förbehåll och skälet till att ett steg finns, vilket en verktygsbeskrivning inte kan.

Katalogen är publik och utan legitimation på api.getmunin.com/v1/public/mcp-tools, och verktygsreferensen grupperar den per modul.

För många verktyg var aldrig ett räkneproblem. Det är ett upptäcktsproblem.