MCP

Kapitel 01 beschreibt, was ein Agent tut. Damit er es tun kann, muss er an etwas herankommen: an eine Datenbank, an Dateien, an eine Suchfunktion. Dieses Kapitel handelt vom Stecker dafür.

Das Problem, für das es gebaut wurde

Tools gab es vorher. ChatGPT bekam im März 2023 Erweiterungen, drei Monate später lieferte OpenAI Modelle aus, die einen Tool Call von sich aus formulieren konnten, und Grundkurs, Kapitel 09 nimmt die Mechanik dahinter auseinander. Was fehlte, war eine gemeinsame Form dafür. Jede dieser Anbindungen gehörte einem Anbieter, und wer eine Wetterauskunft, ein Ticketsystem und eine Dateiablage anschließen wollte, schrieb sie für jedes Programm neu. Der Nachbar, der dieselben drei brauchte, schrieb sie noch einmal. Anthropic beschrieb das bei der Vorstellung so:

Every new data source requires its own custom implementation, making truly connected systems difficult to scale. (externe Seite, anthropic.com)

Der Vorschlag dagegen ist eine gemeinsame Sprache:

It provides a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol. (externe Seite, anthropic.com)

Der Vergleich, der sich anbietet, ist der Stecker. Ein Gerät mit USB-Anschluss passt an jeden Rechner mit USB-Anschluss, und niemand baut das Kabel selbst. MCP will dasselbe für Tools sein: einmal bereitgestellt, danach von jedem Programm nutzbar, das den Standard spricht.

seitlich verschiebbar

eigene Darstellung, Stand 04.08.2026

Drei Rollen

Der Standard benennt drei Beteiligte, und die Begriffe begegnen einem in jeder Anleitung:

Host. Die Anwendung, die das Modell benutzt, also der Chat, der Editor, der Agent. Die Spezifikation nennt sie LLM applications that initiate connections (externe Seite, modelcontextprotocol.io). Bei ihm laufen die Fäden zusammen. Er entscheidet, was von einem Server beim Modell ankommt.

Client. Der Verbinder im Host. Einer je Server, und er spricht mit genau diesem einen:

A host application creates and manages multiple clients, with each client having a 1:1 relationship with a particular server. (externe Seite, modelcontextprotocol.io)

Server. Die Gegenstelle, die etwas anbietet. Laut Spezifikation Services that provide context and capabilities (externe Seite, modelcontextprotocol.io).

Ein Detail an dieser Aufstellung zählt später: Zwischen dem Server und dem Modell steht immer der Host. Was ein Server liefert, geht durch ihn hindurch, und was er damit macht, ist seine Entscheidung.

Ein Server kann bei Ihnen auf dem Rechner laufen oder irgendwo im Netz. Für das Protokoll macht das keinen Unterschied, für die Sicherheit einen großen, und darum geht es in Tiefe 3.

Was ein Server anbieten kann

Drei Arten von Dingen, und der Unterschied zwischen ihnen ist wichtiger, als er zunächst wirkt:

Art	Was es ist	Für wen
Tools	Functions for the AI model to execute (externe Seite, modelcontextprotocol.io)	das Modell
Ressourcen	Context and data, for the user or the AI model to use (externe Seite, modelcontextprotocol.io)	beide
Vorlagen	Fertige Textbausteine und Abläufe	die Person davor

Die meisten Server bieten vor allem Tools an, und in der Praxis meint „einen MCP-Server einbinden“ fast immer: dem Modell kommen ein paar Tools dazu.

Woran Sie merken, dass einer läuft

In den Programmen, die MCP unterstützen, taucht nach dem Einbinden eine Liste auf: die Namen der Tools, die dieser Server mitbringt. Manchmal steht daneben ein Schalter je Tool.

Diese Liste ist der Ort, an dem Sie die Kontrolle haben, und sie ist es aus zwei Gründen. Der eine ist die Rechnung: Was darin steht, geht im Normalfall bei jeder Anfrage mit ins Fenster, auch wenn niemand es benutzt. Tiefe 2 zeigt, was das kostet und womit ein Programm es umgehen kann. Der andere Grund ist der Text selbst, und den nimmt Tiefe 3 auseinander.

