Værktøjsoverbelastning er et opdagelsesproblem.

Konsensus kom hurtigt, og den lyder rigtig: for mange værktøjer gør en agent dårligere. Anthropics egen dokumentation sætter et tal på det — en models evne til at vælge det rigtige værktøj forringes, når du overskrider 30 til 50 tilgængelige værktøjer. Munin eksponerer mere end 200 på ét enkelt endpoint. Efter det regnestykke brugte vi et år på at bygge nøjagtigt det, branchen lige havde lært ikke at bygge.

Jeg tror, regnestykket måler det forkerte objekt. Antallet er en egenskab ved kataloget. Forringelsen er en egenskab ved, hvad en klient vælger at indlæse i kontekstvinduet. De var det samme tal i to år, hvilket er grunden til, at alle begyndte at behandle dem som én ting. I 2026 gik de fra hinanden, og det interessante designspørgsmål flyttede med dem.

Gør for mange MCP-værktøjer en AI-agent dårligere?

Ja — når klienten indlæser hver eneste værktøjsdefinition på forhånd. Anthropics dokumentation om værktøjssøgning sætter nøjagtighedstærsklen ved 30 til 50 tilgængelige værktøjer og bemærker, at en opsætning med fem servere på tværs af GitHub, Slack, Sentry, Grafana og Splunk kan sluge omkring 55.000 tokens i definitioner, før modellen har læst forespørgslen. Fejlen ligger i ivrig indlæsning, ikke i katalogets størrelse.

Den skelnen er ikke et debatpunkt, for løsningen er allerede leveret. Værktøjssøgningsværktøjet lader en server mærke definitioner med defer_loading: true; modellen søger derefter i navne, beskrivelser, argumentnavne og argumentbeskrivelser, og API'et udvider kun det, der kommer tilbage. Anthropics dokumentation rapporterer, at det typisk skærer definitionsoverhead med mere end 85 procent ved at indlæse de tre til fem værktøjer, en given forespørgsel faktisk har brug for, og fastslår, at udvælgelsesnøjagtigheden »forbliver høj selv på tværs af tusindvis af værktøjer«. Loftet per forespørgsel er 10.000 udskudte værktøjer.

Den anden løsning er ældre og mere kontant. I Code execution with MCP, udgivet i november 2025, præsenterede Anthropic værktøjskataloger som filer, en agent kan læse efter behov, og målte ét arbejdsflow falde fra 150.000 tokens til 2.000 — en reduktion på 98,7 procent. Cloudflare nåede samme konklusion uafhængigt og kaldte det Code Mode. To teams, to implementeringer, én indsigt: hold op med at betale for definitioner, du ikke har brugt endnu.

Hvorfor eksponerer Munin 200-og-noget MCP-værktøjer i stedet for et dusin?

Fordi de 200-og-noget værktøjer er primitiver, ikke arbejdsflow. crm_create_contact, conv_send_message, cms_update_entry, kb_search — hvert enkelt gør én ting ved én slags post, og navnet siger, hvilket modul der ejer det. Et katalog af primitiver er stort og forudsigeligt. Et katalog af arbejdsflow er lille, indtil nogen vil have en kombination, ingen forudsagde, og så vokser det for evigt.

Den ærlige del af det: to hundrede definitioner er mere, end nogen enkelt samtale har brug for, og en klient, der indlæser dem alle ivrigt, bruger kontekst på værktøjer, den session aldrig vil kalde. Det er en reel omkostning, og jeg vil ikke lade som noget andet.

