MCP förklarat mot specifikationen: vad en server egentligen är

Före wire, aritmetiken. Du har $N$ AI-applikationer och $M$ saker de borde kunna nå — en kalender, ett ärendehanteringssystem, en lagerdatabas, ett designverktyg. Utan ett gemensamt kontrakt skriver någon $N \times M$ integrationer, och var och en är ett schema plus en endpoint plus en autentiseringshistoria plus en underhållsbörda. Med ett sådant skriver tool-leverantören en server, applikationsleverantören skriver en client, och totalsumman blir $N + M$.

Det är ingen ny iakttagelse, och specifikationen säger vems 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.¹

Ta den jämförelsen bokstavligt snarare än som en komplimang. Före det protokollet innebar stöd för ett språk i en editor ett plugin per editor; efteråt skeppade ett språkteam en server och varje editor fick det. Måttet på framgång var inte elegans, utan att antalet integrationer slutade multipliceras. Samma sak följer här: värdet ligger i antalet implementationer, inte i designen. Ett protokoll som två produkter talar är ett dataformat med extra ceremoni.

MCP-meddelanden är JSON-RPC 2.0. En request är ett objekt med jsonrpc, ett id, ett method och valfria params; ett response bär samma id och antingen result eller error; en notification är en request utan id och får inget svar. Specifikationen lägger tre begränsningar ovanpå: id måste vara en sträng eller ett tal och får inte vara null, det får inte kollidera med en annan request som fortfarande är in flight, och varje result måste bära ett resultType-fält.²

På stdio-transporten — den som kommandot ovan använde — är framing-regeln en rad per meddelande:

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 sista klausulen är det vanligaste sättet en hemmabyggd server går sönder, och den går sönder tyst: en vilsekommen console.log, en progress bar, en deprecation-varning från ett dependency, och clientens radparser träffar något som inte är JSON. Nödutgången finns i samma avsnitt — servern may skriva vad den vill till stderr, och clienten should not behandla det som ett fel. Referensservern ovan skriver Starting default (STDIO) server... vid varje start, på stderr, vilket är skälet till att pipen ändå fungerade.

Den andra standardtransporten är Streamable HTTP: varje meddelande är en POST till en enda endpoint, och svaret är antingen ett JSON-objekt eller en request-scoped ström av Server-Sent Events — wire-formatet som Kapitel 14 parsade för hand. Semantiken är identisk på båda, eftersom en transport är en binding: den definierar framing och leverans, inte betydelse.⁴

Kommandot ovan skickade tools/list och ingenting annat. Under den aktuella revisionen är den requesten malformed, och en conformant server måste avvisa den.

Sedan 2026-07-28 är MCP ett stateless protocol, och specifikationen säger det utan förbehåll:

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.²

Alltså bär varje request sin egen protokollversion och sina egna client capabilities, i ett reserverat _meta-objekt inuti params. Två av de fälten krävs på varje enskild request; en request som saknar något av dem är malformed och servern måste svara -32602:²

Utskrivet är en korrekt tools/list så här — och det är sista gången det här kapitlet visar metadatan i full form, eftersom den finns på varje request härifrån:

