Was ist ein MCP-Server? Tools, Ressourcen und Prompts erklärt | We.Inc
Ein MCP-Server ist ein Programm, das KI-Anwendungen Tools, Ressourcen und Prompts über das Model Context Protocol anbietet. Sieh dir die echten JSON-Nachrichten Schritt für Schritt an.
Was ist ein MCP-Server?
Ein MCP-Server ist ein Programm, das KI-Anwendungen über das Model Context Protocol etwas zum Arbeiten gibt: Tools, die sie aufrufen, Ressourcen, die sie lesen, und Prompts, die Nutzer auswählen können. Die Anwendung verbindet sich über einen MCP-Client, und beide Seiten tauschen JSON-RPC-2.0-Nachrichten aus, lokal über stdio oder remote über Streamable HTTP.
Die drei Dinge, die ein Server anbieten kann
Primitive
Was es ist
Wer über die Nutzung entscheidet
Wichtigste Methoden
Tools
Funktionen, die eine Aktion ausführen, mit einem JSON Schema für ihre Eingabe
Das Modell
tools/list, tools/call
Ressourcen
Schreibgeschützte Daten, adressiert über eine URI, etwa eine Datei oder ein Schema
Die Anwendung
resources/list, resources/read
Prompts
Wiederverwendbare Anweisungsvorlagen mit Argumenten
Der Nutzer
prompts/list, prompts/get
Geh unten Schritt für Schritt durch einen echten Austausch. Jeder Schritt zeigt das JSON, das ein Client sendet, und was der Server antwortet, mit den Nachrichtenformen aus der aktuellen Spezifikation (Version 2026-07-28). Die rohen Nachrichten zu lesen ist der schnellste Weg, einen Server nicht mehr für Magie zu halten.
Wähle einen Schritt: Discovery, Tools auflisten, ein Tool aufrufen oder eine Änderungsbenachrichtigung empfangen.
Lies links den Request und rechts die Antwort.
Sieh dir den Hinweis unter dem Paar für das eine Feld an, das in diesem Schritt am wichtigsten ist.
Kopiere eine beliebige Nachricht, um sie mit dem zu vergleichen, was dein eigener Server oder Client sendet.
Benenne Tools mit einem klaren Präfix, etwa weather_current statt get. Ein Host kann Tools von vielen Servern gleichzeitig laden, und vage Namen kollidieren.
Schreib jede Tool-Beschreibung für das Modell, nicht für einen Menschen, der eine Liste überfliegt. Sag, was das Tool tut und wann es gewählt werden sollte.
Stelle schreibgeschützten Kontext als Ressourcen statt als Tools bereit. Bei Ressourcen entscheidet die Anwendung, was einbezogen wird, sodass das Modell keine Daten abruft, die es nicht braucht.
Behandle jedes Tool, das etwas verändert, als riskant. Das Protokoll überlässt die Freigabe dem Host, also entwirf Tools, die sich sicher Aufruf für Aufruf bestätigen lassen.
Häufige Fragen
Ist ein MCP-Server dasselbe wie eine API?
Meist umschließt er eine. Ein typischer Server ruft eine bestehende API oder Datenbank auf und beschreibt diese Operationen auf standardisierte Weise, sodass jede MCP-fähige Anwendung sie ohne eigenen Integrationscode finden und aufrufen kann.
Läuft ein MCP-Server auf meinem Computer oder in der Cloud?
Beides ist möglich. Ein lokaler Server wird von der Anwendung gestartet und kommuniziert über Standardeingabe und Standardausgabe. Ein Remote-Server läuft woanders und wird über Streamable HTTP erreicht, wo er viele Clients bedienen kann.
Enthält ein MCP-Server ein Sprachmodell?
Nein. Der Server bietet nur Tools, Ressourcen und Prompts an. Die Host-Anwendung besitzt das Modell und entscheidet, was sie ihm sendet. Die Spezifikation markiert vom Server angefordertes Sampling ab Version 2026-07-28 als veraltet.
Was hat sich in Protokollversion 2026-07-28 geändert?
Das Protokoll wurde zustandslos: Jeder Request trägt die Protokollversion und die Fähigkeiten in seinem _meta-Feld, und Server beantworten einen verpflichtenden server/discover-Request. Änderungsbenachrichtigungen sind jetzt optional über einen subscriptions/listen-Stream.
Wer genehmigt einen Tool-Aufruf?
Der Host. Die Protokolldokumentation schlägt Freigabedialoge, Berechtigungseinstellungen und Aktivitätsprotokolle vor, aber deren Durchsetzung ist Aufgabe der Anwendung, daher sollte ein Server nie annehmen, dass ein Mensch einen Aufruf geprüft hat.
Host, Client und Server
In jedem Setup gibt es drei Rollen. Der Host ist die KI-Anwendung, die die Person nutzt. Für jeden Server, mit dem er sich verbindet, erstellt der Host einen Client, und jeder Client hält eine eigene Verbindung zu genau einem Server.
Ein Host, der mit einem Dateiserver und einem Datenbankserver verbunden ist, hält also zwei Clients. Der Server ist einfach das Programm, das antwortet, egal wo es läuft.
Zwei Schichten: Daten und Transport
Die Datenschicht definiert die Nachrichten: JSON-RPC-2.0-Requests, -Antworten und -Benachrichtigungen für Discovery, Tools, Ressourcen und Prompts. Die Transportschicht befördert diese Nachrichten und kümmert sich um Verbindungsaufbau und Autorisierung.
Es gibt zwei Standard-Transporte. Stdio leitet Nachrichten über Standardeingabe und Standardausgabe zwischen Prozessen auf einem Rechner. Streamable HTTP nutzt HTTP POST vom Client zum Server, optional mit Server-Sent Events für Streaming, und unterstützt Bearer-Tokens, API-Schlüssel und OAuth.
Was der Client im Gegenzug anbieten kann
Server können den Client auch um etwas bitten. Mit Elicitation kann ein Server über die Methode elicitation/create weitere Informationen oder eine Bestätigung vom Nutzer anfordern.
Sampling, bei dem ein Server den Host um eine Modellantwort bittet, und Logging auf Protokollebene sind ab Version 2026-07-28 veraltet. Neue Server sollten bei stdio nach stderr loggen oder OpenTelemetry nutzen.
Stdio oder Streamable HTTP?
Einen Transport wählen
Stdio
Streamable HTTP
Wo der Server läuft
Auf demselben Rechner, vom Host gestartet
Überall, wo er über das Netzwerk erreichbar ist
Wie Nachrichten übertragen werden
Standardeingabe- und Standardausgabe-Streams
HTTP POST, optional Server-Sent Events
Typische Clients pro Server
Einer
Viele
Authentifizierung
Nicht nötig, es ist ein lokaler Prozess
Bearer-Tokens, API-Schlüssel, eigene Header; OAuth empfohlen
Wohin geloggt wird
stderr (stdout trägt die Protokollnachrichten)
Deine normalen Server-Logs
Wie ein Ressourcen-Template aussieht
Ein Ressourcen-Template mit URI-Parameter
Clients finden Templates mit resources/templates/list, füllen die geschweiften Klammern aus und lesen das Ergebnis mit resources/read.
1. Discovery
server/discover ist für den Client optional, aber jeder Server muss darauf antworten. Das capabilities-Objekt sagt, welche Primitive existieren; listChanged bedeutet, dass der Server über Tool-Änderungen benachrichtigen kann.
2. Tools auflisten
Jedes Tool hat einen Namen, eine Beschreibung und ein inputSchema in JSON Schema. Der Host gibt diese an das Modell weiter, damit es weiß, was es aufrufen darf.
3. Ein Tool aufrufen
Der Name muss exakt mit dem gelisteten Tool übereinstimmen, und die Argumente müssen zu seinem inputSchema passen. Ergebnisse kommen als content-Array zurück, hier ein einzelnes Textelement.
4. Änderungsbenachrichtigung
Benachrichtigungen haben keine id, daher antwortet niemand darauf. Der Client erhält diese nur, weil er einen subscriptions/listen-Stream mit toolsListChanged geöffnet hat.