MCP (Model Context Protocol): definition, funktion og eksempler

En AI-agent, der kun kan tale med sig selv, gør ikke meget nytte. For virkelig at kunne handle skal den læse dine filer, forespørge dine databaser, skrive i dine værktøjer. MCP er protokollen, der er skabt for at standardisere denne forbindelse, i stedet for at genopfinde den for hvert nyt værktøj.

Detaljeret definition

Protokollens officielle side definerer den sådan: MCP er "en åben standard til at forbinde AI-applikationer til eksterne systemer", som giver dem adgang til datakilder (lokale filer, databaser), værktøjer (søgemaskiner, lommeregnere) og workflows (specialiserede prompts). Selve dokumentationen opsummerer ideen med et enkelt billede: MCP er «som en USB-C-port for AI-applikationer», en standardiseret forbindelse frem for et forskelligt kabel til hver enhed.

Protokollen blev annonceret af Anthropic den 25. november 2024. Annonceringen beskriver det problem, MCP forsøger at løse: AI-assistenter forblev isoleret fra data, der ellers var kritiske, hvor hver ny kilde krævede en skræddersyet implementering, hvilket skabte et integrationsproblem, der voksede for hvert nyt værktøj og hver ny model. Anthropic udgav samtidig specifikationen, udviklingskits og et repository med referenceservere til værktøjer som Google Drive, Slack, GitHub, Git eller Postgres. Se Anthropics annoncering.

IBM tilbyder en supplerende teknisk formulering: MCP er "et standardiseringslag, der gør det muligt for AI-applikationer at kommunikere effektivt med eksterne tjenester, som værktøjer, databaser eller foruddefinerede promptskabeloner". Denne beskrivelse understreger et ofte overset punkt: MCP fortæller ikke en agent, hvornår den skal bruge et værktøj, eller hvordan den skal orkestrere flere trin. Den standardiserer kun den måde, værktøjet beskrives og forbindes på. Se IBM's side om MCP.

Sådan fungerer det

MCP følger en klient-server-arkitektur med tre roller, beskrevet i detaljer i den officielle dokumentation og gengivet af Microsoft i deres .NET-dokumentation. MCP-værten (MCP host) er selve AI-applikationen, som en assistent eller en kodeeditor. Den opretter en dedikeret MCP-klient for hver tjeneste, den forbinder til. Hver klient opretholder en forbindelse til en MCP-server, det program der reelt eksponerer data eller handlinger. En MCP-server kan køre lokalt på brugerens maskine eller eksternt på værktøjsudbyderens servere.

Konkret eksponerer en MCP-server tre typer elementer: værktøjer (handlinger agenten kan udløse, som at forespørge en database eller sende en besked), ressourcer (data der kan tilgås, som indholdet af en fil) og prompts (genanvendelige forespørgselsskabeloner). Klienten forespørger først serveren for at få at vide, hvad den tilbyder, og kan derefter kalde et præcist værktøj med præcise argumenter, en funktionsmåde tæt på den, der beskrives i vores artikel om tool calling.

Det er netop her, kilderne er uenige om MCP's præcise omfang. IBM og Microsoft er enige om, at MCP ikke erstatter tool calling: det er den underliggende mekanisme, den hvorigennem en model konkret anmoder om udførelsen af en handling. Det, MCP tilføjer, er en fælles måde at beskrive og opdage disse værktøjer på, uafhængig af modeludbyderen, hvor hver udbyder tidligere pålagde sit eget kaldformat. På samme måde erstatter MCP ikke klassiske API'er: Microsofts .NET-dokumentation præciserer, at en MCP-server "kan levere en abstraktion oven på en REST-API" for at eksponere forretningsdata til en model. MCP er altså en fælles facade lagt over eksisterende API'er, ikke en teknologi der gør dem overflødige.

En MCP-server kan også eksponere en dokumentbase, der kan forespørges før et svar gives, en anvendelse der direkte overlapper princippet bag RAG: søg først i en pålidelig kilde, generér derefter svaret ud fra det, der er fundet.

Konkret eksempel fra Atako

Atakos Standard-plan lister "Atako MCP" blandt sine inkluderede funktioner, sammen med integrationer, observerbarhed eller BYOK, på siden priser. En API-nøgle, der genereres fra kontoindstillingerne, bruges blandt andet til at forbinde eksterne MCP-klienter til platformen.

Resten af den præcise implementering, hvilke servere, hvilke værktøjer der eksponeres i detaljer, er ikke offentligt dokumenteret på nuværende tidspunkt. Det er bedst at holde sig til fakta på dette punkt frem for at gætte på en liste af værktøjer eller en lanceringsdato.

Almindelige fejl

Første fejl: at tro, at MCP er en helt ny mekanisme, der erstatter tool calling. Det er ikke tilfældet, MCP standardiserer beskrivelsen og opdagelsen af værktøjer, men selve kaldet forbliver et klassisk funktionskald, produceret af modellen.

Anden fejl: at tro, at en "MCP-server" nødvendigvis betegner en stor ekstern maskine. Den officielle dokumentation skelner tydeligt mellem lokale servere, der kører på brugerens computer og kommunikerer lokalt, og eksterne servere, hostet af værktøjsudbyderen og tilgængelige via HTTP.

Tredje fejl: at forveksle MCP med en sikkerhedsgaranti i sig selv. Protokollen standardiserer den måde, en model opdager og kalder et værktøj på, den bestemmer ikke i modellens sted, hvilke tilladelser der gives til dette værktøj. På en seriøs platform forbliver denne beslutning et separat lag, uafhængigt af den anvendte forbindelsesprotokol.

Fjerde fejl: at tro, at ethvert værktøj, der forbindes til en agent, nødvendigvis går gennem MCP. Mange agenter, herunder dem der bruger integrationer som GitHub eller Slack, kalder handlinger via klassisk tool calling uden at gå gennem en dedikeret MCP-server. Atako dokumenterer ikke offentligt detaljerne om de værktøjer, der eksponeres af deres eget MCP: MCP forbliver én forbindelsesmulighed blandt flere, ikke en obligatorisk vej for at give en agent værktøjer.

Lær mere

MCP har relativt hurtigt etableret sig som en standard, der understøttes af et bredt økosystem: den officielle dokumentation nævner applikationer som Claude eller kodeeditorer som Visual Studio Code og Cursor blandt de kompatible MCP-klienter. For at forstå de beslægtede byggesten i denne protokol, gå til den samlede ordliste, med begreberne tool calling, RAG og BYOK, alle mekanismer til forbindelse eller konfiguration på modelsiden.