{"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 är förhandlingen. Det finns inte längre något separat förhandlingssteg: clienten deklarerar vad den kan göra på varje request, servern deklarerar vad den kan göra i resultatet, och ingen sida får använda en feature som den andra inte har claim. En server som behöver en capability som clienten inte deklarerade måste svara -32021 och namnge den saknade capability i data.requiredCapabilities. En server som inte talar den begärda versionen måste svara -32022 och lista de versioner den talar.²

Clients som vill ha svaret i förväg kan be om det: server/discover är en obligatorisk RPC som returnerar versioner som stöds, capabilities, identity och ett valfritt block av instructions på en round trip.⁵ Att anropa den är valfritt. Att implementera den är det inte.

Kommandot fungerade. Under den aktuella revisionen borde det inte ha gjort det, och skälet till att det gjorde det förtjänar en mätning snarare än ett stycke, eftersom det är hela ekosystemets tillstånd på en rad.

Proba referensservern på det sätt specifikationen säger åt en modern client att proba:

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 är den tredje grenen i kompatibilitetsregeln: ett DiscoverResult betyder modern, ett erkänt modernt fel betyder modern-men-fel-version, och allt annat — inklusive -32601 — betyder legacy, fall tillbaka till initialize-handskakningen.³ Gör alltså det, och be om den aktuella revisionen:

→ {"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 och servern svarade 2025-11-25. Den 7 september 2026 implementerar den officiella referensservern — npm-paketet @modelcontextprotocol/server-everything, version 2026.8.31, publicerat 31 augusti 2026 — inte den aktuella revisionen. Inte heller, enligt datumen, gör TypeScript-SDK:t den är byggd på: release 1.30.0 gick ut 27 juli 2026, dagen före revisionen.

Läs konsekvensen snarare än skvallret. Nästan allt som skrivits om MCP beskriver ett protokoll med en initialize-handskakning, en session, en roots/list-request som servern skickar till clienten, och en HTTP+SSE-transport. Alla fyra är borta eller på väg bort. När du läser något om MCP, inklusive den här sidan, är det första du ska leta efter ett revisionsnummer.

Och skälet till att det allra första kommandot fungerade anges i specifikationen som en risk, inte 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.³

Uppmätt: att skicka tools/list till den servern utan någon handskakning alls returnerar hela katalogen. En metod som borde ha nekats blev betjänad, vilket är exakt varför specifikationen säger att man ska proba med server/discover först även när man bara stöder moderna versioner.

MCP har tre parter, och skillnaden mellan de två första är den folk brukar slå ihop:

Server. En process eller tjänst som exponerar resurser, tools och prompts. Den kan vara lokal eller remote, den arbetar självständigt, och hela dess uppgift är ett avgränsat område.⁶

Regeln ”exakt en server” är inte bokföring. Det är vad som gör designprincipen nedan implementerbar, och detta är meningen att ta från specifikationen om du bara tar en:

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 mentala modell de flesta kommer in med. En väderserver du kopplar till din assistant ser inte vad du frågade. Den ser ett tools/call med argumenten modellen valde, och inget annat — inte tidigare turns, inte din system prompt, inte resultaten som kalenderservern returnerade för ett ögonblick sedan. Om två servrar behöver samarbeta bär hosten ett värde från den ena till den andra, avsiktligt, eftersom modellen bad den att göra det. Därför är isolation den säkerhetsegenskap Kapitel 30 lutar sig mot: en komprometterad server har en liten, definierad blast radius, och att förstora den kräver att hosten samarbetar.

Det första kommandot bad servern om tools och fick tretton. Ställ de två andra frågorna till den och den svarar på dem också: resources/list returnerar sju, prompts/list returnerar fyra. Inget av dem dök upp, eftersom inget frågade. Vilket leder oss till MCP:s pedagogiska ryggrad, som ligger i specifikationen som en tabell nästan ingen citerar:

Inte ”tre sätt att exponera en capability”. Tre svar på vem bestämmer att detta händer. Modellen bestämmer att den ska anropa ett tool. Applikationen bestämmer att den ska bifoga en resource. Personen bestämmer att den ska köra en prompt. Får du det fel fungerar featuren fortfarande, men den fungerar vid fel ögonblick och av fel skäl.

Det tydligaste sättet att känna det är en kalender. Här är en server som exponerar samma kalender tre gånger, en gång som varje primitive, på hundra rader vanlig Node utan 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 och fråga den på alla tre sätt. Riktig output, ett meddelande per rad på wire, radbrutet här för sidan, med requestens _meta och serverns identity-block utelämnade:

→ 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, en kalender. Nu poängen:

Nästan alla gör alla tre till tools. Resultatet är en katalog där en read som applikationen borde ha bifogat tyst konkurrerar om modellens attention med en write som behöver approval, och där den enda sak en person ville ha en knapp för ligger begravd i ett schema. Det kostar inget att göra rätt, och det avgörs innan du skriver en rad.

Kalenderverktyget har ett obligatoriskt argument, title, och ett valfritt startsAt. Be det skapa ett event utan datum, och något intressant kommer tillbaka:

→ 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=="}

Servern skickade ingen request. Den besvarade den den fick, med resultType: "input_required" och en beskrivning av vad den fortfarande behöver. Clienten samlar in svaret från personen och skickar sedan om det ursprungliga anropet — med ett nytt id, som bär inputResponses och ekar tillbaka det ogenomskinliga requestState:

→ 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}

Detta är Multi Round-Trip Requests, introducerat i den aktuella revisionen, och det ersatte den äldre designen där servrar skickade JSON-RPC-requests tillbaka till clients. Transportspecifikationen anger nu regeln rakt ut: ”servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses”.⁴ Det finns en riktning för initiativ, och den tillhör hosten.

Två client-side features rider på den mekanismen, och en av dem har ett namn som kommer att lura dig.

Elicitation är servern som ber personen om något: ett formulär med ett avsiktligt begränsat JSON Schema — platta objekt, primitive properties, ingen nesting — så att vilken client som helst kan rendera det utan en layout engine. Den bär en hård regel: servrar must not använda form mode för att be om ”passwords, API keys, access tokens, or payment credentials”, och must använda URL mode för sådant, vilket skickar användaren till en sida clienten aldrig läser.⁷

Sampling är servern som ber hostens modell om en generation, så att en server kan vara intelligent utan att hålla en API key. Och här är vokabulärvarningen, eftersom detta ord redan betyder något annat i den här kursen: detta är inte Kapitel 17:s sampling. Inget här handlar om temperature, top-p eller formen på en probability distribution. Det är ett nästat modellanrop som färdas bakåt genom ett protokoll.

Det finns ett andra skäl att inte sträcka sig efter det: från och med denna revision är sampling deprecated, tillsammans med roots och logging, under SEP-2577, med en rättfram föreslagen migration — ”integrate directly with LLM provider APIs instead of Sampling”.⁸ Idén misslyckades inte tekniskt; den misslyckades med att motivera sin surface area, och ett protokoll som kan ta bort saker är friskare än ett som inte kan det.

Statelessness låter som en wire-format-detalj tills du testar det. Ta tre-meddelandeutbytet ovan och kör varje meddelande i en separat process — en färsk node calendar.mjs, inget delat minne, inget som bärs över:

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)

