Alle Artikel

Was ist ein MCP-Server eigentlich?

Zieht man das Marketing ab, ist MCP ein kleines, langweiliges Protokoll. Das ist seine beste Eigenschaft.

Veröffentlicht am 22. September 2026 · Aktualisiert am 6. Oktober 2026 · 6 Min. Lesezeit

Ein Sprachmodell allein kann Ihre Dateien nicht lesen, Ihre Datenbank nicht abfragen und sich nicht an gestern erinnern. Es erzeugt Text. Alles andere — jede Aktion, jeder Abruf — geschieht, weil ein Programm außerhalb des Modells hingegangen ist und es getan hat.

Vor dem Model Context Protocol war jede einzelne dieser Verbindungen maßgeschneidert. Wenn Claude Ihr Notion lesen sollte und ChatGPT Ihr Notion lesen sollte, schrieben Sie zwei Integrationen gegen zwei verschiedene Plugin-Systeme, und keine überlebte das nächste Release des Anbieters. MCP ist die Übereinkunft, die damit Schluss macht: ein Server, jeder Client, der das Protokoll spricht.

Der grobe Aufbau

Es gibt drei Beteiligte. Der Host ist die Anwendung, die Sie tatsächlich benutzen — ein Desktop-Assistent, eine IDE, eine Chat-Oberfläche. Der Client lebt im Host und verwaltet eine Verbindung. Der Server ist das, was Sie oder jemand anderes geschrieben hat, und er hält die Fähigkeit: Zugriff auf ein Dateisystem, eine Postgres-Instanz, einen Kalender, einen Gedächtnisspeicher.

Sie sprechen JSON-RPC 2.0. Das ist kein Detail, bei dem man verweilen müsste, aber es lohnt sich zu wissen, denn es bedeutet, dass das Ganze inspizierbar ist. Sie können die Nachrichten lesen. Es gibt keine magische Schicht, in der das Modell etwas „entscheidet“, das Sie nicht sehen können.

Der Ablauf ist mit Absicht öde: Der Client verbindet sich, beide Seiten tauschen ihre Fähigkeiten aus, der Client fragt, was der Server anbietet, und von da an kann das Modell eines dieser Dinge beim Namen anfordern. Der Server führt aus. Das Ergebnis kommt als Text zurück, den das Modell liest.

Die drei Dinge, die ein Server anbieten kann

Fast jeder Server, dem Sie begegnen werden, nutzt das erste und ignoriert die beiden anderen. Alle drei lohnen sich zu verstehen, denn der Unterschied betrifft wer entscheidet.

  • Tools — Funktionen, die das Modell aus eigenem Antrieb aufrufen darf. `search_memory`, `create_issue`, `run_query`. Das Modell liest Ihre Beschreibung des Tools und entscheidet, wann sie zutrifft. Hier liegt die Macht, und hier liegt das Risiko.
  • Resources — Daten, die der *Host* liest und in den Kontext legt. Eine Datei, ein Datensatz, ein Dokument. Nicht das Modell löst das aus, sondern die Anwendung. Weniger Autonomie, mehr Vorhersagbarkeit.
  • Prompts — wiederverwendbare Vorlagen, die der Nutzer bewusst auswählt. Am ehesten mit einem Slash-Befehl vergleichbar.

Eine Folge, die man spät entdeckt: Die Beschreibung eines Tools ist keine Dokumentation, sie ist eine Anweisung an das Modell. Wenn ein Tool nie aufgerufen wird, obwohl es sollte, liegt die Lösung meist nicht im Code — sondern daran, dass die Beschreibung dem Modell nicht sagen konnte, zu welcher Situation sie gehört. Wir haben unsere genau aus diesem Grund neu geschrieben, und die Aufrufrate änderte sich sofort.

Lokal oder entfernt: die Entscheidung, auf die es ankommt

Es gibt zwei Transportwege, und die Wahl dazwischen bestimmt das meiste daran, wie sich Ihr Aufbau anfühlt.

