Verktøyoverbelastning er et oppdagelsesproblem.

Konsensusen kom raskt, og den høres riktig ut: for mange verktøy gjør en agent dårligere. Anthropics egen dokumentasjon setter et tall på det — en modells evne til å velge riktig verktøy forringes når du overstiger 30 til 50 tilgjengelige verktøy. Munin eksponerer mer enn 200 på ett enkelt endepunkt. Etter det regnestykket brukte vi et år på å bygge nøyaktig det bransjen nettopp lærte seg å ikke bygge.

Jeg tror regnestykket måler feil objekt. Antallet er en egenskap ved katalogen. Forringelsen er en egenskap ved hva en klient velger å laste inn i kontekstvinduet. De var det samme tallet i to år, og det er derfor alle begynte å behandle dem som én ting. I 2026 gikk de fra hverandre, og det interessante designspørsmålet flyttet seg med dem.

Gjør for mange MCP-verktøy en AI-agent dårligere?

Ja — når klienten laster inn hver eneste verktøydefinisjon på forhånd. Anthropics dokumentasjon om verktøysøk setter nøyaktighetsterskelen ved 30 til 50 tilgjengelige verktøy, og bemerker at et oppsett med fem servere på tvers av GitHub, Slack, Sentry, Grafana og Splunk kan sluke rundt 55 000 tokens i definisjoner før modellen har lest forespørselen. Feilen ligger i ivrig lasting, ikke i størrelsen på katalogen.

Det skillet er ikke et debattpoeng, fordi fiksen allerede er levert. Verktøysøk-verktøyet lar en server merke definisjoner med defer_loading: true; modellen søker så i navn, beskrivelser, argumentnavn og argumentbeskrivelser, og API-et utvider bare det som kommer tilbake. Anthropics dokumentasjon melder at dette typisk kutter definisjonsoverheaden med mer enn 85 prosent, ved å laste de tre til fem verktøyene en gitt forespørsel faktisk trenger, og slår fast at utvalgsnøyaktigheten «holder seg høy selv på tvers av tusenvis av verktøy». Taket per forespørsel er 10 000 utsatte verktøy.

Den andre fiksen er eldre og mer rett fram. I Code execution with MCP, publisert i november 2025, presenterte Anthropic verktøykataloger som filer en agent kan lese ved behov, og målte én arbeidsflyt som falt fra 150 000 tokens til 2 000 — en reduksjon på 98,7 prosent. Cloudflare kom til den samme konklusjonen uavhengig og kalte den Code Mode. To team, to implementasjoner, én innsikt: slutt å betale for definisjoner du ikke har brukt ennå.

Hvorfor eksponerer Munin 200-og-noe MCP-verktøy i stedet for et dusin?

Fordi de 200-og-noe verktøyene er primitiver, ikke arbeidsflyter. crm_create_contact, conv_send_message, cms_update_entry, kb_search — hvert enkelt gjør én ting med én type post, og navnet sier hvilken modul som eier det. En katalog av primitiver er stor og forutsigbar. En katalog av arbeidsflyter er liten helt til noen vil ha en kombinasjon ingen forutsa, og så vokser den for alltid.

Den ærlige delen av dette: to hundre definisjoner er mer enn noen enkelt samtale trenger, og en klient som laster alle ivrig, bruker kontekst på verktøy den økta aldri vil kalle. Det er en reell kostnad, og jeg skal ikke late som noe annet.

Det som følger av det, er likevel at kostnaden hører til lastestrategien framfor katalogen — og lastestrategien er delen som ble fikset. Å krympe katalogen for å passe en ivrig klient optimaliserer for en skranke som Claude Code, Claude API-et og hver eneste kodekjøringsrigg allerede har fjernet. Det koster deg også permanent det primitivene kjøper: en flate der modellen resonnerer om crm_change_deal_stage som en navngitt operasjon med sitt eget skjema, sine egne tilganger og sin egen godkjenningsdialog, framfor som én gren inne i noe større. Seks moduler med reell dekning — CRM, samtaler, kunnskapsbase, CMS, utgående kontakt, analyse — er det 200-og-noe kjøper, og det er de samme seks som deler én database og én tenancy-kolonne.

Hva skjer om du kollapser 200-og-noe verktøy til tolv?

Flaten krymper ikke. Den flytter seg. Et enkelt crm-verktøy med en action-parameter må fortsatt godta hvert argument hver handling trenger, så tvetydigheten vandrer ut av verktøyvalget — der modellen får et navn, en beskrivelse og et validert skjema — og inn i argumentkonstruksjonen, der den får en streng og et håp.

To andre ting følger med. Klienten mister evnen til å skille en lesing fra en destruktiv skriving før kallet gjøres, fordi det nå er ett verktøy og det er iblant begge deler; godkjennings-UX degraderes til å godkjenne crm generelt. Og tilganger slutter å kunne uttrykkes per operasjon, fordi enheten tokenet gir tilgang til, ikke lenger er enheten arbeidet skjer i.