Process B, som aldrig såg frågan, slutförde ett multi-round-trip-anrop som process A startade. Det är poängen med requestState: continuation färdas i meddelandet, så inget beror på att processen är densamma.

Process C är felet. Eventet skapades och finns inte där — eftersom toy-servern håller EVENTS i en array på modulnivå, och en array på modulnivå är connection state. Specifikationens note namnger misstaget exakt:

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 föreskrivna fixen är inte en session. Det är ett explicit handle: ett creation tool returnerar en opaque identifier, och varje senare anrop tar den som ett vanligt argument. Protokollet har inget begrepp om den alls — ”from the wire's perspective a handle is an ordinary string in a tool result and an ordinary argument to subsequent tool calls”.⁹ Vilket sätter modellen i ansvar för att bära den, och sätter servern i ansvar för att validera att den här anroparen får använda den vid varje enskilt anrop, eftersom ett handle är ett namn och inte en permission.

Varje tool en server exponerar är ett schema som går in i din prompt på varje request, och Kapitel 24 mätte vad det gör med ett window. MCP lägger till en andra post som är lätt att missa, så båda är värda att räkna på referensservern ovan.

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

Två observationer. Den första är aritmetik: koppla fem servrar av den här storleken och ungefär åtta tusen token av ditt window är upptagna på varje turn, för alltid, oavsett om modellen använder någon av dem eller inte — vilket är mekanismen bakom minskningen från 150 000 till 2 000 som Kapitel 24 citerade, och skälet till att just-in-time tool discovery finns.

Den andra är en säkerhetsnote i redovisningskostym. instructions är natural-language text, written by the server author, that lands in the host's prompt, och tool-beskrivningarna bredvid den är samma sak. Specifikationen säger vad man ska göra åt det i sina egna säkerhetsprinciper: tool annotations och descriptions ”should be considered untrusted, unless obtained from a trusted server”, och hosts ”must obtain explicit user consent before invoking any tool”.¹ Att ansluta en MCP-server är inte att lägga till ett dependency. Det är att ge en främling 1 619 token av din system prompt och rätten att bli anropad. Kapitel 30 är vad som händer när den främlingen är fientlig.

Allt i det här avsnittet är sant för protokollrevision 2026-07-28, den aktuella, läst den 7 september 2026. Revisioner dateras YYYY-MM-DD och datumet är senaste gången en bakåtinkompatibel ändring gjordes.¹⁰ Det normativa dokumentet är en TypeScript-fil, schema/2026-07-28/schema.ts; JSON Schema bredvid genereras från den, vilket är varför specifikationen här läses i TypeScript och varför att undervisa MCP från något annat är att undervisa en översättning.

