MCP anhand der Spec erklärt: Was ein Server wirklich ist

Vor dem Wire kommt die Arithmetik. Du hast $N$ AI-Anwendungen und $M$ Dinge, die sie erreichen können sollen — einen Kalender, einen Ticket-Tracker, eine Warehouse-Datenbank, ein Design-Tool. Ohne gemeinsamen Vertrag schreibt jemand $N \times M$ Integrationen, und jede einzelne ist ein Schema plus ein Endpoint plus eine Authentifizierungsstory plus Wartungsaufwand. Mit einem schreibt der Tool-Anbieter einen Server, der Anwendungsanbieter einen Client, und die Summe ist $N + M$.

Das ist keine neue Beobachtung, und die Spezifikation sagt, wessen Idee es war:

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

Nimm diesen Vergleich wörtlich, nicht als Kompliment. Vor diesem Protokoll bedeutete die Unterstützung einer Sprache in einem Editor ein Plugin pro Editor; danach lieferte ein Sprachteam einen Server aus und jeder Editor bekam sie. Das Maß für Erfolg war nicht Eleganz, sondern dass die Anzahl der Integrationen aufhörte, sich zu multiplizieren. Dasselbe folgt hier: Der Wert liegt in der Anzahl der Implementierungen, nicht im Design. Ein Protokoll, das zwei Produkte sprechen, ist ein Datenformat mit zusätzlicher Zeremonie.

MCP-Nachrichten sind JSON-RPC 2.0. Eine Request ist ein Objekt mit jsonrpc, einer id, einer method und optionalen params; eine Response trägt dieselbe id und entweder result oder error; eine Notification ist eine Request ohne id und erhält keine Antwort. Die Spezifikation legt drei zusätzliche Constraints darüber: Die id muss ein String oder eine Zahl sein und darf nicht null sein, sie darf nicht mit einer anderen noch laufenden Request kollidieren, und jedes Result muss ein resultType-Feld tragen.²

Beim stdio-Transport — dem, den der obige Befehl verwendet hat — lautet die Framing-Regel: eine Zeile pro Nachricht:

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

Diese letzte Klausel ist die häufigste Art, wie ein selbstgebauter Server kaputtgeht, und er geht still kaputt: ein verirrtes console.log, ein Fortschrittsbalken, eine Deprecation-Warnung einer Dependency, und der Line-Parser des Clients trifft auf etwas, das kein JSON ist. Der Notausgang steht im selben Abschnitt — der Server darf alles, was er möchte, nach stderr schreiben, und der Client sollte das nicht als Fehler behandeln. Der Referenzserver oben druckt bei jedem Start Starting default (STDIO) server... auf stderr, weshalb die Pipe trotzdem funktionierte.

Der andere Standardtransport ist Streamable HTTP: Jede Nachricht ist ein POST an einen einzelnen Endpoint, und die Antwort ist entweder ein JSON-Objekt oder ein Request-scoped Stream von Server-Sent Events — das Wire-Format, das Kapitel 14 von Hand geparst hat. Die Semantik ist bei beiden identisch, weil ein Transport ein Binding ist: Er definiert Framing und Zustellung, nicht Bedeutung.⁴

Der obige Befehl sendete tools/list und sonst nichts. Unter der aktuellen Revision ist diese Request malformed, und ein konformer Server muss sie ablehnen.

Seit 2026-07-28 ist MCP ein zustandsloses Protokoll, und die Spezifikation sagt das ohne Einschränkung:

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

Also trägt jede Request ihre eigene Protokollversion und ihre eigenen Client-Capabilities in einem reservierten _meta-Objekt innerhalb von params. Zwei dieser Felder sind bei jeder einzelnen Request erforderlich; fehlt eines davon, ist die Request malformed und der Server muss mit -32602 antworten:²

Ausgeschrieben sieht ein korrektes tools/list so aus — und es ist das letzte Mal, dass dieses Kapitel die Metadaten vollständig zeigt, weil sie ab hier auf jeder Request stehen:

{"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"}}}}

Das Capability-Objekt ist die Negotiation. Es gibt keinen separaten Negotiation-Schritt mehr: Der Client erklärt bei jeder Request, was er kann, der Server erklärt im Result, was er kann, und keine Seite darf ein Feature verwenden, das die andere nicht beansprucht hat. Ein Server, der eine Capability braucht, die der Client nicht deklariert hat, muss mit -32021 antworten und die fehlende Capability in data.requiredCapabilities benennen. Ein Server, der die angeforderte Version nicht spricht, muss mit -32022 antworten und die Versionen auflisten, die er spricht.²