Hvad der følger af det, er dog, at omkostningen tilhører indlæsningsstrategien frem for kataloget — og indlæsningsstrategien er den del, der blev rettet. At krympe kataloget for at passe en ivrig klient optimerer for en begrænsning, som Claude Code, Claude API'et og enhver rig med kodeeksekvering allerede har fjernet. Det koster dig også permanent det, primitiverne køber: en flade, hvor modellen ræsonnerer om crm_change_deal_stage som en navngiven operation med sit eget skema, sine egne rettigheder og sin egen godkendelsesdialog, frem for som én gren inde i noget større. Seks moduler med reel dækning — CRM, samtaler, videnbase, CMS, udgående kontakt, analyse — er, hvad 200-og-noget køber, og det er de samme seks, der deler én database og én tenancy-kolonne.

Hvad sker der, hvis du kollapser 200-og-noget værktøjer til tolv?

Fladen krymper ikke. Den flytter sig. Et enkelt crm-værktøj med en action-parameter skal stadig acceptere hvert argument, hver handling kræver, så tvetydigheden vandrer ud af værktøjsvalget — hvor modellen får et navn, en beskrivelse og et valideret skema — og ind i argumentkonstruktionen, hvor den får en streng og et håb.

To andre ting følger med. Klienten mister evnen til at skelne en læsning fra en destruktiv skrivning, før kaldet foretages, fordi der nu er ét værktøj, og det er nogle gange begge dele; godkendelses-UX degraderes til at godkende crm i almindelighed. Og rettigheder holder op med at kunne udtrykkes per operation, fordi den enhed, token giver adgang til, ikke længere er den enhed, arbejdet sker i.

Det er ikke et angreb på de teams, der gør det. At konsolidere et vidtstrakt tredjeparts-API bag nogle få velvalgte udsagnsord er reelt god ingeniørkunst, og for en server, der pakker en andens REST-flade ind, er det ofte det rigtige valg — det underliggende API blev ikke designet til denne kalder, og et tyndt, tro spejl af det er værre end en gennemtænkt abstraktion. Munin er i en anden position: vi designede værktøjsfladen først og REST-API'et og dashboardet som klienter af den, så primitiverne er allerede den gennemtænkte abstraktion. Der er intet at konsolidere væk fra.

Hvordan navngiver du 200-og-noget værktøjer, så en agent kan finde dem?

Brug navnerum per modul, og bryd aldrig præfikset. Hvert Munin-værktøj begynder med det modul, der ejer det — crm_, conv_, kb_, cms_, analytics_, outreach_, med mindre familier til bookinger, handel, forbindelser, webhooks, Slack, feedback, SEO, identitet og systemalarmer. Ét regex mod ^crm_ returnerer hele CRM-familien i én søgning. Anthropics vejledning om værktøjssøgning beder om præcis det: »brug præfiks per tjeneste eller ressource, så én søgning rammer hele gruppen«.

Det er en navnekonvention, der gør bærende arbejde, og den virker kun, hvis den er absolut. I det øjeblik ét værktøj hedder create_contact, fordi det læste bedre alene, holder præfikset op med at være et pålideligt indeks, og hver søgning skal skrives defensivt. Vi behandler et manglende præfiks som en fejl i samme kategori som en manglende migration.

Deskriptorerne bærer fire felter mere, der findes af samme grund — så en klient kan indsnævre kataloget, uden at et menneske kuraterer en liste:

{
  "name":        "crm_create_contact",
  "title":       "…",
  "description": "…",
  "audiences":   ["admin"],   // eller ["self_service"], eller begge
  "scopes":      ["…"],       // hvad token allerede skal have
  "danger":      null,        // udfyldt når kaldet er destruktivt
  "readOnly":    false
}

// Hele kataloget er et rent JSON-array af disse,
// offentligt, uden legitimation. Tæl det selv.