Was sich dadurch nicht ändert

Ein verbreitetes Missverständnis ist, dass MCP dem Modell neue Fähigkeiten gibt. Es gibt ihm neue Anschlüsse. Die Mechanik dahinter bleibt die Tool-Schleife aus Grundkurs, Kapitel 09: Das Modell nennt einen Aufruf, ein Programm führt ihn aus, das Ergebnis kommt zurück.

Was MCP spart, ist die Arbeit auf der Seite dessen, der das Tool bereitstellt. Was es nicht spart, ist die Sorgfalt bei der Frage, welchem Server Sie das erlauben.

Unter der Oberfläche ist MCP unspektakulär: Nachrichten im JSON-RPC-Format zwischen zwei Programmen. Interessant sind die Entscheidungen darum herum.

Wie eine Verbindung zustande kommt

Der Host startet einen Client je Server. Läuft der Server auf demselben Rechner, wird er als Programm gestartet und über die Standardein- und -ausgabe angesprochen. Liegt er im Netz, geht es über HTTP.

Der Client fragt ab, was der Server anbietet, und bekommt eine Liste zurück: Tool-Namen, Beschreibungen, Schemas für die Angaben. Ressourcen und Vorlagen laufen über eigene Listen derselben Bauart. Wie sie über die Leitung gehen, regelt der Transport. Was in ihnen stehen darf, regelt das Protokoll.

Zustandslos seit Juli 2026

Bis zur Fassung vom 25.11.2025 hielten Client und Server eine Sitzung. Es gab einen Handschlag am Anfang, ausgehandelte Fähigkeiten und eine Sitzungskennung, die bei jeder Folgeanfrage mitging.

Die Fassung vom 28.07.2026 hat das abgeschafft. Anfragen stehen jetzt für sich, und was ein Server über mehrere Aufrufe hinweg behalten muss, gibt er als gewöhnliches Argument zurück:

Servers that need cross-call state use explicit, server-minted handles passed as ordinary tool arguments (externe Seite, modelcontextprotocol.io)

Was das im Einzelnen bedeutet, mit Transportbeispielen und der Verträglichkeitsmatrix zwischen alten und neuen Fassungen, steht ausführlich im Beitrag MCP ohne Sitzung. Für dieses Kapitel genügt die Folge: Ein Lastverteiler kann jede Anfrage woanders hinschicken, und ein Server darf zwischen zwei Aufrufen neu starten, ohne dass ihm dabei etwas abhandenkommt, das er sich hätte merken müssen.

Zustandslos geworden ist dabei der Protokollkern. Ein laufender Aufruf bleibt davon unberührt, und dieselbe Änderungsliste hält das in einem Satz fest:

A broken response stream loses the in-flight request (externe Seite, modelcontextprotocol.io)

Ein Neustart kostet also, was gerade unterwegs war. Und die Handles helfen genau so weit, wie der Zustand dahinter für jede Instanz erreichbar bleibt.

Was mitgeht, und wer darüber entscheidet

Hier lohnt sich der Blick auf die Rechnung. Im Normalfall stehen die Tools eines eingebundenen Servers mit Namen, Beschreibung und Schema in jeder Anfrage an das Modell, unabhängig davon, ob eines davon benutzt wird. Wie sich das im Kontextfenster summiert, steht in Grundkurs, Kapitel 09.

Praktisch heißt das: Fünf eingebundene Server mit je acht Tools sind vierzig Beschreibungen, die Sie bei jeder Frage bezahlen, auch bei „Wie spät ist es“. Anthropic hat für genau diesen Zuschnitt eine Zahl gemessen:

A typical multiserver setup (GitHub, Slack, Sentry, Grafana, and Splunk) can consume ~55k tokens in definitions before Claude does any work. (externe Seite, platform.claude.com)

seitlich verschiebbar

eigene Darstellung, Stand 07.08.2026