Clients, die die Antwort vorab möchten, können danach fragen: server/discover ist ein verpflichtender RPC, der unterstützte Versionen, Capabilities, Identität und einen optionalen Block von instructions in einem Roundtrip zurückgibt.⁵ Ihn aufzurufen ist optional. Ihn zu implementieren nicht.

Der Befehl funktionierte. Unter der aktuellen Revision hätte er das nicht tun sollen, und der Grund dafür ist eher eine Messung wert als einen Absatz, denn er ist der Zustand des gesamten Ökosystems in einer Zeile.

Probe den Referenzserver so, wie die Spezifikation es einem modernen Client vorschreibt:

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

Das ist der dritte Zweig der Kompatibilitätsregel: Ein DiscoverResult bedeutet modern, ein erkannter moderner Fehler bedeutet modern-aber-falsche-Version, und alles andere — einschließlich -32601 — bedeutet legacy, falle auf den initialize-Handshake zurück.³ Also tue das, mit der aktuellen 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":"…"}}

Der Client fragte nach 2026-07-28 und der Server antwortete 2025-11-25. Am 7. September 2026 implementiert der offizielle Referenzserver — npm-Package @modelcontextprotocol/server-everything, Version 2026.8.31, veröffentlicht am 31. August 2026 — die aktuelle Revision nicht. Ebenso wenig, den Daten nach, das TypeScript SDK, auf dem er basiert: Release 1.30.0 erschien am 27. Juli 2026, einen Tag vor der Revision.

Lies die Konsequenz, nicht den Klatsch. Fast alles, was über MCP geschrieben wurde, beschreibt ein Protokoll mit einem initialize-Handshake, einer Session, einer roots/list-Request, die der Server an den Client sendet, und einem HTTP+SSE-Transport. Alle vier sind weg oder gehen gerade weg. Wenn du etwas über MCP liest, einschließlich dieser Seite, ist das Erste, wonach du suchen solltest, eine Revisionsnummer.

Und der Grund, weshalb der allererste Befehl funktionierte, steht in der Spezifikation als Gefahr, nicht als 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.³

Gemessen: tools/list ohne jeden Handshake an diesen Server zu senden, liefert den vollständigen Katalog zurück. Eine Methode, die hätte abgelehnt werden sollen, wurde bedient, und genau deshalb sagt die Spezifikation, zuerst mit server/discover zu proben, selbst wenn du nur moderne Versionen unterstützt.

MCP hat drei Parteien, und die Unterscheidung zwischen den ersten beiden ist die, die Leute zusammenfallen lassen:

Server. Ein Prozess oder Service, der Ressourcen, Tools und prompts exposes. Er kann lokal oder remote sein, arbeitet unabhängig, und seine ganze Aufgabe ist ein fokussierter Bereich.⁶

Diese „genau ein Server“-Regel ist keine Buchhaltung. Sie macht das folgende Designprinzip implementierbar, und dies ist der Satz, den du aus der Spezifikation mitnehmen solltest, wenn du nur einen mitnimmst:

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

Das kippt das mentale Modell, mit dem die meisten Menschen ankommen. Ein Wetterserver, den du mit deinem Assistant verbindest, sieht nicht, was du gefragt hast. Er sieht einen tools/call mit den Argumenten, die das Modell gewählt hat, und nichts anderes — nicht die vorherigen Turns, nicht deinen system prompt, nicht die Ergebnisse, die der Kalenderserver einen Moment zuvor zurückgegeben hat. Wenn zwei Server zusammenarbeiten müssen, trägt der Host einen Wert absichtlich von einem zum anderen, weil das Modell ihn darum gebeten hat. Deshalb ist Isolation die Sicherheitseigenschaft, auf der Kapitel 30 aufbaut: Ein kompromittierter Server hat einen kleinen, definierten Blast Radius, und ihn zu vergrößern erfordert die Kooperation des Hosts.

Der erste Befehl fragte diesen Server nach Tools und bekam dreizehn. Stell ihm die anderen zwei Fragen, und er beantwortet sie ebenfalls: resources/list gibt sieben zurück, prompts/list gibt vier zurück. Keines davon erschien, weil nichts danach fragte. Damit kommen wir zum pädagogischen Rückgrat von MCP, das in der Spezifikation als Tabelle steht und das fast niemand zitiert:

Nicht „drei Wege, eine Capability offenzulegen“. Drei Antworten auf wer entscheidet, dass dies passiert. Das Modell entscheidet, ein Tool aufzurufen. Die Anwendung entscheidet, eine Ressource anzuhängen. Die Person entscheidet, einen prompt auszuführen. Verstehst du das falsch, funktioniert das Feature trotzdem, aber es funktioniert im falschen Moment und aus dem falschen Grund.

Am klarsten spürst du es an einem Kalender. Hier ist ein Server, der denselben Kalender dreimal exposed, einmal als jedes Primitive, in hundert Zeilen schlichtem Node ohne 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" });
}

Führe ihn aus und frage ihn auf alle drei Arten. Echte Ausgabe, eine Nachricht pro Zeile auf dem Wire, hier für die Seite umbrochen, mit der Request _meta und dem Identitätsblock des Servers ausgelassen:

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

Drei Methoden, drei Formen, ein Kalender. Jetzt der Punkt:

Fast alle machen aus allen dreien Tools. Das Ergebnis ist ein Katalog, in dem ein Read, den die Anwendung still hätte anhängen sollen, um die Aufmerksamkeit des Modells mit einem Write konkurriert, der Approval braucht, und in dem das eine Ding, für das eine Person einen Button wollte, in einem Schema begraben liegt. Es kostet nichts, es richtig zu machen, und es wird entschieden, bevor du eine Zeile schreibst.

Das Kalender-Tool hat ein erforderliches Argument, title, und ein optionales startsAt. Bitte es, ein Event ohne Datum zu erstellen, und etwas Interessantes kommt zurück:

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

Der Server hat keine Request gesendet. Er hat diejenige beantwortet, die ihm gegeben wurde, mit resultType: "input_required" und einer Beschreibung dessen, was er noch braucht. Der Client sammelt die Antwort von der Person und sendet dann den ursprünglichen Call erneut — mit einer neuen id, die inputResponses trägt und das opaque requestState zurückspiegelt:

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

Das sind Multi Round-Trip Requests, eingeführt in der aktuellen Revision, und sie ersetzten das ältere Design, bei dem Server JSON-RPC-Requests zurück an Clients sendeten. Die Transport-Spezifikation sagt die Regel jetzt glatt heraus: „servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses“.⁴ Es gibt eine Richtung der Initiative, und sie gehört dem Host.

Zwei clientseitige Features reiten auf diesem Mechanismus, und eines davon hat einen Namen, über den du stolpern wirst.

Elicitation ist der Server, der die Person nach etwas fragt: ein Formular mit einem bewusst eingeschränkten JSON Schema — flache Objekte, primitive Properties, keine Verschachtelung — damit jeder Client es ohne Layout-Engine rendern kann. Es trägt eine harte Regel: Server dürfen den Formularmodus nicht verwenden, um nach „passwords, API keys, access tokens, or payment credentials“ zu fragen, und müssen dafür den URL-Modus verwenden, der den Nutzer auf eine Seite schickt, die der Client nie liest.⁷

Sampling ist der Server, der das Modell des Hosts um eine Generierung bittet, damit ein Server intelligent sein kann, ohne einen API key zu halten. Und hier ist die Vokabelwarnung, weil dieses Wort in diesem Kurs bereits etwas anderes bedeutet: Das ist nicht das Sampling aus Kapitel 17. Hier geht es nicht um Temperature, top-p oder die Form einer Wahrscheinlichkeitsverteilung. Es ist ein verschachtelter Modell-Call, der rückwärts durch ein Protokoll reist.

Es gibt einen zweiten Grund, nicht danach zu greifen: Ab dieser Revision ist sampling deprecated, zusammen mit Roots und Logging, unter SEP-2577, mit einer stumpfen vorgeschlagenen Migration — „integrate directly with LLM provider APIs instead of Sampling“.⁸ Die Idee ist nicht technisch gescheitert; sie hat ihre Surface Area nicht gerechtfertigt, und ein Protokoll, das Dinge entfernen kann, ist gesünder als eines, das es nicht kann.

Zustandslosigkeit klingt wie ein Wire-Format-Detail, bis du sie testest. Nimm den Drei-Nachrichten-Austausch oben und führe jede Nachricht in einem separaten Prozess aus — ein frisches node calendar.mjs, kein gemeinsamer Speicher, nichts wird mitgetragen:

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)

Prozess B, der die Frage nie gesehen hat, schloss einen Multi-Round-Trip-Call ab, den Prozess A begonnen hatte. Das ist der Sinn von requestState: Die Continuation reist in der Nachricht, also hängt nichts davon ab, dass es derselbe Prozess ist.