• audiencesHvem der overhovedet må se værktøjet. En adminnøgle ser hele kataloget; et delegeret slutbrugertoken ser kun selvbetjenings-delmængden. Det er en synlighedsbeslutning truffet på serveren, før tools/list svarer.
• scopesHvad det kaldende token allerede skal have. Erklæret per værktøj frem for per modul, så en nøgle udstedt til indholdsarbejde ikke når CRM'et, selvom begge bor bag ét endpoint.
• dangerUdfyldt når operationen er destruktiv. En klient kan bygge en godkendelsesdialog ud fra dette felt i stedet for at vedligeholde sin egen hårdkodede liste over ting, man skal være forsigtig med.
• readOnlyOm kaldet ændrer noget. Det billigste signal, en rig har, til at afgøre, hvad der må køre uden opsyn, og hvad der venter på en person.

Hvordan undgår en kundevendt agent at se alle 200-og-noget værktøjer?

audiences-feltet. En adminnøgle ser alt. Et delegeret slutbrugertoken — det bag en supportwidget, i samtale med din kunde — ser kun de værktøjer, der er mærket selvbetjening: tjek min egen ordre, slå min egen booking op, læs min egen kontaktpost, søg i den offentlige videnbase, bed om et menneske. Det er en kort selvbetjeningsdelmængde — under tyve definitioner — ikke to hundrede, og indsnævringen sker på serversiden, før kataloget overhovedet returneres.

Det betyder mere, end det lyder. Det sædvanlige råd mod værktøjsoverbelastning er at konfigurere din klient omhyggeligt, hvilket lægger en sikkerhedsformet beslutning i en konfigurationsfil, der vedligeholdes af den, der satte agenten op. Publikummer flytter den ind i token. En selvbetjeningsagent er ikke betroet-men-filtreret; den kan ikke opremse adminværktøjerne, så den kan ikke overtales til at kalde et.

Hvorfor er de medfølgende færdigheder ikke bare flere værktøjer?

Fordi arbejdsflow hører hjemme i dokumenter, ikke i værktøjskataloget. Munin leverer 60 markdown-færdigheder — importere og score en leadliste, starte en supportafdeling, koble en frontend til widgetten og sporeren, migrere en tenant mellem servere — og når dem alle gennem nøjagtigt to værktøjer, skills_list og skills_read. Agenten lister titlerne, læser den, den har brug for, og kalder de primitiver, den færdighed navngiver. Syvoghalvtreds arbejdsflow, to definitioner.

Det er progressiv afdækning implementeret på serveren, og det er den samme form, Anthropic beskriver, når de foreslår at tilføje et search_tools-værktøj eller lægge værktøjer ud som filer på et filsystem. Forskellen er kun, hvor indekset bor. En færdighed er et dokument, så den kan bære rækkefølge, forbehold, den fælde der koster alle en eftermiddag, og grunden til at et trin findes — intet af det passer i en værktøjsbeskrivelse, og alt af det er, hvad en agent faktisk har brug for for at få en sekskalds sekvens rigtig første gang.

Det er også svaret på den åbenlyse indvending mod primitiverne. Ja, crm_import efterfulgt af crm_create_pipeline efterfulgt af crm_log_activity er flere kald, end ét import_and_score_leads-værktøj ville være. Sekvensen er skrevet ned i skill://crm/import-and-score-leads, hvor den ikke koster noget, før den bliver læst.

Hvilke MCP-klienter håndterer et stort katalog godt?

Dem, der udskyder. Claude Code bruger værktøjssøgning som standard, så en stor server koster en liste med navne frem for en mur af skemaer — at køre hele platformen fra en terminal er ét claude mcp add. På Claude API'et får du den samme adfærd eksplicit, med defer_loading på MCP-værktøjssættets post og en regex- eller BM25-søgevariant. Enhver rig med en sandkasse til kodeeksekvering kan gå videre og læse definitioner direkte fra et filsystem.

Ivrige klienter er den begrænsning, det er værd at tjekke, før du kobler noget op. Cursor-brugere har i over et år rapporteret, at agenten kun modtager omtrent de første 40 værktøjer på tværs af alle konfigurerede servere, mens resten stille er utilgængelige — denne Cursor-forumtråd er den langvarige. Det er en reel grænse, og den har en kedeligt enkel løsning: afgræns forbindelsen. Munin i Cursor er værd at koble op til CRM- og samtalefamilierne og intet andet, fordi grunden til at have Munin i en editor er at læse den sag, der meldte fejlen, ikke at køre en udgående kampagne derfra.