Dette er ikke et slag mot teamene som gjør det. Å konsolidere et vidstrakt tredjeparts-API bak noen få godt valgte verb er genuint god ingeniørkunst, og for en server som pakker inn noen andres REST-flate er det ofte riktig valg — det underliggende API-et ble ikke designet for denne kalleren, og et tynt, trofast speil av det er verre enn en gjennomtenkt abstraksjon. Munin er i en annen posisjon: vi designet verktøyflaten først og REST-API-et og dashbordet som klienter av den, så primitivene er allerede den gjennomtenkte abstraksjonen. Det finnes ingenting å konsolidere bort fra.

Hvordan navngir du 200-og-noe verktøy så en agent finner dem?

Bruk navnerom etter modul, og bryt aldri prefikset. Hvert Munin-verktøy begynner med modulen som eier det — crm_, conv_, kb_, cms_, analytics_, outreach_, med mindre familier for bookinger, handel, koblinger, webhooks, Slack, tilbakemeldinger, SEO, identitet og systemvarsler. Ett regex mot ^crm_ returnerer hele CRM-familien i ett søk. Anthropics veiledning om verktøysøk ber om nettopp dette: «bruk prefiks etter tjeneste eller ressurs, så ett søk treffer hele gruppa».

Det er en navnekonvensjon som gjør bærende arbeid, og den virker bare om den er absolutt. I det øyeblikket ett verktøy heter create_contact fordi det leste bedre alene, slutter prefikset å være en pålitelig indeks, og hvert søk må skrives defensivt. Vi behandler et manglende prefiks som en feil i samme kategori som en manglende migrasjon.

Deskriptorene bærer fire felt til som finnes av samme grunn — så en klient kan snevre inn katalogen uten at et menneske kurerer en liste:

{
  "name":        "crm_create_contact",
  "title":       "…",
  "description": "…",
  "audiences":   ["admin"],   // eller ["self_service"], eller begge
  "scopes":      ["…"],       // hva tokenet allerede må ha
  "danger":      null,        // fylt ut når kallet er destruktivt
  "readOnly":    false
}

// Hele katalogen er et rent JSON-array av disse,
// offentlig, uten legitimasjon. Tell den selv.

• audiencesHvem som i det hele tatt får se verktøyet. En admin-nøkkel ser hele katalogen; et delegert sluttbrukertoken ser bare selvbetjenings-delmengden. Dette er en synlighetsbeslutning tatt på serveren, før tools/list svarer.
• scopesHva det kallende tokenet allerede må ha. Erklært per verktøy framfor per modul, så en nøkkel utstedt for innholdsarbeid ikke når CRM-et, selv om begge bor bak ett endepunkt.
• dangerFylt ut når operasjonen er destruktiv. En klient kan bygge en godkjenningsdialog fra dette feltet i stedet for å vedlikeholde sin egen hardkodede liste over ting å være forsiktig med.
• readOnlyOm kallet endrer noe. Det billigste signalet en rigg har for å avgjøre hva som kan kjøre uten tilsyn og hva som venter på en person.

Hvordan unngår en kundevendt agent å se alle 200-og-noe verktøy?

audiences-feltet. En admin-nøkkel ser alt. Et delegert sluttbrukertoken — det bak en supportwidget, i samtale med kunden din — ser bare verktøyene merket selvbetjening: sjekk min egen ordre, slå opp min egen booking, les min egen kontaktpost, søk i den offentlige kunnskapsbasen, be om et menneske. Det er en kort selvbetjeningsdelmengde — under tjue definisjoner — ikke to hundre, og innsnevringen skjer på serversiden før katalogen i det hele tatt returneres.

Dette betyr mer enn det høres ut som. Det vanlige rådet mot verktøyoverbelastning er å konfigurere klienten nøye, som legger en sikkerhetsformet beslutning i en konfigurasjonsfil vedlikeholdt av den som satte opp agenten. Publikum flytter den inn i tokenet. En selvbetjeningsagent er ikke tiltrodd-men-filtrert; den kan ikke ramse opp admin-verktøyene, så den kan ikke overtales til å kalle ett.

Hvorfor er de medfølgende ferdighetene ikke bare flere verktøy?

Fordi arbeidsflyter hører hjemme i dokumenter, ikke i verktøykatalogen. Munin leverer 60 markdown-ferdigheter — importere og score en lead-liste, starte en supportavdeling, koble en frontend til widgeten og sporeren, migrere en leietaker mellom servere — og når alle sammen gjennom nøyaktig to verktøy, skills_list og skills_read. Agenten lister titlene, leser den den trenger, og kaller primitivene den ferdigheten navngir. Femtisju arbeidsflyter, to definisjoner.

Det er gradvis avdekking implementert på serveren, og det er den samme formen Anthropic beskriver når de foreslår å legge til et search_tools-verktøy eller legge verktøy ut som filer på et filsystem. Forskjellen er bare hvor indeksen bor. En ferdighet er et dokument, så den kan bære rekkefølge, forbehold, fella som koster alle en ettermiddag, og grunnen til at et steg finnes — ingenting av det får plass i en verktøybeskrivelse, og alt av det er det en agent faktisk trenger for å få en seks-kalls sekvens riktig første gang.