Verlangt ist das nirgends. MCP regelt, wie ein Client die Liste beim Server abholt. Was davon beim Modell ankommt, ist die Sache des Hosts, und der hat mehr als eine Möglichkeit. Anthropic bietet dafür ein Tool an, dessen einzige Aufgabe das Finden anderer Tools ist:

Instead of loading all tool definitions into the context window up front, Claude searches your tool catalog (including tool names, descriptions, argument names, and argument descriptions) and loads only the tools it needs. (externe Seite, platform.claude.com)

Der Preis steht daneben. Die Suche kostet einen eigenen Zug, mindestens ein Tool muss ungestundet bleiben, und was sie hereinholt, zählt danach wie jede andere Eingabe. Für kleine Aufbauten rät dieselbe Seite deshalb ab:

Standard tool calling, without tool search, is a better fit when you have fewer than 10 tools, every tool is used in every request, or your tool definitions are small (externe Seite, platform.claude.com)

Die Rechnung oben gilt also, solange niemand etwas dagegen tut. Ob jemand etwas dagegen tut, entscheidet Ihr Programm. Der Standard sagt dazu nichts.

Deshalb gibt es in den Programmen Schalter je Server und je Tool. Sie sind die Kostenkontrolle von Hand, und sie sind zugleich Rechtekontrolle: Ein abgeschaltetes Tool kostet nichts und lässt sich auch nicht aufrufen.

Im gesprochenen Dialog läuft daneben eine zweite Rechnung in einer zweiten Währung: Der Aufruf hält das Gespräch an, solange er dauert. Was das ändert, steht in Conversational AI, Kapitel 06.

Wonach ein Tool ausgewählt wird

Ein Punkt, der bei eigener Anbindung selten auffällt und bei fremden Servern zum Problem wird. Die Doku nennt zwei Größen:

Claude determines when to call a tool based on the user’s request and the tool’s description. (externe Seite, platform.claude.com)

Die eine ist Ihre Anfrage, die andere die Beschreibung, die der Server mitliefert. Bei einem selbst gebauten Tool haben Sie beide geschrieben. Bei einem fremden Server stammt die zweite von jemand anderem, und sie wirkt trotzdem in Ihrem Fenster. Das ist die Grundlage für alles, was in Tiefe 3 steht.

Server bei Ihnen und Server im Netz

Der Unterschied ist keine Frage der Bequemlichkeit.

	lokal gestartet	über HTTP
Wo er läuft	auf Ihrem Rechner	dort, wo der Betreiber ihn hinstellt
Was er sieht	so viel, wie die Umgebung ihm lässt	was Sie ihm schicken, dazu Ihre Anmeldung
Wer ihn aktualisiert	Sie, sofern die Fassung festgeschrieben ist	der Betreiber, jederzeit
Rechte	ohne eigene Grenze dieselben wie Ihr Programm	die des Servers

Der lokale Server ist bequem, und was er darf, hängt an der Umgebung, in der er startet. Wie eng die zu ziehen ist und was der Standard dazu sagt, steht in Tiefe 3. Der entfernte sieht nur, was durch die Leitung geht, und ändert sich ohne Ihr Zutun.

Was das Protokoll ausdrücklich offen lässt

Die Spezifikation hat einen Abschnitt zu Sicherheit, und darin einen Satz, der den Rahmen absteckt:

While MCP itself cannot enforce these security principles at the protocol level (externe Seite, modelcontextprotocol.io)

Das Protokoll formuliert also Grundsätze und überlässt die Durchsetzung dem Programm, das es benutzt. Wer einen MCP-Server einbindet, verlässt sich damit auf zwei Dinge: auf den Server und auf die Sorgfalt seines eigenen Programms. Was daraus folgt, steht in Tiefe 3.

Einen MCP-Server einzubinden dauert eine Minute und sieht aus wie das Installieren einer Erweiterung. Was dabei tatsächlich geschieht, ist etwas anderes, und das Projekt selbst sagt es an mehreren Stellen unverblümt.

Eine Tool-Beschreibung ist fremder Text im eigenen Fenster