Den generelle regel, jeg ville give enhver, der bygger en server af denne størrelse: publicer hele kataloget, brug navnerum ubarmhjertigt, mærk hver deskriptor op, så en klient kan filtrere uden et menneskes hjælp, og lad klienten afgøre, hvor meget af det den holder ad gangen. Det er den arbejdsdeling, protokollen nu er designet omkring. Det er også derfor det var det rigtige væddemål, at protokollen betyder mere end grænsefladen — klienterne blev klogere på kataloget, uden at kataloget ændrede sig overhovedet.

Ofte stillede spørgsmål

Hvor mange MCP-værktøjer er for mange? Det afhænger fuldstændigt af klienten. Med ivrig indlæsning sætter Anthropics dokumentation udvælgelsesforringelse ved 30 til 50 værktøjer. Med udskudt indlæsning og værktøjssøgning understøtter den samme dokumentation tusindvis og sætter loftet for én forespørgsel ved 10.000 udskudte definitioner. Tallet at holde øje med er, hvor mange definitioner der når kontekstvinduet, ikke hvor mange serveren publicerer.

Hvor mange værktøjer har Munin? Mere end 200 MCP-værktøjer på ét endpoint, mcp.getmunin.com, der dækker CRM, samtaler, videnbase, CMS, udgående kontakt og analyse, plus et REST-API over de samme data og 60 medfølgende markdown-færdigheder. Det levende katalog er offentligt og uden legitimation på https://api.getmunin.com/v1/public/mcp-tools, hvis du hellere vil tælle det end tage mit ord for det — hvilket er det rigtige instinkt, fordi tallet flytter sig, hver gang vi leverer.

Gør en stor MCP-server Claude eller ChatGPT langsommere? Kun hvis klienten indlæser hver definition på forhånd. Claude Code udskyder MCP-værktøjer som standard; Claude API'et udskyder, når du sætter defer_loading på værktøjssættet; en rig med kodeeksekvering læser definitioner efter behov. Klienter uden udskydelse betaler for hele kataloget ved hver forespørgsel, uanset hvilken server det kom fra.

Skal jeg bygge ét MCP-værktøj per operation eller nogle få værktøjer med en action-parameter? Ét per operation, hvis du styrer det underliggende system og kan navngive operationerne godt. Værktøjer per operation giver modellen et skema i stedet for et fritekstargument og giver klienten et signal per kald til godkendelse og afgrænsning. Konsoliderede værktøjer giver mere mening, når du pakker et tredjeparts-API ind, hvis form du ikke valgte.

Hvordan forhindrer du en kundevendt agent i at nå adminværktøjer? Med et publikum på token frem for et filter i klienten. Hver Munin-værktøjsdeskriptor bærer et audiences-array; et delegeret slutbrugertoken får kun nogensinde vist selvbetjeningsdelmængden, så adminværktøjerne er ikke i det katalog, den agent modtager, og kan ikke kaldes ved navn.

Hvor bør flertrinsarbejdsflow bo, hvis ikke i værktøjskataloget? I dokumenter, agenten kan læse efter behov. Munin holder alle 60 bag skills_list og skills_read, så et arbejdsflow koster to definitioner, uanset hvor mange arbejdsflow der findes. Et dokument kan også bære rækkefølge, forbehold og grunden til, at et trin findes, hvilket en værktøjsbeskrivelse ikke kan.

Kataloget er offentligt og uden legitimation på api.getmunin.com/v1/public/mcp-tools, og værktøjsreferencen grupperer det per modul.

For mange værktøjer var aldrig et tælleproblem. Det er et opdagelsesproblem.