MCP forklaret op mod specifikationen: hvad en server egentlig er

Før wiren, regnestykket. Du har $N$ AI-applikationer og $M$ ting, de burde kunne nå — en kalender, et ticket-system, en warehouse-database, et designværktøj. Uden en fælles kontrakt skriver nogen $N \times M$ integrationer, og hver eneste af dem er et schema plus et endpoint plus en autentificeringshistorie plus en vedligeholdelsesbyrde. Med én skriver tool-leverandøren en server, applikationsleverandøren skriver en client, og totalen er $N + M$.

Det er ikke en ny observation, og specifikationen siger, hvis idé det var:

MCP takes some inspiration from the Language Server Protocol, which standardizes how to add support for programming languages across a whole ecosystem of development tools. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.¹

Tag den sammenligning bogstaveligt, ikke som en kompliment. Før den protokol betød understøttelse af et sprog i en editor et plugin per editor; bagefter udgav et sprogteam én server, og alle editorer fik den. Succeskriteriet var ikke elegance, men at antallet af integrationer holdt op med at multiplicere. Det samme gælder her: værdien ligger i antallet af implementeringer, ikke i designet. En protokol, som to produkter taler, er et dataformat med ekstra ceremoni.

MCP-beskeder er JSON-RPC 2.0. En request er et objekt med jsonrpc, et id, en method og valgfri params; et response bærer det samme id og enten result eller error; en notification er en request uden id og får intet svar. Specifikationen tilføjer tre begrænsninger ovenpå: id skal være en string eller et tal og må ikke være null, det må ikke kollidere med en anden request, der stadig er in flight, og hvert result skal bære et resultType-felt.²

På stdio-transporten — den kommandoen ovenfor brugte — er framing-reglen én linje per besked:

Messages are delimited by newlines, and MUST NOT contain embedded newlines. […] The server MUST NOT write anything to its stdout that is not a valid MCP message.³

Den sidste sætning er den mest almindelige måde, en hjemmelavet server går i stykker på, og den går i stykker lydløst: et tilfældigt console.log, en progress bar, en deprecation warning fra en dependency, og clientens line parser rammer noget, der ikke er JSON. Nødudgangen står i samme afsnit — serveren må skrive hvad som helst til stderr, og clienten bør ikke behandle det som en fejl. Reference-serveren ovenfor printer Starting default (STDIO) server... ved hver start, på stderr, og derfor virkede pipen stadig.

Den anden standardtransport er Streamable HTTP: hver besked er en POST til et enkelt endpoint, og svaret er enten et JSON-objekt eller en request-scoped stream af Server-Sent Events — wire-formatet Kapitel 14 parsede i hånden. Semantikken er identisk på begge, fordi en transport er en binding: den definerer framing og levering, ikke betydning.⁴

Kommandoen ovenfor sendte tools/list og intet andet. Under den nuværende revision er den request malformed, og en conformant server skal afvise den.

Siden 2026-07-28 har MCP været en stateless protokol, og specifikationen siger det uden forbehold:

The Model Context Protocol (MCP) is a stateless protocol: all the information needed to process a request is contained in the request itself. A server processes each request independently; no state should be inferred from previous requests, even those on the same connection or stream.²

Så hver request bærer sin egen protocol version og sine egne client capabilities i et reserveret _meta-objekt inde i params. To af de felter er påkrævet på hver eneste request; en request, der mangler et af dem, er malformed, og serveren skal svare -32602:²

Skrevet ud er en korrekt tools/list sådan her — og det er sidste gang, kapitlet viser metadataene i fuld længde, fordi de er på hver request herfra:

{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{"elicitation":{"form":{}}},
  "io.modelcontextprotocol/clientInfo":{"name":"bare-hands","version":"0.0.1"}}}}

Capability-objektet er forhandlingen. Der er ikke længere et separat negotiation step: clienten erklærer, hvad den kan på hver request, serveren erklærer, hvad den kan i resultatet, og ingen af siderne må bruge en feature, den anden ikke har claimed. En server, der har brug for en capability, clienten ikke erklærede, skal svare -32021 og navngive den manglende capability i data.requiredCapabilities. En server, der ikke taler den efterspurgte version, skal svare -32022 og liste de versioner, den taler.²

Clients, der vil have svaret på forhånd, kan bede om det: server/discover er en obligatorisk RPC, der returnerer understøttede versioner, capabilities, identity og en valgfri blok med instructions i én round trip.⁵ Det er valgfrit at kalde den. Det er ikke valgfrit at implementere den.