Det er også svaret på den åpenbare innvendingen mot primitivene. Ja, crm_import etterfulgt av crm_create_pipeline etterfulgt av crm_log_activity er flere kall enn ett import_and_score_leads-verktøy ville vært. Sekvensen er skrevet ned i skill://crm/import-and-score-leads, der den koster ingenting til den blir lest.

Hvilke MCP-klienter håndterer en stor katalog godt?

De som utsetter. Claude Code bruker verktøysøk som standard, så en stor server koster en liste med navn framfor en vegg av skjemaer — å styre hele plattformen fra en terminal er én claude mcp add. På Claude API-et får du den samme oppførselen eksplisitt, med defer_loading på MCP-verktøysettets oppføring og en regex- eller BM25-søkevariant. Hvilken som helst rigg med en kodekjøringssandkasse kan gå lenger og lese definisjoner rett fra et filsystem.

Ivrige klienter er flaskehalsen det er verdt å sjekke før du kobler opp noe som helst. Cursor-brukere har i over et år meldt at agenten bare mottar omtrent de første 40 verktøyene på tvers av alle konfigurerte servere, mens resten stille er utilgjengelige — denne Cursor-forumtråden er den langvarige. Det er en reell grense, og den har en kjedelig fiks: avgrens tilkoblingen. Munin i Cursor er verdt å koble opp for CRM- og samtalefamiliene og ingenting annet, fordi grunnen til å ha Munin i en editor er å lese saken som meldte feilen, ikke å kjøre en utgående kampanje derfra.

Den generelle regelen jeg ville gitt hvem som helst som bygger en server på denne størrelsen: publiser hele katalogen, bruk navnerom nådeløst, merk opp hver deskriptor så en klient kan filtrere uten et menneskes hjelp, og la klienten avgjøre hvor mye av den den holder om gangen. Det er arbeidsdelingen protokollen nå er designet rundt. Det er også derfor det var riktig veddemål at protokollen betyr mer enn grensesnittet — klientene ble smartere om katalogen uten at katalogen endret seg i det hele tatt.

Ofte stilte spørsmål

Hvor mange MCP-verktøy er for mange? Det avhenger fullstendig av klienten. Med ivrig lasting setter Anthropics dokumentasjon utvalgsforringelse ved 30 til 50 verktøy. Med utsatt lasting og verktøysøk støtter den samme dokumentasjonen tusenvis og setter taket for én forespørsel ved 10 000 utsatte definisjoner. Tallet å følge med på er hvor mange definisjoner som når kontekstvinduet, ikke hvor mange serveren publiserer.

Hvor mange verktøy har Munin? Mer enn 200 MCP-verktøy på ett endepunkt, mcp.getmunin.com, som dekker CRM, samtaler, kunnskapsbase, CMS, utgående kontakt og analyse, pluss et REST-API over de samme dataene og 60 medfølgende markdown-ferdigheter. Den levende katalogen er offentlig og uten legitimasjon på https://api.getmunin.com/v1/public/mcp-tools om du heller vil telle den enn å ta mitt ord for det — som er riktig instinkt, fordi tallet flytter seg hver gang vi leverer.

Gjør en stor MCP-server Claude eller ChatGPT tregere? Bare om klienten laster inn hver definisjon på forhånd. Claude Code utsetter MCP-verktøy som standard; Claude API-et utsetter når du setter defer_loading på verktøysettet; en kodekjøringsrigg leser definisjoner ved behov. Klienter uten utsettelse betaler for hele katalogen ved hver forespørsel, uansett hvilken server den kom fra.

Bør jeg bygge ett MCP-verktøy per operasjon, eller noen få verktøy med en action-parameter? Ett per operasjon, om du styrer det underliggende systemet og kan navngi operasjonene godt. Verktøy per operasjon gir modellen et skjema i stedet for et fritekstargument, og gir klienten et signal per kall for godkjenning og avgrensning. Konsoliderte verktøy gir mer mening når du pakker inn et tredjeparts-API hvis form du ikke valgte.

Hvordan hindrer du en kundevendt agent i å nå admin-verktøy? Med et publikum på tokenet framfor et filter i klienten. Hver Munin-verktøydeskriptor bærer et audiences-array; et delegert sluttbrukertoken blir bare noen gang vist selvbetjeningsdelmengden, så admin-verktøyene er ikke i katalogen den agenten mottar og kan ikke kalles ved navn.

Hvor bør flerstegs arbeidsflyter bo, om ikke i verktøykatalogen? I dokumenter agenten kan lese ved behov. Munin holder alle 60 bak skills_list og skills_read, så en arbeidsflyt koster to definisjoner uansett hvor mange arbeidsflyter det finnes. Et dokument kan også bære rekkefølge, forbehold og grunnen til at et steg finnes, som en verktøybeskrivelse ikke kan.

Katalogen er offentlig og uten legitimasjon på api.getmunin.com/v1/public/mcp-tools, og verktøyreferansen grupperer den etter modul.

For mange verktøy var aldri et telleproblem. Det er et oppdagelsesproblem.