Die Kette ist kurz und jedes Glied belegt. Erstens geht in die Auswahl neben Ihrer Anfrage die Beschreibung des Tools (externe Seite, platform.claude.com) ein. Zweitens stammt diese Beschreibung bei einem fremden Server von jemand anderem. Drittens steht sie im selben Fenster wie Ihre Anweisung, sobald der Host sie dorthin gibt.

Dieses dritte Glied ist der Ort, an dem Sie eingreifen können, und es gehört zur Kette dazu. Zwischen Server und Modell steht immer der Host, und die Architekturseite führt das unter seinen Aufgaben:

Manages context aggregation across clients (externe Seite, modelcontextprotocol.io)

Er kann also filtern, umschreiben, zurückhalten. Tut er nichts davon, hat der Betreiber eines eingebundenen Servers eine Textstelle in Ihrem Kontext, die bei jeder Anfrage mitgelesen wird. Die Spezifikation zieht daraus die einzig mögliche Folgerung:

descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server (externe Seite, modelcontextprotocol.io)

seitlich verschiebbar

eigene Darstellung, Stand 07.08.2026

Das ist kein Nebensatz aus einem Sicherheitsanhang, das steht im Grundlagenteil unter den Kernprinzipien. Und es ist die Antwort auf die Frage, warum ein MCP-Server mehr ist als eine Bibliothek: Eine Bibliothek liefert Code, den Sie aufrufen. Ein MCP-Server liefert zusätzlich Text, den Ihr Modell liest.

Dieser Kanal läuft in eine Richtung, und das ist beim Nachdenken über den Schaden der entscheidende Punkt. Was in Ihrem Fenster steht, bekommt ein Server nicht zu sehen:

Full conversation history stays with the host (externe Seite, modelcontextprotocol.io)

Er schreibt hinein, mitlesen kann er nicht. Wer über diesen Weg an etwas herankommen will, muss also das Modell dazu bringen, es ihm zu schicken. Damit ist auch gesagt, wie ein Angriff über diesen Weg aussehen muss: als Aufforderung, ein Tool mit bestimmten Angaben aufzurufen.

Was ein Tool ist, wenn man es nüchtern betrachtet

Derselbe Abschnitt der Spezifikation nennt die Sache beim Namen:

Tools represent arbitrary code execution and must be treated with appropriate caution. (externe Seite, modelcontextprotocol.io)

Der Satz sagt nichts darüber, was ein einzelnes Tool tatsächlich tut. Ein Wetterabruf bleibt ein Wetterabruf. Er sagt, womit zu rechnen ist, solange man nicht nachgesehen hat, und das ist eine Vorschrift für den Umgang. Wer sie auf die eigene Tool-Liste anwendet, kommt zu einer anderen Zahl eingebundener Server als jemand, der von Erweiterungen ausgeht.

Dazu die zweite Forderung, die dieselbe Seite aufstellt:

Hosts must obtain explicit user consent before invoking any tool (externe Seite, modelcontextprotocol.io)

In der Praxis ist das der Bestätigungsdialog, und in der Praxis wird er weggeklickt oder dauerhaft abgeschaltet, sobald er das dritte Mal erscheint. Das liegt an einer Eigenschaft häufiger Dialoge und sagt über die Anwender nichts aus. Wer die Zustimmung als Schutz einplant, plant mit einem Schutz, der sich mit der Zeit selbst abschaltet.

Verlangt ist dabei die Einwilligung, ihre Form steht dem Programm frei. Eine Freigabe, die nur für lesende Aufrufe gilt, oder eine, die für die Dauer einer Sitzung ausgesprochen wird, erfüllt dieselbe Forderung und erscheint seltener. Was danach noch fragt, ist die Ausnahme, und eine Ausnahme wird gelesen.

Ein lokaler Server ist ein Programm, und die Frage ist, mit welchen Rechten

Der Fall, der Anwender am ehesten trifft, hat mit dem Protokoll wenig zu tun und mit der Installation alles. Der Sicherheitsleitfaden des Projekts stellt klar, worum es sich bei einem lokal betriebenen Server handelt:

Local MCP servers are binaries that are downloaded and executed on the same machine as the MCP client. (externe Seite, modelcontextprotocol.io)