stdio startet den Server als Kindprozess auf Ihrer eigenen Maschine. Der Host führt einen Befehl aus, spricht über Standardeingabe und -ausgabe mit ihm und beendet ihn beim Schließen. Nichts verlässt das Gerät. Das ist die richtige Antwort für alles, was lokale Dateien berührt, und deshalb funktionieren die Filesystem- und Git-Server so, wie sie es tun. Der Preis: Er existiert nur auf dieser Maschine. Ihr Laptop und Ihr Telefon teilen ihn nicht, und der Server lebt nur, solange die Anwendung lebt.

HTTP betreibt den Server an einem erreichbaren Ort. Der Host verbindet sich über das Netz, üblicherweise mit OAuth 2.0 authentifiziert. Nun sehen alle Geräte denselben Server, und ein gehosteter Dienst kann einer sein. Der Preis: Sie vertrauen demjenigen, der ihn betreibt, und Sie sollten wissen, wo er läuft — das Thema eines anderen Artikels hier.

Für Gedächtnis im Besonderen ist das keine knappe Entscheidung. Ein Gedächtnis, das nur auf einem Laptop existiert, ist ein Notizbuch. Der ganze Sinn der Sache ist, dass der Assistent, den Sie auf einem anderen Gerät öffnen, es bereits weiß.

Was ein Server Ihnen antun kann

Ein MCP-Server ist Code, dem Sie das Recht zu handeln eingeräumt haben. Behandeln Sie ihn entsprechend.

Ein lokaler Server läuft mit den Rechten Ihres Benutzers — er kann alles lesen, was Sie lesen können. Ein entfernter bekommt alles, was das Modell ihm schickt, und das ist mit der Zeit eine ganze Menge über Sie. Und eine Tool-Beschreibung ist ein an das Modell gerichteter Text, ein Server kann also prägen, wie sich der Assistent verhält, nicht bloß ihm antworten.

Vier Fragen, die man stellen sollte, bevor man einen installiert:

  1. Kann ich den Quellcode lesen, oder ist das ein Binary von einem Unbekannten?
  2. Welche Rechte hält er — ein einzelnes Verzeichnis oder mein ganzes Home?
  3. Falls entfernt: Wer betreibt ihn, in welchem Land, und kann ich meine Daten löschen?
  4. Schreibt er, oder liest er nur? Ein Server mit reinem Lesezugriff hat einen viel kleineren Wirkungsradius.

Das Ökosystem ist jung und überwiegend von Einzelpersonen in gutem Glauben gebaut. Das ist nicht dasselbe wie auditiert. Die offizielle Registry und die Community-Listen sind Werkzeuge zum Entdecken, keine Empfehlungen.

Wann Sie selbst einen schreiben sollten

Die Hürde ist niedrig — ein Server mit zwei Tools ist eine kurze Datei in Python oder TypeScript, und die SDKs erledigen das Protokoll. Die eigentliche Frage ist, ob ein Tool die richtige Form für das ist, was Sie wollen.

Das ist es meistens, wenn der Assistent auf einem laufenden System *handeln* oder etwas abrufen muss, das sich ändert. Meistens nicht, wenn Sie nur wollen, dass das Modell einen festen Textbestand kennt — ihn einzufügen oder als Resource anzubieten ist einfacher und verlässlicher, als dem Modell beizubringen, danach zu fragen.

Wenn Sie die Details wollen: Die Spezifikation ist kurz und lesbar, was selten ist und etwas Gutes über das Projekt aussagt.

Pryzm ist ein entfernter MCP-Server, dessen einzige Aufgabe Gedächtnis ist: Er speichert, was Sie ihm sagen, und holt die relevanten Teile später wieder hervor, in jedem Client, der das Protokoll spricht. Wenn Sie lieber selbst betreiben: Es gibt mehrere kostenlose, selbst hostbare Memory-Server, und wir führen sie in unserem Vergleich auf.