Kommandoen virkede. Under den nuværende revision burde den ikke have gjort det, og grunden til, at den gjorde, er værd at måle frem for at beskrive i et afsnit, fordi det er hele økosystemets tilstand på én linje.

Probe reference-serveren sådan som specifikationen siger, at en modern client skal probe:

echo '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{}}}}' \
  | npx @modelcontextprotocol/server-everything stdio

{"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found"}}

Det er den tredje gren af kompatibilitetsreglen: en DiscoverResult betyder modern, en genkendt modern error betyder modern-men-forkert-version, og alt andet — inklusive -32601 — betyder legacy, fald tilbage til initialize-handshaket.³ Så gør det, og bed om den nuværende revision:

→ {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-07-28",
   "capabilities":{},"clientInfo":{"name":"bare-hands","version":"0.0.1"}}}

← {"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{"listChanged":true},
   "prompts":{"listChanged":true},"resources":{"subscribe":true,"listChanged":true},
   "logging":{},"tasks":{…},"completions":{}},"serverInfo":{"name":"mcp-servers/everything",
   "title":"Everything Reference Server","version":"2.0.0"},"instructions":"…"}}

Clienten bad om 2026-07-28, og serveren svarede 2025-11-25. Den 7. september 2026 implementerer den officielle reference-server — npm-pakken @modelcontextprotocol/server-everything, version 2026.8.31, udgivet 31. august 2026 — ikke den nuværende revision. Det gør TypeScript-SDK'et, den er bygget på, heller ikke på datoerne: release 1.30.0 udkom 27. juli 2026, dagen før revisionen gjorde.

Læs konsekvensen, ikke sladderen. Næsten alt, der er skrevet om MCP, beskriver en protokol med et initialize-handshake, en session, en roots/list-request serveren sender til clienten, og en HTTP+SSE-transport. Alle fire er væk eller på vej væk. Når du læser noget om MCP, inklusive denne side, er det første du skal lede efter et revisionsnummer.

Og grunden til, at den allerførste kommando virkede, står i specifikationen som en hazard, ikke en feature:

some legacy servers do not validate that a request arrives after initialize and would process an era-ambiguous method (such as tools/call) under legacy semantics. Probing yields a deterministic failure instead.³

Målt: at sende tools/list til den server uden noget handshake overhovedet returnerer hele kataloget. En metode, der burde være blevet afvist, blev serveret, og det er præcis derfor specifikationen siger, at man skal probe med server/discover først, selv når man kun understøtter modern versions.

MCP har tre parter, og skellet mellem de første to er det, folk kollapser:

Server. En proces eller en service, der eksponerer ressourcer, værktøjer og prompts. Den kan være lokal eller remote, den opererer uafhængigt, og hele dens job er ét fokuseret område.⁶

Reglen om "præcis én server" er ikke bogholderi. Det er det, der gør designprincippet nedenfor implementerbart, og dette er sætningen, du skal tage med fra specifikationen, hvis du kun tager én:

Servers should not be able to read the whole conversation, nor "see into" other servers. Servers receive only necessary contextual information. Full conversation history stays with the host. Each server maintains isolation. Cross-server interactions are controlled by the host.⁶

Det vælter den mentale model, de fleste kommer med. En vejrserver, du forbinder til din assistant, ser ikke hvad du spurgte om. Den ser et tools/call med de argumenter, modellen valgte, og intet andet — ikke de foregående turns, ikke din system prompt, ikke de resultater kalender-serveren returnerede et øjeblik tidligere. Hvis to servere skal samarbejde, bærer hosten en værdi fra den ene til den anden, bevidst, fordi modellen bad om det. Derfor er isolation den sikkerhedsegenskab, Kapitel 30 læner sig op ad: en compromised server har en lille, defineret blast radius, og at udvide den kræver, at hosten samarbejder.

Den første kommando bad serveren om værktøjer og fik tretten. Stil den de to andre spørgsmål, og den svarer også på dem: resources/list returnerer syv, prompts/list returnerer fire. Ingen af dem dukkede op, fordi intet spurgte. Det bringer os til MCP's pædagogiske rygrad, der ligger i specifikationen som en tabel, næsten ingen citerer:

Ikke "tre måder at eksponere en capability på". Tre svar på hvem der beslutter, at dette sker. Modellen beslutter at kalde et værktøj. Applikationen beslutter at vedhæfte en ressource. Personen beslutter at køre en prompt. Får du det forkert, virker featuren stadig, men den virker på det forkerte tidspunkt og af den forkerte grund.

Den klareste måde at mærke det på er en kalender. Her er en server, der eksponerer den samme kalender tre gange, én gang som hver primitiv, i hundrede linjer plain Node uden dependencies:

const TOOL = {
  name: "create_event",
  description: "Create a calendar event. Writes to the calendar.",
  inputSchema: {
    type: "object",
    properties: {
      title:    { type: "string", description: "Event title." },
      startsAt: { type: "string", format: "date-time", description: "Start, ISO 8601 UTC." },
    },
    required: ["title"],
  },
};

switch (method) {
  case "resources/read":                                          
    return ok(id, { contents: [{ uri: "calendar://week",
      mimeType: "application/json", text: JSON.stringify(EVENTS) }],
      ttlMs: 60000, cacheScope: "private" });

  case "prompts/get":                                             
    return ok(id, { description: PROMPT.description, messages: [{ role: "user",
      content: { type: "text", text: `Read calendar://week and draft a plan. ` +
        `Focus: ${params.arguments?.focus ?? "balance"}.` } }] });

  case "tools/list":                                              
    return ok(id, { tools: [TOOL], ttlMs: 300000, cacheScope: "public" });
}

Kør den, og spørg den på alle tre måder. Rigtigt output, én besked per linje på wiren, ombrudt her til siden, med request _meta og serverens identity block udeladt:

→ resources/read  {"uri":"calendar://week"}
← {"resultType":"complete","contents":[{"uri":"calendar://week",
   "mimeType":"application/json","text":"[{\"id\":\"e1\",\"title\":\"Standup\",
   \"startsAt\":\"2026-09-07T09:00:00Z\"},{\"id\":\"e2\",\"title\":\"Design review\",
   \"startsAt\":\"2026-09-09T15:00:00Z\"}]"}],"ttlMs":60000,"cacheScope":"private"}

→ prompts/get    {"name":"prepare_week","arguments":{"focus":"deep work"}}
← {"resultType":"complete","description":"Read the week and draft a plan.",
   "messages":[{"role":"user","content":{"type":"text",
   "text":"Read calendar://week and draft a plan. Focus: deep work."}}]}

→ tools/call     {"name":"create_event","arguments":{"title":"Dentist",
                  "startsAt":"2026-09-10T08:30:00Z"}}
← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],
   "structuredContent":{"id":"e3","title":"Dentist","startsAt":"2026-09-10T08:30:00Z"},
   "isError":false}

Tre metoder, tre former, én kalender. Nu pointen:

Næsten alle gør alle tre af disse til værktøjer. Resultatet er et katalog, hvor en læsning, applikationen burde have vedhæftet lydløst, konkurrerer om modellens attention med en skrivning, der kræver approval, og hvor den ene ting, en person ville have en knap til, er begravet i et schema. Det koster ingenting at gøre rigtigt, og det afgøres, før du skriver en linje.

Kalenderværktøjet har ét påkrævet argument, title, og et valgfrit startsAt. Bed den om at oprette en begivenhed uden en dato, og noget interessant kommer tilbage:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"}}