Der Satz unmittelbar danach ist der wichtigere, denn er nennt die Bedingung, unter der die Aufzählung dahinter überhaupt gilt:

Without proper sandboxing and consent requirements in place, the following attacks become possible (externe Seite, modelcontextprotocol.io)

Erst dann folgt die Liste, und ihr erster Punkt ist der bekannte:

Arbitrary code execution. Attackers can execute any command with MCP client privileges. (externe Seite, modelcontextprotocol.io)

Ein Eintrag in einer Konfigurationsdatei, der mit einem Klick übernommen wird, startet also ein Programm. Wie viel dieses Programm darf, entscheidet sich außerhalb von MCP. Vom Wirtsprogramm verlangt der Leitfaden zuerst eine Warnung, die den Vorgang beim Namen nennt:

Warn that MCP servers run with the same privileges as the client (externe Seite, modelcontextprotocol.io)

Sechs Zeilen weiter steht, was danach zu tun ist:

Execute MCP server commands in a sandboxed environment with minimal default privileges (externe Seite, modelcontextprotocol.io)

Launch MCP servers with restricted access to the file system, network, and other system resources (externe Seite, modelcontextprotocol.io)

Dieselbe Reihenfolge steht in Kapitel 01: erst die Umgebung, dann die Allowlist. Ein Punkt der Angriffsliste bleibt allerdings auch dann stehen, weil ihn keine Grenze berührt:

No visibility. Users have no insight into what commands are being executed. (externe Seite, modelcontextprotocol.io)

Eine Sandbox begrenzt, was ein Programm anrichten kann. Was es tut, steht damit auf keinem Bildschirm.

Warum die Menge das Problem verschiebt

Ein einzelner geprüfter Server ist eine überschaubare Sache. Zwanzig Server aus einem Verzeichnis sind eine andere Lage, und der Grund ist Arithmetik: Bei zwanzig Servern kennt niemand mehr alle Tool-Beschreibungen, und beim nächsten Update liest sie erst recht niemand. Eine davon ändert sich, und im Programm sieht das aus wie vorher. Genau hier liegt der Unterschied zu einer Bibliothek: Deren Änderungen stehen in einem Diff, den man lesen kann. Die Tool-Beschreibung eines entfernten Servers ändert sich ohne Commit und ohne Versionsnummer.

Schließen lässt sich diese Lücke, und zwar an derselben Stelle wie alles andere in diesem Kapitel. Wer die abgeholte Liste festhält und sie beim nächsten Start mit der vorigen vergleicht, bekommt seinen Diff. Der Standard sieht das nicht vor. Das Programm davor kann es tun.

Was praktisch hilft

Fünf Dinge, die auch dann wirken, wenn das Vertrauen in den Betreiber sich als falsch herausstellt. Ganz ohne Vertrauen geht es nicht: Wer einen entfernten Server benutzt, verlässt sich weiter darauf, dass er die geschickten Daten so behandelt, wie er es zusagt.

Wenige Server, bewusst gewählt. Die Zahl ist der wirksamste Hebel, weil alles Weitere mit ihr skaliert.

Tools einzeln abschalten. Ein Server, von dem Sie zwei von zwölf Tools brauchen, liefert zehn Beschreibungen zu viel in Ihr Fenster.

Lokale Server in einer Umgebung starten, die weniger hergibt als Ihr Konto. Der Leitfaden nennt dafür Behälter, chroot und die Sandboxes des Betriebssystems. Diese Grenze hält auch dann, wenn die Prüfung der Herkunft danebenlag.

Lokale Server aus Quellen, die Sie lesen können. Bei einer heruntergeladenen Binärdatei ist der Unterschied zwischen „vertrauenswürdig“ und „bisher unauffällig“ nicht überprüfbar. Und die Fassung festschreiben, sonst holt der nächste Start etwas anderes.

Die Grenze im eigenen Programm. Was ein Tool anrichten darf, entscheidet die Schicht, die den Aufruf entgegennimmt, und die gehört Ihnen. Das ist dieselbe Trennung, die Grundkurs, Kapitel 09 beschreibt, angewendet auf eine Tool-Liste, die Sie nicht selbst geschrieben haben.