De fleste MCP-servere bruker én primitiv av fem
Har du bygget en MCP-server, er sjansen stor for at den eksponerer tools. Tools er den åpenbare primitiven: modellen bestemmer å kalle noe, får et resultat tilbake, går videre. Det er mønsteret alle MCP-tutorials starter med, og det er reelt sett det vanligste integrasjonspunktet i produksjon i dag.
Men Model Context Protocol definerer fem primitiver, ikke én — tre på serversiden, to på klientsiden — og fire av dem er stille underutnyttet. Dette innlegget går gjennom alle fem, rammeverket for å velge riktig primitiv, og hvor protokollen er på vei: bort fra lokale prosesser og ut på nettet.
Interaksjonsmodellen: hvem bestemmer når
Før vi går inn på primitivene, er det verdt å navngi det som faktisk organiserer dem, siden det er lett å overse i spesifikasjonsteksten. Kall det interaksjonsmodellen: den samme underliggende dataen kan eksponeres til en klient på tre ulike måter, og forskjellen er hvem som bestemmer når den dukker opp i konteksten.
- Prompts er brukerstyrt. Brukeren velger selv å hente noe inn i kontekstvinduet — typisk via en slash-kommando i klienten.
- Resources er applikasjonsstyrt. Vertsapplikasjonen (en IDE, en desktop-klient) bestemmer hva den gjør med rådataen en server eksponerer.
- Tools er modellstyrt. Modellen bestemmer, midt i en samtale, om den skal kalle noe.
Med denne rammen svarer de fleste «bør dette være et tool eller en resource?»-spørsmål seg selv: det avhenger av hvem som skal ha kontroll over beslutningen om å bruke det.
Prompts: ferdigdefinerte maler brukeren selv utløser
Prompts er ferdigdefinerte maler for AI-interaksjoner som en server eksponerer til en klient. Konkret: en server kan definere en navngitt prompt — for eksempel summarize-pr — som en bruker utløser direkte, som regel via en slash-kommando i klienten de bruker.
To ting gjør prompts nyttige utover «ferdige eksempler»:
De er kode, ikke statisk tekst. En prompt-handler kjører på serveren, og kan derfor hente ferske data før den returnerer malen. En prompt som henter kommentarene på din nåværende GitHub pull request og legger dem rett inn i kontekstvinduet, er en normal, liten implementasjon — noen få linjer server-kode, ikke et spesialtilfelle.
De støtter parameter-completion. Hvis en prompt tar parametere, kan serveren eksponere en completion-handler slik at klienten kan vise brukeren en velger — for eksempel en nedtrekksliste over brukerens åpne pull requests — i stedet for å be dem taste inn en ID fra hukommelsen. Dette er reelt sett enkelt å implementere i de fleste SDK-er: én funksjon som genererer prompten, én funksjon som returnerer completion-kandidater.
Distinksjonen som betyr noe: prompts er ting brukeren eksplisitt velger å legge til i konteksten, før de ber modellen gjøre noe med det. Det er forskjellig fra et tool, som modellen kaller etter egen vurdering underveis i en oppgave.
Resources: rådata, eksponert for at applikasjonen skal bruke den
Resources eksponerer rådata eller innhold fra en server — fil-lignende objekter en klient kan lese. Der prompts er tekstbiter ment for direkte kontekst-injeksjon, er resources nærmere «her er en datakilde, gjør hva du vil med den».
Det er to ulike måter klienter bruker resources på:
- Direkte injeksjon. De fleste klienter i dag lar en bruker legge til en resource i kontekstvinduet omtrent som et filvedlegg — et databaseskjema, en konfigfil, et dokument.
- Applikasjonsside-prosessering. Fordi resources bare er data eksponert gjennom et stabilt grensesnitt, kan en applikasjon gjøre mer enn å lime det inn i konteksten: bygge embeddings over det, indeksere det, kjøre retrieval-augmented generation mot det, og bare hente inn de mest relevante bitene ved behov.
Det andre mønsteret er stort sett uutforsket i dagens MCP-økosystem. De fleste implementasjoner behandler resources som «filer du kan legge ved», som fungerer, men lar RAG-bruken — å indeksere en resource-samling og hente fra den — stå nesten urørt av eksisterende servere.
Et konkret eksempel på det enkle tilfellet: eksponer et databaseskjema som en resource, legg det ved i en desktop-klient slik du ville lagt ved en fil, og be modellen visualisere det. Modellen trenger ikke et tool-kall for å «hente skjemaet» — det ligger allerede i konteksten fordi klienten hentet det inn som en resource.
Tools: den alle allerede kjenner
Tools er handlinger modellen kan kalle — primitiven de fleste MCP-servere finnes for å eksponere, og den de fleste allerede dekker godt i dokumentasjon. Kortversjonen: modellen bestemmer når den skal kalle et tool, basert på samtalen, og får et resultat tilbake. Har du bygget en MCP-server, har du bygget dette.
Sampling: la serveren låne klientens modell
Her er et problem verdt å formulere presist. Si du vil bygge en MCP-server for et issue-tracker-system som kan oppsummere en diskusjonstråd. Å hente selve tråden er et vanlig tool eller en resource. Men å oppsummere den krever en modell — og serveren vet ikke hvilken modell klienten har konfigurert, vil ikke levere sin egen SDK og API-nøkkel, og vil definitivt ikke be sluttbrukeren om en egen credential bare for å bruke én funksjon.
Sampling er primitiven som løser dette: den lar en server be om en completion fra klienten, i stedet for å bringe sin egen modell-integrasjon. Serveren sender en sampling-forespørsel; klienten — som allerede har en modell konfigurert, og allerede har brukerens tillit og faktureringsforhold — returnerer completionen.
Dette gjør to ting:
- Klienten beholder kontrollen. Sikkerhet, personvern og kostnad blir værende hos den som allerede er betrodd dem, i stedet for at en tredjeparts-server trenger sine egne credentials og sin egen datahåndteringshistorie.
- Det gjør kjeding rekursiv. Setter du sammen MCP-servere — et tool-kall som, midt i utførelsen, kaller flere MCP-servere nedstrøms — kan sampling-forespørsler boble helt tilbake til den opprinnelige klienten. Klienten beholder kontrollen over kostnad og personvern uansett hvor dyp kjeden blir. Dette er en av de mest direkte veiene mot reelt agentiske, multi-server MCP-systemer, i stedet for enkeltstående tool-kall.
Sampling er også, ærlig talt, en av de minst støttede primitivene i klienter i dag. Anthropics egne førsteparts-produkter forventes å legge til støtte, men bred klientstøtte henger fortsatt etter det spesifikasjonen tillater.
Roots: å fortelle serveren hva som faktisk er åpent
Roots lar en klient fortelle en server hva den skal betrakte som «innenfor scope» — typisk hvilke prosjektmapper eller workspaces som er åpne. Det klassiske eksempelet: en MCP-server som kjører git-kommandoer på dine vegne, må vite hvilken arbeidsmappe den skal operere i. Roots er hvordan klienten svarer på det spørsmålet, i stedet for at serveren gjetter eller krever manuell konfigurasjon.
Det er en mindre, mer spesifikk primitiv enn de fire andre, og bruken gjenspeiler det — noen IDE-er (VS Code blant dem) støtter den, men den er langt fra universell. Likevel, bygger du en server som opererer på lokal prosjekttilstand, er roots den korrekte mekanismen fremfor en omvei.
Å sette sammen alle fem til én integrasjon
Slik ser det ut når primitivene spiller sammen, med en hypotetisk MCP-server for en chat-plattform (Slack, Discord, hva som helst):
- Prompts gir brukeren et utgangspunkt: «oppsummer denne tråden», «hva er nytt siden i går» — med completion over nylige tråder eller kanaler slik at brukeren slipper å taste inn en ID.
- Resources eksponerer kanallisten og nylig trådinnhold slik at klienten kan indeksere eller resonnere over det direkte.
- Tools dekker handlingene: søk, les en kanal, les en tråd.
- Sampling håndterer selve oppsummeringssteget, med hvilken modell klienten allerede har konfigurert.
Ingenting av dette er eksotisk — det er de samme fem primitivene, arrangert slik at hver interaksjon skjer gjennom mekanismen som matcher hvem som bør bestemme den. Resultatet er en vesentlig rikere integrasjon enn en tools-only-server, uten å legge til noen nye konsepter utover det spesifikasjonen allerede tilbyr.
Hvor MCP er på vei: bort fra laptopen, ut på nettet
Av rundt 10 000 MCP-servere community har bygget de første seks til syv månedene av protokollens levetid, er det store flertallet lokale — en Docker-container, en lokal kjørbar fil, noe du kjører på egen maskin. Neste store retning for MCP er å flytte servere bort fra lokale prosesser og ut på nettet: en MCP-server som rett og slett er et nettsted klienten din kobler seg til, i stedet for noe du laster ned og kjører.
Det skiftet krever to ting: autorisasjon og skalering.
Autorisasjon: OAuth 2.1
Gjeldende spesifikasjon krever OAuth 2.1 for autorisasjon — i praksis OAuth 2.0 med sikkerhetspraksisene du allerede burde følge, formalisert. Dette åpner to mønstre:
Forbrukerrettede eksterne servere. En leverandør — si et betalingsselskap — kan eksponere mcp.leverandor.com som en ekstern server. Brukeren kobler MCP-klienten sin til, går gjennom en OAuth-innlogging, og har nå tools skopet til sin egen konto, støttet av en leverandør de allerede har et tillitsforhold til — ikke en ukjent tredjeparts binærfil som kjører lokalt. Leverandøren kan også oppdatere serveren løpende, uten at brukere trenger å hente et nytt image.
Enterprise-interne servere bak eksisterende SSO. Et selskap kan deploye en MCP-server internt og legge den bak hvilken identity-provider de allerede bruker for single sign-on — Entra ID, Okta eller lignende. Ansatte autentiserer seg som de alltid gjør, og fra da av arver hver MCP-interaksjon den identiteten automatisk. Dette skiller tydelig to jobber som pleide å være sammenvevd: teamene som bygger selve MCP-serveren, og teamene som eier identitet og tilgang — den samme arbeidsdelingen de fleste enterprise-organisasjoner allerede bruker overalt ellers.
Skalering: Streamable HTTP
Det andre kravet er en transportmekanisme som skalerer slik vanlige API-er gjør. Streamable HTTP er svaret: et enkelt tool-kall kan returnere et resultat direkte, mye som en REST-respons — forespørsel inn, JSON ut, forbindelse lukket. Men når en interaksjon trenger mer — en notifikasjon, en sampling-runde — kan serveren åpne en strøm og sende flere meldinger før den returnerer det endelige resultatet. Samme transport, to modi, valgt basert på hva interaksjonen faktisk trenger.
Sammen er autorisasjon og skalering det som lar MCP bevege seg fra «en protokoll for lokale utviklerverktøy» til en reell standard for hvordan LLM-applikasjoner snakker med nettet generelt.
Hva som kommer
Noen punkter på veikartet verdt å følge med på:
- Asynkrone tasks — primitiver for lengre kjørende agent-arbeid (timer, ikke sekunder), ikke bare request/response tool-kall.
- Elicitation — en måte for en server å be brukeren om input midt i en interaksjon, i stedet for å feile eller gjette.
- Et offisielt register — et sentralt sted for å finne og publisere MCP-servere, inkludert støtte for at agenter kan oppdage og installere servere dynamisk.
- Multimodalitet — streaming av resultater og andre evner utover tekst.
- Flere offisielle SDK-er — en Ruby-SDK donert av Shopify, og en offisiell Go-SDK under utvikling.
Hvorfor dette betyr noe utover spesifikasjonen
MCP er Anthropics protokoll, men det er en åpen spesifikasjon, og primitivene over er tilgjengelige for enhver server eller klient som implementerer dem — Claude inkludert. Det som er lett å overse utenfra, er at «MCP-støtte» ikke er én enkelt avkrysningsboks. En server som kun implementerer tools og en server som implementerer alle fem primitiver pluss ekstern autorisasjon, er begge «MCP-servere», men de muliggjør svært ulike klasser av integrasjon.
Det gapet er nøyaktig der vi bruker mesteparten av tiden vår når vi bygger agent-infrastruktur for kunder: ikke å koble opp ett enkelt tool-kall, men å designe hvilken primitiv som passer hvilken interaksjon, og — stadig oftere — å sette autorisasjonslaget foran slik at en MCP-server kan ligge bak eksisterende enterprise-SSO fremfor en lokalt kjørende binærfil ingen sentralt kontrollerer. Kjenner du igjen dette SSO-mønsteret fra egen IT-avdeling, er det nøyaktig den formen på arbeid vi bygger under Enterprise-løsninger.
Les også: Claude Cowork: Når AI-agenten flytter inn på skrivebordet — og hva norske SMB-er må strukturere først · Claude i nettleseren er ikke en AI-strategi