Prozess C ist der Fehler. Das Event wurde erstellt und ist nicht da — weil der Toy-Server EVENTS in einem Array auf Modulebene hält, und ein Array auf Modulebene Connection State ist. Die Note der Spezifikation benennt den Fehler präzise:

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

Der vorgeschriebene Fix ist keine Session. Es ist ein explizites Handle: Ein Creation-Tool gibt einen opaque Identifier zurück, und jeder spätere Call nimmt ihn als gewöhnliches Argument. Das Protokoll hat davon überhaupt keinen Begriff — „from the wire's perspective a handle is an ordinary string in a tool result and an ordinary argument to subsequent tool calls“.⁹ Damit ist das Modell dafür zuständig, ihn zu tragen, und der Server dafür, bei jedem einzelnen Call zu validieren, dass dieser Caller ihn verwenden darf, denn ein Handle ist ein Name und keine Berechtigung.

Jedes Tool, das ein Server exposed, ist ein Schema, das bei jeder Request in deinen prompt geht, und Kapitel 24 hat gemessen, was das mit einer Window macht. MCP fügt einen zweiten Posten hinzu, der leicht zu übersehen ist, also lohnt es sich, beide beim Referenzserver oben zu zählen.

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

Zwei Beobachtungen. Die erste ist Arithmetik: Verbinde fünf Server dieser Größe, und ungefähr achttausend token deiner Window sind bei jedem Turn für immer belegt, egal ob das Modell irgendeinen davon nutzt — das ist der Mechanismus hinter der Reduktion von 150.000 auf 2.000, die Kapitel 24 zitierte, und der Grund, warum Just-in-time-Tool-Discovery existiert.

Die zweite ist eine Sicherheitsnotiz im Kostüm der Buchhaltung. instructions ist Natural-Language-Text, geschrieben vom Server-Autor, der im prompt des Hosts landet, und die Tool-Beschreibungen daneben sind dasselbe. Die Spezifikation sagt in ihren eigenen Sicherheitsprinzipien, was damit zu tun ist: Tool-Annotations und -Beschreibungen „should be considered untrusted, unless obtained from a trusted server“, und Hosts „must obtain explicit user consent before invoking any tool“.¹ Einen MCP Server zu verbinden, ist nicht das Hinzufügen einer Dependency. Es bedeutet, einem Fremden 1.619 token deines system prompt und das Recht, aufgerufen zu werden, zu gewähren. Kapitel 30 zeigt, was passiert, wenn dieser Fremde feindlich ist.

Alles in diesem Abschnitt gilt für Protokollrevision 2026-07-28, die aktuelle, gelesen am 7. September 2026. Revisionen sind als YYYY-MM-DD datiert, und das Datum ist der letzte Zeitpunkt, zu dem eine rückwärtsinkompatible Änderung vorgenommen wurde.¹⁰ Das normative Dokument ist eine TypeScript-Datei, schema/2026-07-28/schema.ts; das JSON Schema daneben wird daraus generiert, weshalb die Spezifikation hier in TypeScript gelesen wird und weshalb MCP aus irgendetwas anderem zu lehren heißt, eine Übersetzung zu lehren.

Die Governance-Änderung unter dieser Tabelle ist wichtiger als jede einzelne Zeile. Diese Revision führte eine Feature-Lifecycle- und Deprecation-Policy ein: Features sind Active, Deprecated oder Removed, ein deprecated Feature dokumentiert seinen Migrationspfad und bleibt mindestens zwölf Monate in der Spezifikation, bevor es für Removal infrage kommt, und es gibt eine Registry, die alles auflistet, was aktuell im Deprecated-Zustand ist.⁸ Vor dieser Policy bedeutete „deprecated“ in einem AI-Protokoll, was auch immer der letzte Blogpost sagte. Jetzt bedeutet es ein Datum.

Das ist das Vokabular des ganzen Blocks an einer Stelle.

Zwei davon verdienen je einen Satz, weil dort die Verwirrung tatsächlich lebt.

