Grunnleggende AI
Hva er Model Context Protocol (MCP)? Standarden som kobler AI til verktøy og data
Model Context Protocol gir AI‑applikasjoner en standard måte å oppdage og bruke verktøy, data, prompt‑meldinger og andre funksjoner på. Denne guiden forklarer MCPs arkitektur, primitive, sikkerhetsgrenser og plass i agent‑stakken.
Legg til Unite.AI blant dine foretrukne kilder på Google
Model Context Protocol (MCP) er en åpen standard som gjør det mulig for AI‑applikasjoner å koble seg til eksterne verktøy, data, prompt og andre funksjoner via et konsistent grensesnitt. I stedet for å bygge en tilpasset integrasjon for hver modell‑og‑system‑kombinasjon, kan utviklere implementere en felles protokoll mellom en AI‑vert og en MCP‑server.
MCP blir ofte beskrevet som en universell kobling for AI, men analogien er ufullstendig. Protokollen flytter ikke bare data. Den definerer hvordan deltakere etablerer funksjoner, eksponerer ressurser og handlinger, utveksler strukturerte meldinger, og opprettholder sikkerhetsgrenser. Dette gjør den til en viktig del av den fremvoksende infrastrukturen for AI‑assistenter og agenter.
Hvorfor MCP eksisterer
En modell alene kan ikke se et selskaps private dokumenter, inspisere et lokalt lager, forespørre en levende database eller kalle en intern tjeneste. Utviklere har historisk koblet disse funksjonene sammen via engangsplug‑ins og applikasjonsspesifikke API‑er.
Den tilnærmingen skaper et integrasjonsproblem. Hvis ti AI‑applikasjoner hver trenger å koble seg til ti systemer, kan team ende opp med å vedlikeholde dusinvis av skreddersydde adaptere. Hver adapter kan representere verktøy, kontekst, autentisering, feil og oppdateringer på ulike måter.
MCP skaper en felles kontrakt. En MCP‑kompatibel applikasjon kan kommunisere med MCP‑servere som eksponerer funksjoner i et kjent format. Den offisielle Model Context Protocol-spesifikasjonen definerer protokollen, mens individuelle verter og servere bestemmer hvilke funksjoner og sikkerhetspolicyer de støtter.
MCP‑arkitekturen
MCP skiller AI‑applikasjonens samtale‑ og modelllogikk fra integrasjonslogikken som kreves av hver datakilde eller tjeneste. Vert kan opprettholde flere klienttilkoblinger samtidig – én for en filsystem‑server, én for en database‑server og en annen for en forretningsapplikasjon – samtidig som den presenterer deres funksjoner for modellen via et konsistent grensesnitt.
Serveren er ikke nødvendigvis en ekstern internett‑tjeneste. Den kan kjøre lokalt ved siden av en skrivebordsapplikasjon, inne i et bedriftsnettverk, eller som en fjerntjeneste. Dette distribusjonsvalget endrer transport‑ og tillitsgrensen, men ikke det sentrale forholdet: en klient oppdager funksjoner fra en server og utveksler strukturerte meldinger med den.
MCP bruker en vert‑klient‑server‑arkitektur.
- Host: AI‑applikasjonen brukeren interagerer med, for eksempel en assistent, et kode‑miljø eller en agent‑plattform.
- Client: en protokollkomponent opprettet av verten for å opprettholde en tilkobling til en bestemt MCP‑server.
- Server: et program som eksponerer utvalgte verktøy, ressurser eller prompt til MCP‑klienter.
En vert kan koble seg til flere servere samtidig. En server kan gi tilgang til et filarkiv, en annen til et prosjektstyringssystem, og en tredje til en intern database. Vert forblir ansvarlig for brukeropplevelsen, modell‑orkestrering, samtykke og informasjonen som plasseres i modellkonteksten.
Meldinger er strukturert ved bruk av JSON‑RPC‑konvensjoner. Under initiering forhandler deltakerne om protokollversjoner og funksjoner. Denne forhandlingen er viktig fordi klienter og servere ikke trenger å implementere hver valgfri funksjon.
Verktøy, ressurser og prompt
| Vert | AI‑applikasjonen som koordinerer brukeropplevelsen og tillatelser. |
|---|---|
| Klient | Protokolltilkoblingen som vedlikeholdes av verten for én server. |
| Server | Programmet som eksponerer verktøy, ressurser eller prompt. |
| Resultat | Strukturerte data som returneres til verten etter en godkjent påkalling. |
MCP organiserer server‑leverte kapasiteter i flere primitive. De tre mest kjente er verktøy, ressurser og prompt.
Verktøy
Et verktøy er en kjørbar funksjon som AI‑applikasjonen kan påkalle. Eksempler inkluderer søk i en kundedatabase, opprettelse av en sak, kjøring av en spørring eller henting av gjeldende lagerbeholdning. En verktøysdefinisjon inneholder et navn, en beskrivelse og et inndataskjema slik at modellen og kjøretiden vet hvilke argumenter som forventes.
Bruk av verktøy kan endre eksterne systemer, så verter bør vise meningsfulle beskrivelser, validere inndata, anvende tillatelser og kreve bekreftelse for konsekvensfulle handlinger.
Ressurser
En ressurs er kontekst som en applikasjon kan lese, for eksempel en fil, en databasepost, en dokumentasjons‑side eller en generert rapport. Ressurser bruker identifikatorer og kan eksponere metadata som navn og medietype. De gir verter en standardisert måte å oppdage og hente informasjon på uten å late som om hver leseoperasjon er en handling.
Prompt
Prompt er gjenbrukbare maler eller arbeidsflyter som en server gjør tilgjengelige for verten. De kan hjelpe brukere med å påkalle en funksjon korrekt, levere strukturerte argumenter, eller kombinere domenespesifikke instruksjoner med relevant kontekst.
MCP støtter også kapasiteter i motsatt retning. Avhengig av hva som forhandles, kan en server be verten om å hente modell‑fullføringer eller brukerinput. Det viktige designprinsippet er eksplisitt kapasitetsforhandling i stedet for å anta at hver deltaker kan utføre enhver operasjon.
Hva skjer under et MCP‑verktøykall?
Tenk deg en AI‑kodeassistent koblet til en server for analyse av kodearkiv.
- Verten kobler til MCP‑serveren og forhandler støttede kapasiteter.
- Klienten ber om listen over tilgjengelige verktøy.
- Serveren returnerer strukturerte verktøysdefinisjoner, inkludert deres inndataskjemaer.
- Verten gjør valgte verktøysbeskrivelser tilgjengelige for modellen.
- Modellen foreslår et verktøykall, for eksempel søk etter referanser til en funksjon.
- Verten sjekker policy og, når nødvendig, ber brukeren om godkjenning.
- Klienten sender den validerte forespørselen til serveren.
- Serveren utfører operasjonen og returnerer strukturert innhold eller en feil.
- Verten bestemmer hvilken del av resultatet som skal gis til modellen for neste steg.
MCP standardiserer utvekslingen, men bestemmer ikke om modellen skal få lov til å påkalle et verktøy. Den beslutningen tilhører verten og dens policy‑lag.
MCP erstatter ikke API‑er
En MCP‑server omslutter ofte eksisterende API‑er, programvare‑utviklingssett, kommandolinjeverktøy eller databasedrivere. De underliggende grensesnittene utfører fortsatt selve arbeidet. MCP legger til et AI‑orientert oppdagelses‑ og interaksjonslag over dem.
Dette skillet forklarer hvorfor MCP er komplementært til REST, GraphQL og andre applikasjonsgrensesnitt. En betalingstjeneste kan beholde sitt modne API mens en MCP‑server eksponerer et nøye begrenset delsett av operasjoner med modell‑vennlige beskrivelser og skjemaer.
MCP vs. funksjonskalling
Funksjons‑ eller verktøykalling er en modellkapasitet: modellen kan returnere en strukturert forespørsel for å påkalle en funksjon. MCP er en protokoll for å oppdage og kommunisere med leverandører av verktøy og kontekst.
De to arbeider ofte sammen. En MCP‑server forteller verten hvilke verktøy som finnes. Vertens presenterer valgte definisjoner for en modell. Modellen sender et verktøykall. Vertens bruker deretter MCP til å sende den forespørselen til riktig server.
MCP vs. Agent2Agent
MCP kobler en AI‑applikasjon til kapasiteter og kontekst. Agent2Agent, eller A2A, fokuserer på kommunikasjon mellom autonome agenter som kan eies av ulike systemer eller organisasjoner.
Et praktisk system kan bruke begge. En agent kan bruke MCP for å få tilgang til sine verktøy og data, og deretter bruke A2A for å delegere en større oppgave til en annen agent. MCP svarer på «Hvordan kan denne applikasjonen bruke den kapasiteten?», mens A2A svarer på «Hvordan kan disse agentene koordinere arbeidet?»
Sikkerhetsrisikoer og kontroller
En sikker vert opprettholder en eksplisitt tillatelsesliste over servere og verktøy, viser meningsfullt samtykke når tilgang gis, og knytter hver samtale til brukeren eller arbeidsbelastningsidentiteten som autoriserte den. Verktøyskjemaer bør være så smale at de avviser uventede argumenter, mens revisjonslogger bør registrere serveren, funksjonen, inndata, resultatstatus og godkjenningsvei.
Returnerte ressurser og verktøyresultater er også en overflate for prompt‑injeksjon. Et dokument som leses via MCP kan inneholde tekst som ber modellen om å ignorere instruksjonene sine eller eksfiltrere data. Vert må opprettholde skillet mellom upålitelig innhold og systempolicy, og bør hindre at én servers output stille utvider en annen servers tillatelser.
Standardisering forbedrer interoperabilitet, men gjør ikke en server pålitelig. En MCP‑server kan eksponere sensitiv data, misvisende verktøysbeskrivelser, usikre handlinger eller kompromitterte avhengigheter. Upålitelig innhold hentet via en ressurs kan også inneholde prompt‑injeksjonsinstruksjoner ment å manipulere modellen.
Viktige kontroller inkluderer:
- Minste privilegium: gi hver server kun de legitimasjonene og omfanget som trengs for formålet.
- Servertillit: verifiser kilde, kode, eierskap og oppdateringssti for servere før de kobles til.
- Brukersynlighet: gjør det tydelig hvilken server som vil motta data og hvilken handling den vil utføre.
- Inndata‑validering: håndhev skjemaer og forretningsregler utenfor modellen.
- Godkjenningsgrenser: bekreft sensitive, eksterne, finansielle eller destruktive handlinger.
- Dataminimering: unngå å sende hele dokumenter eller samtaler når kun en liten del er nødvendig.
- Logging og tilbakekalling: registrer samtaler, overvåk avvik, og gjør legitimasjon og tilkoblinger enkle å deaktivere.
MCP‑prosjektet fortsetter å finpusse arkitekturen og sikkerhetsveiledningen. Prosjektets 2026 spesifikasjonsoppdatering illustrerer hvordan standarden utvikler seg rundt enklere infrastruktur, autorisasjon og produksjonsutplassering.
Når bør utviklere bruke MCP?
MCP er en god løsning når flere AI‑klienter trenger en konsistent tilkobling til samme funksjon, når verktøy skal kunne oppdages ved kjøring, eller når et team ønsker å skille AI‑orchestrering fra systemspesifikk integrasjonskode.
Et direkte funksjonskall kan fortsatt være enklere for en liten applikasjon med én stramt kontrollert backend. Adoptasjon av protokollen medfører eget operasjonelt arbeid: håndtering av serverlivssyklus, kompatibilitetstesting, autentisering, observabilitet og styring.
Hva du bør huske om Model Context Protocol (MCP)
MCP er et felles språk mellom AI‑applikasjoner og verktøyene og konteksten rundt dem. Verdien ligger i å erstatte isolerte integrasjonskonvensjoner med en oppdagbar, strukturert og utvidbar protokoll.
Standarden fjerner ikke behovet for grundig engineering. Vertene må fortsatt avgjøre hvilke servere de skal stole på, hvilke funksjoner som skal eksponeres, hvilke data som skal deles, og når en person må godkjenne en handling. MCP gjør tilkoblinger portable; styring gjør dem trygge og nyttige.