Governance-ändringen under den tabellen spelar större roll än någon enskild rad. Denna revision antog en feature lifecycle and deprecation policy: features är Active, Deprecated eller Removed, en deprecated feature dokumenterar sin migrationsväg och stannar i specifikationen i minst tolv månader innan den blir eligible for removal, och det finns ett registry som listar allt som för närvarande är i Deprecated state.⁸ Före den policyn betydde ”deprecated” i ett AI-protokoll vad det senaste blogginlägget än sa. Nu betyder det ett datum.

Det här är vokabulären för hela blocket på ett ställe.

Två av dem förtjänar varsin mening, eftersom det är där förvirringen faktiskt bor.

MCP mot A2A är ingen rivalitet, och båda specifikationerna säger det. A2A-dokumentationen drar gränsen efter vad som finns i andra änden: MCP ”defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API”, där ett tool utför ”specific, often stateless, functions”; A2A adresserar agents, ”more autonomous systems” som ”reason, plan, use multiple tools, maintain state over longer interactions, and engage in complex, often multi-turn dialogues”. Dess egen sammanfattning är meningen att minnas: ”A2A is about agents partnering on tasks, while MCP is more about agents using capabilities.”¹¹ De två nestar — en applikation använder A2A för att nå andra agents, och varje agent använder MCP för att nå sina egna tools. Kapitel 25 drog den gränsen inuti en process, mellan att fråga en sub-agent och lämna över konversationen till den; A2A drar den mellan organisationer.

MCP mot ACP är en jämförelse med en stale premise, vilket är exakt varför den är värd att besvara. Agent Communication Protocol var en separat öppen standard för agent-to-agent-meddelanden. Dess egen dokumentation öppnar nu med notisen: ”ACP is now part of A2A under the Linux Foundation!”¹² Det ärliga svaret på ”MCP eller ACP?” i september 2026 är att frågan har ett alternativ mindre än sidorna som rankar för den antyder.

Och jämförelsen folk oftast ber om, mcp vs api, har det minst intressanta svaret: MCP är ett API. Det den lägger till är inte kraft, utan conventions — en fast uppsättning metodnamn, ett discovery call, en control hierarchy över primitiverna och en isolation model. Du ger upp friheten att designa ditt eget interface och får varje host som talar protokollet, vilket är det trade varje protokoll alltid har erbjudit.

Du kan nu läsa specifikationen utan en översättare, skilja en resource från ett tool från en prompt efter vem som bestämmer över den, skriva en request för hand när ett client-bibliotek ljuger för dig, och datera varje MCP-artikel du läser efter vilka av de deprecated features den fortfarande lär ut som aktuella.

Vad du inte har gjort är att skeppa en. Kapitel 27 skriver samma server två gånger — TypeScript och Python, sida vid sida, eftersom MCP är det enda genuint tvåspråkiga territoriet i den här kursen och siffrorna säger det åt båda hållen. Det täcker de två live-transporterna ordentligt, inspectorn, packaging, och den halva av protokollet som detta kapitel avsiktligt lämnade ifred: authorization. För i samma ögonblick som din server är remote snarare än en subprocess på din egen laptop kommer en främlings client att presentera en token, och specifikationens regel om vad du får göra med den är ovanligt strikt.

Vilket väcker frågan som nästa kapitel måste besvara, och den är inte vänlig: om en token anländer till din server och den utfärdades för någon annans audience, vad exakt hindrar dig från att vidarebefordra den?

Varje citat, metodnamn, error code och regel i detta kapitel lästes från Model Context Protocol-specifikationen, revision 2026-07-28, den 7 september 2026. Varje trace producerades lokalt på Node 22: toy-kalenderservern är 101 rader utan dependencies, och referensservern är det publicerade npm-paketet som namnges nedan. Inget betalt API anropades för att skriva detta kapitel — inget här behöver en modell, vilket i sig är poängen.

Mätningarna: @modelcontextprotocol/server-everything@2026.8.31, publicerat 31 augusti 2026, byggt på @modelcontextprotocol/sdk@1.30.0, publicerat 27 juli 2026 — en dag före revisionen detta kapitel beskriver. Det svarar server/discover med -32601, förhandlar 2025-11-25 när det ombeds om 2026-07-28, och serverar tools/list utan någon handskakning alls. Dess katalog är 13 tools i 7 663 byte; token-antal är o200k_base via tiktoken, över name, description och inputSchema i varje definition, vilket är vad en provider renderar in i din prompt och inte vad JSON-RPC-framen väger.

Anthropic, Code execution with MCP: building more efficient agents, 4 november 2025, är källan till siffran 150 000-till-2 000, citerad och använd i Kapitel 24 och bara refererad här.