MCP gegenüber A2A ist keine Rivalität, und beide Spezifikationen sagen das. Die A2A-Dokumentation zieht die Linie danach, was am anderen Ende ist: MCP „defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API“, wobei ein Tool „specific, often stateless, functions“ ausführt; A2A adressiert agents, „more autonomous systems“, die „reason, plan, use multiple tools, maintain state over longer interactions, and engage in complex, often multi-turn dialogues“. Die eigene Zusammenfassung ist der Satz, den man sich merken sollte: „A2A is about agents partnering on tasks, while MCP is more about agents using capabilities.“¹¹ Die beiden verschachteln sich — eine Anwendung nutzt A2A, um andere agents zu erreichen, und jeder agent nutzt MCP, um seine eigenen Tools zu erreichen. Kapitel 25 zog diese Linie innerhalb eines Prozesses, zwischen dem Fragen eines sub-agent und dem Übergeben der Konversation; A2A zieht sie zwischen Organisationen.

MCP gegenüber ACP ist ein Vergleich mit einer veralteten Prämisse, und genau deshalb lohnt es sich, ihn zu beantworten. Das Agent Communication Protocol war ein separater offener Standard für agent-to-agent Messaging. Seine eigene Dokumentation beginnt inzwischen mit dem Hinweis: „ACP is now part of A2A under the Linux Foundation!“¹² Die ehrliche Antwort auf „MCP oder ACP?“ im September 2026 ist, dass die Frage eine Option weniger hat, als die Seiten, die dafür ranken, suggerieren.

Und der Vergleich, nach dem die meisten fragen, mcp vs api, hat die am wenigsten interessante Antwort: MCP ist eine API. Was es hinzufügt, ist nicht Power, sondern Konventionen — eine feste Menge von Methodennamen, ein Discovery-Call, eine Kontrollhierarchie über die Primitive und ein Isolationsmodell. Du gibst die Freiheit auf, dein eigenes Interface zu designen, und bekommst jeden Host, der das Protokoll spricht, was der Trade ist, den jedes Protokoll je angeboten hat.

Du kannst die Spezifikation jetzt ohne Übersetzer lesen, eine Ressource von einem Tool von einem prompt danach unterscheiden, wer darüber entscheidet, eine Request von Hand tippen, wenn eine Client-Bibliothek dich belügt, und jeden MCP-Artikel, den du liest, danach datieren, welche deprecated Features er noch als aktuell lehrt.

Was du noch nicht getan hast, ist, einen auszuliefern. Kapitel 27 schreibt denselben Server zweimal — TypeScript und Python, nebeneinander, weil MCP das eine wirklich zweisprachige Gebiet in diesem Kurs ist und die Zahlen das in beide Richtungen sagen. Es behandelt die beiden Live-Transporte richtig, den Inspector, Packaging und die Hälfte des Protokolls, die dieses Kapitel absichtlich ausgelassen hat: Authorization. Denn sobald dein Server remote ist und kein Subprozess auf deinem eigenen Laptop, wird der Client eines Fremden einen token präsentieren, und die Regel der Spezifikation dazu, was du damit tun darfst, ist ungewöhnlich strikt.

Das wirft die Frage auf, die das nächste Kapitel beantworten muss, und sie ist keine freundliche: Wenn ein token bei deinem Server ankommt und für die Audience von jemand anderem ausgestellt wurde, was genau hält dich davon ab, ihn weiterzuleiten?

Jedes Zitat, jeder Methodenname, jeder Error Code und jede Regel in diesem Kapitel wurde aus der Model Context Protocol Specification, Revision 2026-07-28, am 7. September 2026 gelesen. Jeder Trace wurde lokal auf Node 22 erzeugt: Der Toy-Kalenderserver hat 101 Zeilen ohne Dependencies, und der Referenzserver ist das unten genannte veröffentlichte npm-Package. Keine bezahlte API wurde aufgerufen, um dieses Kapitel zu schreiben — nichts hier braucht ein Modell, was selbst der Punkt ist.

Die Messungen: @modelcontextprotocol/server-everything@2026.8.31, veröffentlicht am 31. August 2026, gebaut auf @modelcontextprotocol/sdk@1.30.0, veröffentlicht am 27. Juli 2026 — einen Tag vor der Revision, die dieses Kapitel beschreibt. Es beantwortet server/discover mit -32601, negotiates 2025-11-25, wenn nach 2026-07-28 gefragt wird, und bedient tools/list ganz ohne Handshake. Sein Katalog umfasst 13 Tools in 7.663 Bytes; token Counts sind o200k_base via tiktoken, über name, description und inputSchema jeder Definition, also das, was ein Provider in deinen prompt rendert, nicht das Gewicht des JSON-RPC-Frames.

Anthropic, Code execution with MCP: building more efficient agents, 4. November 2025, ist die Quelle der 150.000-auf-2.000-Zahl, die in Kapitel 24 zitiert und verwendet wird und hier nur referenziert wird.