← {"resultType":"input_required",
   "inputRequests":{"when":{"method":"elicitation/create","params":{"mode":"form",
     "message":"When should \"Dentist\" start?",
     "requestedSchema":{"type":"object",
       "properties":{"startsAt":{"type":"string","format":"date-time"}},
       "required":["startsAt"]}}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

Serveren sendte ikke en request. Den besvarede den, den fik, med resultType: "input_required" og en beskrivelse af, hvad den stadig mangler. Clienten indsamler svaret fra personen og sender derefter det oprindelige call igen — med et nyt id, med inputResponses og med det opaque requestState ekkoet tilbage:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"},
   "inputResponses":{"when":{"action":"accept",
     "content":{"startsAt":"2026-09-10T08:30:00Z"}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],"isError":false}

Dette er Multi Round-Trip Requests, introduceret i den nuværende revision, og det erstattede det ældre design, hvor servere sendte JSON-RPC requests tilbage til clients. Transport-specifikationen fastslår nu reglen direkte: "servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses".⁴ Der er én retning for initiativ, og den tilhører hosten.

To client-side features rider på den mekanisme, og den ene har et navn, der vil få dig til at snuble.

Elicitation er serveren, der beder personen om noget: en formular med et bevidst begrænset JSON Schema — flade objekter, primitive properties, ingen nesting — så enhver client kan render den uden en layout engine. Den bærer en hård regel: servere må ikke bruge form mode til at bede om "passwords, API keys, access tokens, or payment credentials", og skal bruge URL mode til det, som sender brugeren til en side, clienten aldrig læser.⁷

Sampling er serveren, der beder hostens model om en generation, så en server kan være intelligent uden at holde en API key. Og her er ordforrådsadvarslen, fordi dette ord allerede betyder noget andet i dette kursus: det er ikke Kapitel 17's sampling. Intet her handler om temperature, top-p eller formen på en probability distribution. Det er et nested model call, der rejser baglæns gennem en protokol.

Der er en anden grund til ikke at række ud efter det: fra denne revision er sampling deprecated, sammen med roots og logging, under SEP-2577, med en direkte foreslået migration — "integrate directly with LLM provider APIs instead of Sampling".⁸ Idéen fejlede ikke teknisk; den fejlede i at retfærdiggøre sit surface area, og en protokol, der kan fjerne ting, er sundere end en, der ikke kan.

Statelessness lyder som en wire-format-detalje, indtil du tester den. Tag trebeskeds-udvekslingen ovenfor og kør hver besked i en separat proces — en frisk node calendar.mjs, ingen delt hukommelse, intet båret videre:

process A   tools/call (no date)   → resultType: input_required
                                     requestState: eyJ0aXRsZSI6IkRlbnRpc3QifQ==
process B   tools/call (with the answer, same requestState)
                                   → resultType: complete
                                     "Created e3: Dentist at 2026-09-10T08:30:00Z"
process C   resources/read calendar://week
                                   → events: 2  (Standup, Design review)

Proces B, som aldrig så spørgsmålet, fuldførte et multi-round-trip call, som proces A startede. Det er pointen med requestState: continuation rejser i beskeden, så intet afhænger af, at processen er den samme.

Proces C er fejlen. Begivenheden blev oprettet, og den er ikke der — fordi toy-serveren holder EVENTS i et module-level array, og et module-level array er connection state. Specifikationens note navngiver fejlen præcist:

an open connection, such as a STDIO process, is not a conversation or session: clients may interleave unrelated requests on the same transport, and a server must not treat connection or process identity as a proxy for conversation or session continuity.²

Den foreskrevne løsning er ikke en session. Det er et explicit handle: et creation tool returnerer en opaque identifier, og hvert senere call tager den som et almindeligt argument. Protokollen har slet intet begreb om det — "from the wire's perspective a handle is an ordinary string in a tool result and an ordinary argument to subsequent tool calls".⁹ Det sætter modellen til at bære den, og serveren til at validere, at denne caller har lov til at bruge den på hvert eneste call, fordi et handle er et navn og ikke en tilladelse.

Hvert værktøj, en server eksponerer, er et schema, der går ind i din prompt på hver request, og Kapitel 24 målte, hvad det gør ved et window. MCP tilføjer en anden linjepost, der er let at overse, så begge er værd at tælle på reference-serveren ovenfor.

13 tool definitions (name + description + inputSchema):  1,307 tokens
  cheapest tool, get-tiny-image                              52
  costliest tool, gzip-file-as-resource                     235
server `instructions`, returned by discovery:               312 tokens
                                                          ------
one server, connected, before it is used:                 1,619 tokens

To observationer. Den første er regning: forbind fem servere af denne størrelse, og omtrent otte tusind tokens af dit window er optaget på hvert turn, for altid, uanset om modellen bruger nogen af dem eller ej — hvilket er mekanismen bag reduktionen fra 150.000 til 2.000, som Kapitel 24 citerede, og grunden til at just-in-time tool discovery findes.

Den anden er en sikkerhedsnote i regnskabskostume. instructions er natural-language text, skrevet af serverforfatteren, der lander i hostens prompt, og tool-beskrivelserne ved siden af er det samme. Specifikationen siger, hvad man skal gøre ved det i sine egne sikkerhedsprincipper: tool annotations og descriptions "should be considered untrusted, unless obtained from a trusted server", og hosts "must obtain explicit user consent before invoking any tool".¹ At forbinde en MCP-server er ikke at tilføje en dependency. Det er at give en fremmed 1.619 tokens af din system prompt og retten til at blive kaldt. Kapitel 30 er, hvad der sker, når den fremmede er fjendtlig.

Alt i dette afsnit er sandt for protocol revision 2026-07-28, den nuværende, læst 7. september 2026. Revisioner dateres YYYY-MM-DD, og datoen er sidste gang, der blev lavet en bagud-inkompatibel ændring.¹⁰ Det normative dokument er en TypeScript-fil, schema/2026-07-28/schema.ts; JSON Schemaet ved siden af genereres fra den, og derfor læses specifikationen her i TypeScript, og derfor er det at undervise i MCP fra noget andet at undervise i en oversættelse.

Governance-ændringen under den tabel betyder mere end nogen enkelt række. Denne revision indførte en feature lifecycle and deprecation policy: features er Active, Deprecated eller Removed, en deprecated feature dokumenterer sin migration path og bliver i specifikationen i mindst tolv måneder, før den kan fjernes, og der er et registry, der lister alt, der aktuelt er i Deprecated state.⁸ Før den policy betød "deprecated" i en AI-protokol det, det seneste blogindlæg sagde. Nu betyder det en dato.

Dette er ordforrådet for hele blokken samlet ét sted.

To af dem fortjener en sætning hver, fordi det er der, forvirringen faktisk bor.

MCP mod A2A er ikke en rivalisering, og begge specifikationer siger det. A2A-dokumentationen trækker grænsen efter, hvad der er i den anden ende: MCP "defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API", hvor et værktøj udfører "specific, often stateless, functions"; A2A adresserer agents, "more autonomous systems" der "reason, plan, use multiple tools, maintain state over longer interactions, and engage in complex, often multi-turn dialogues". Dens egen opsummering er sætningen at huske: "A2A is about agents partnering on tasks, while MCP is more about agents using capabilities."¹¹ De to kan nestes — en applikation bruger A2A til at nå andre agents, og hver agent bruger MCP til at nå sine egne værktøjer. Kapitel 25 trak den grænse inde i én proces, mellem at spørge en sub-agent og overdrage den samtalen; A2A trækker den mellem organisationer.

MCP mod ACP er en sammenligning med en forældet præmis, og netop derfor er den værd at besvare. Agent Communication Protocol var en separat åben standard for agent-to-agent messaging. Dens egen dokumentation åbner nu med beskeden: "ACP is now part of A2A under the Linux Foundation!"¹² Det ærlige svar på "MCP or ACP?" i september 2026 er, at spørgsmålet har én mulighed færre, end de sider, der ranker for det, antyder.

Og den sammenligning, folk oftest beder om, mcp vs api, har det mindst interessante svar: MCP er en API. Det, den tilføjer, er ikke power, men conventions — et fast sæt method names, et discovery call, et kontrolhierarki over primitiverne og en isolation model. Du giver friheden til at designe dit eget interface væk, og du får hver host, der taler protokollen, hvilket er den handel, enhver protokol altid har tilbudt.

Du kan nu læse specifikationen uden en oversætter, skelne en resource fra et værktøj fra en prompt efter hvem der styrer den, skrive en request i hånden når et client library lyver for dig, og datere enhver MCP-artikel, du læser, efter hvilke deprecated features den stadig underviser som aktuelle.

Det, du ikke har gjort, er at shippe én. Kapitel 27 skriver den samme server to gange — TypeScript og Python side om side, fordi MCP er det ene reelt tosprogede territorium i dette kursus, og tallene siger det i begge retninger. Det dækker de to live transports ordentligt, inspectoren, packaging og den halvdel af protokollen, dette kapitel bevidst lod ligge: authorization. For i det øjeblik din server er remote i stedet for en subprocess på din egen laptop, vil en fremmeds client præsentere et token, og specifikationens regel om, hvad du må gøre med det, er usædvanligt streng.

Det rejser spørgsmålet, næste kapitel skal besvare, og det er ikke venligt: hvis et token ankommer til din server, og det blev udstedt til en andens audience, hvad stopper dig så præcist fra at videresende det?

Hvert citat, method name, error code og regel i dette kapitel blev læst fra Model Context Protocol-specifikationen, revision 2026-07-28, den 7. september 2026. Hver trace blev produceret lokalt på Node 22: toy-kalender-serveren er 101 linjer uden dependencies, og reference-serveren er den udgivne npm-pakke navngivet nedenfor. Ingen betalt API blev kaldt for at skrive dette kapitel — intet her kræver en model, hvilket i sig selv er pointen.

Målingerne: @modelcontextprotocol/server-everything@2026.8.31, udgivet 31. august 2026, bygget på @modelcontextprotocol/sdk@1.30.0, udgivet 27. juli 2026 — én dag før den revision, dette kapitel beskriver. Den svarer server/discover med -32601, forhandler 2025-11-25 når den bliver spurgt om 2026-07-28, og serverer tools/list uden noget handshake overhovedet. Dens katalog er 13 tools i 7.663 bytes; token counts er o200k_base via tiktoken, over name, description og inputSchema i hver definition, hvilket er det, en provider render ind i din prompt, og ikke hvad JSON-RPC-framen vejer.

Anthropic, Code execution with MCP: building more efficient agents, 4. november 2025, er kilden til 150.000-til-2.000-tallet, citeret og brugt i Kapitel 24 og kun refereret her.