Was ist ein MCP-Server? So funktionieren MCP und MCP UI 2026

Am 1. April 2025 veröffentlichte Invariant Labs ein Tool namens add. Es nahm zwei Zahlen entgegen und gab ihre Summe zurück. Seine Beschreibung enthielt außerdem einen mit IMPORTANT markierten Block, unsichtbar in der Oberfläche des Clients, der das Modell anwies, ~/.cursor/mcp.json und ~/.ssh/id_rsa zu lesen und beide Dateien über einen ungenutzten Parameter hinauszuschleusen. Das Modell gehorchte. Auf dem Bildschirm stand eine Addition.

Diese Demonstration ist die nützlichste Einführung in MCP-Server, die ich kenne, weil sie beide Hälften auf einmal zeigt. Das Protokoll funktionierte genau wie vorgesehen: Ein KI-Client entdeckte ein Tool, las seine Beschreibung und rief es auf. Das Vertrauensmodell war der Teil, den noch niemand gebaut hatte.

Was ein MCP-Server ist

Ein MCP-Server ist ein Programm, das KI-Anwendungen Tools, Daten und Prompts über das Model Context Protocol (MCP) bereitstellt. Die offizielle Dokumentation definiert MCP als „einen Open-Source-Standard, um KI-Anwendungen mit externen Systemen zu verbinden“. Ein KI-Client wie Claude, ChatGPT, Visual Studio Code oder Cursor verbindet sich mit dem Server, fragt ab, was er anbietet, und ruft diese Fähigkeiten im Auftrag der Person auf, die ihn nutzt.

Anthropic kündigte MCP am 25. November 2024 an, mit sechs fertigen Servern: Google Drive, Slack, GitHub, Git, Postgres und Puppeteer. OpenAI übernahm das Protokoll im März 2025. Google DeepMind folgte im April. Im Dezember 2025 übergab Anthropic das Protokoll an die Agentic AI Foundation, einen zweckgebundenen Fonds unter dem Dach der Linux Foundation, den Anthropic, Block und OpenAI gemeinsam gegründet haben.

Das Problem, das MCP löst, ist Multiplikation. Vor MCP schrieb jede KI-Anwendung, die GitHub erreichen wollte, ihren eigenen GitHub-Connector. Jeder Anbieter entwickelte wiederum eine Verbindung pro KI-Anwendung. Zehn Modelle und zehn Tools konnten hundert Integrationen bedeuten. MCP macht daraus zwanzig: Jeder Client implementiert das Protokoll einmal, jedes System stellt einen Server bereit.

Stell es dir als den Schiffscontainer der KI-Integrationen vor. Vor dem Container belud jeder Hafen jede Fracht von Hand, mit eigenen Kränen und eigener Mannschaft. Der Container standardisierte die Kiste, sodass jedes Schiff, jeder Kran und jeder Lkw jede Fracht bewegen konnte. Was in der Kiste lag, standardisierte er nicht, und den Inhalt prüfte er nie. MCP ist derselbe Handel. Merk dir die zweite Hälfte, sie kommt im Abschnitt über Sicherheit zurück.

Wie ein MCP-Server funktioniert

Die aktuelle Spezifikation, Version 2026-07-28, nutzt Nachrichten nach JSON-RPC 2.0 zwischen drei Rollen. Ihre eigene Beschreibung ist drei Zeilen lang: Hosts sind „LLM-Anwendungen, die Verbindungen aufbauen“, Clients sind „Connectoren innerhalb der Host-Anwendung“, und Server sind „Dienste, die Kontext und Fähigkeiten bereitstellen“.

Host, Client, Server

Der Host ist die Anwendung, in die du tippst: Claude Desktop, eine IDE, dein eigener Agent. Darin läuft ein Client pro Serververbindung. Der Server sitzt auf der anderen Seite und spricht mit dem echten System, ob das eine Postgres-Datenbank ist, die GitHub-API oder ein Ordner auf deiner Festplatte. Der Host entscheidet, was das Modell sieht und was der Mensch freigeben muss. Der Server entscheidet, was das darunterliegende System tun wird.

1. Host Claude Desktop · eine IDE · dein eigener Agent

   zeigt dem Modell die Tools, holt die Zustimmung des Menschen ein

2. Client einer pro Serververbindung

   spricht JSON-RPC über stdio oder Streamable HTTP

3. MCP-Server Tools · Ressourcen · Prompts

   beschreibt, was er anbietet, und führt die Aufrufe aus

4. Darunterliegendes System Datenbank · SaaS-API · lokale Dateien

   erledigt die Arbeit

Tools, Ressourcen und Prompts

Ein Server kann drei Arten von Dingen anbieten:

• Tools sind Funktionen, die das Modell ausführen kann: create_issue, query_orders, send_email. Jedes hat einen Namen, eine Beschreibung und ein JSON Schema für seine Eingaben.
• Ressourcen sind Kontext und Daten, die der Mensch oder das Modell lesen kann: eine Datei, ein Datenbankschema, ein Datensatz.
• Prompts sind vorgefertigte Nachrichten und Workflows, die der Mensch auswählen kann, etwa „Fasse diesen Pull Request zusammen“.

Tools bekommen die meiste Aufmerksamkeit, weil sie handeln. Genau deshalb tragen sie auch das meiste Risiko.

Ein Tool-Aufruf Schritt für Schritt

Mit der Revision 2026-07-28 wurde MCP zustandslos. Es gibt keinen initialize-Handshake mehr. Jede Anfrage trägt ihre Protokollversion und die Fähigkeiten des Clients in einem _meta-Feld, und Server müssen eine Methode server/discover implementieren, damit ein Client vorab fragen kann, was sie unterstützen. Ein einzelner Tool-Aufruf läuft jetzt so ab:

1. Jemand bittet: Lege ein Ticket für diesen Bug an

2. Schritt 1

   Fähigkeiten abfragen

   • Der Client kann server/discover für Versionen und Fähigkeiten aufrufen
3. Schritt 2

   Tools auflisten

   • tools/list liefert Namen, Beschreibungen und Eingabeschemas
4. Schritt 3

   Modell wählt ein Tool

   • Der Host übergibt die Tool-Definitionen an das Modell
5. Schritt 4

   Zustimmung

   • Laut Spezifikation müssen Hosts vor jedem Tool-Aufruf eine ausdrückliche Zustimmung einholen
6. Schritt 5

   Aufruf

   • tools/call mit Argumenten, Protokollversion in _meta

7. Fehlt eine Eingabe? Der Server gibt input_required zurück, der Client wiederholt den Aufruf mit den Antworten

   Schritt 6

   Ergebnis

8. Das Ergebnis geht als Kontext zurück an das Modell

Schritt 6 ist neu in dieser Revision. Ein Server, der mehr Informationen braucht, schickt keine eigene Anfrage mehr an den Client zurück. Er gibt ein Ergebnis mit der Markierung input_required zurück, der Client holt die Antwort ein und wiederholt den ursprünglichen Aufruf. Die Spezifikation nennt das Muster Multi Round-Trip Request.

Transporte: stdio und Streamable HTTP

Die Spezifikation definiert zwei Standard-Transporte:

• stdio: Der Client startet den Server als Unterprozess und tauscht zeilenweise getrenntes JSON-RPC über Standardeingabe und Standardausgabe aus. So laufen die meisten lokalen Server, und das heißt: Der Server läuft auf deinem Rechner mit deinen Rechten.
• Streamable HTTP: Jede Nachricht ist ein HTTP POST an einen einzigen Endpunkt, und Antworten kommen als JSON-Objekt oder als anfragebezogener Event-Stream zurück. So laufen entfernte, gehostete Server.

Der ältere Transport HTTP+SSE ist offiziell veraltet. Die Revision 2026-07-28 hat außerdem Sitzungen auf Protokollebene und den Header Mcp-Session-Id entfernt. Ein Server, der Zustand über mehrere Aufrufe hinweg braucht, erzeugt jetzt sein eigenes Handle und bekommt es als gewöhnliches Tool-Argument zurück.

Autorisierung

Autorisierung ist in MCP optional, und sie gilt nur für HTTP. Bei stdio sollen Server laut Spezifikation ihre Zugangsdaten stattdessen aus der Umgebung beziehen. Bei HTTP agiert ein geschützter MCP-Server als Resource Server nach OAuth 2.1. Er muss OAuth Protected Resource Metadata (RFC 9728) veröffentlichen, damit Clients seinen Autorisierungsserver finden. Clients müssen genau den Server benennen, für den ein Token gedacht ist (Resource Indicators nach RFC 8707). Server müssen jedes Token ablehnen, das nicht für sie ausgestellt wurde, und die Sicherheitsrichtlinien erklären „Token Passthrough“, also das unveränderte Weiterreichen des Client-Tokens an eine nachgelagerte API, ausdrücklich für verboten.

Diese letzte Regel ist wichtiger, als sie aussieht. Ein Server, der jedes empfangene Token weiterreicht, wird zum Proxy für alle, die eines besitzen.

Was MCP UI hinzufügt: Server, die eine Oberfläche zurückgeben

Textantworten versagen in dem Moment, in dem jemand vierzig Zeilen vergleichen, ein Formular mit zwölf Feldern anpassen oder einen Stapel Änderungen einzeln freigeben muss. „MCP UI“ ist der Begriff, unter dem Leute nach der Lösung suchen: Ein Server gibt eine interaktive Oberfläche zurück, die im KI-Client neben der Unterhaltung gerendert wird.

Der Status ist klar abzugrenzen. Die Idee begann mit dem Community-Projekt MCP-UI. OpenAI entwickelte einen ähnlichen Mechanismus für sein Apps SDK. Am 21. November 2025 schlug das MCP-Projekt gemeinsam mit beiden einen Standard vor. Am 26. Januar 2026 veröffentlichte es MCP Apps als erste offizielle MCP-Erweiterung. Die MCP-UI-Pakete implementieren inzwischen diesen Standard und dienen weiter als Experimentierfeld für Erweiterungen.

MCP UI heißt heute also MCP Apps. Es ist offiziell, und es ist eine Erweiterung, kein Kernprotokoll. Erweiterungen sind optional: Client und Server müssen sie beide unterstützen, und die Dokumentation sagt klar, dass „die Unterstützung durch Hosts je nach Client variiert“. Die Dokumentation von MCP Apps nennt Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam und Archestra.AI als unterstützende Hosts. Ein Server, dessen Tools UI zurückgeben, muss trotzdem für einen Client funktionieren, der nur Text anzeigt.

Mechanisch nutzt MCP Apps die vorhandenen Bausteine von MCP:

1. Die Beschreibung eines Tools enthält ein _meta.ui.resourceUri, das auf eine ui://-Ressource zeigt.
2. Der Host lädt diese Ressource, eine HTML-Seite mit ihren Skripten, und kann sie schon vor dem Tool-Aufruf vorladen.
3. Der Host rendert sie in einem abgeschotteten iframe (Sandbox), der weder die übergeordnete Seite noch deren Cookies oder Speicher lesen kann.
4. App und Host kommunizieren über postMessage in einem JSON-RPC-Dialekt von MCP. Die App kann Tool-Aufrufe anfordern, und der Host entscheidet, welche er zulässt.

Die Kosten sind real. Du lieferst jetzt ein Web-Frontend in der Anwendung von jemand anderem aus, mit einer Content Security Policy, die du deklarieren musst, Darstellungsregeln, die du nicht kontrollierst, und einem Text-Fallback für jeden Host, der sie ignoriert. Der Gewinn: Freigabearbeit ist kein Chatverlauf mehr. Die Liste guter Einsatzfälle in der Dokumentation endet mit „Spesenabrechnungen freigeben, Codeänderungen prüfen oder Issues triagieren“, und das ist der ehrliche Kern: MCP UI ist am stärksten bei Entscheidungen, nicht bei Dekoration.

Ein lesendes Tajo-Beispiel

Die Alto-MCP-Schnittstelle von Tajo enthält query_contacts. Dieses Tool durchsucht die im verbundenen Workspace gespeicherten Kontakte. Frage einen vorhandenen Kontakt über seine E-Mail-Adresse ab und prüfe die zurückgegebene ID, den E-Mail-Einwilligungsstatus und den Zeitpunkt der letzten Erfassung. Das separate Tool get_contact_topic_status liest die Themenabonnements dieses Kontakts.

Diese Aufrufe lesen Workspace-Daten. Sie holen keinen aktuellen Datenstand vom Anbieter, starten keinen Sync und senden keine Nachricht. Sie belegen auch nicht, dass jeder Anbieter-Connector aktiv ist. Fehlende oder veraltete Workspace-Daten musst du an ihrer Quelle untersuchen. Ein leeres Ergebnis beweist nicht, dass die Person in Brevo fehlt.

Verbinde über die Tajo-MCP-Dokumentation einen unterstützten Client und prüfe die Tools, die deinem autorisierten Workspace tatsächlich zur Verfügung stehen. Ein interaktives Panel kann die Prüfung erleichtern, wenn der Host MCP Apps unterstützt. Das Ergebnis muss auch als Text verständlich bleiben.

Ein Tool-Aufruf ist kein dauerhafter Sync

Ein wiederkehrender Sync braucht zusätzlich einen Zeitplan, stabile Datensatzidentitäten, gespeicherten Fortschritt, Wiederholungsregeln und einen Nachweis abgeschlossener Schreibzugriffe. Dafür ist die ausführende Anwendung verantwortlich. MCP standardisiert den Tool-Zugriff. Die bloße Auflistung eines Tools liefert diese Geschäftsregeln nicht.

Nach einer Zeitüberschreitung lässt sich ein Lesezugriff meist wiederholen. Ein Versand oder eine Zahlung kann bereits erfolgt sein. Bewahre den Ausführungsnachweis auf und kläre das Ergebnis vor einem weiteren Versuch. Die Konfidenz eines Modells autorisiert weder die Aktion noch macht sie deren Wiederholung sicher.

Den Zielzugriff eines konkreten Kontaktpfads erklärt der Brevo-API-Leitfaden. Wann berechnete Felder einen eigenen gepflegten Sync rechtfertigen, beschreibt Reverse ETL.

Die Sicherheitsrechnung kommt mit dem Protokoll

Der Einwand verdient es, vollständig ausgesprochen zu werden: „MCP gibt einem probabilistischen Modell eine Liste von Funktionen, die Daten löschen und E-Mails senden können, und verlässt sich dann auf Text von Fremden, der sie beschreibt. Das ist kein Integrationsstandard. Das ist ein Supply-Chain-Angriff mit Spezifikation.“ Das meiste davon stimmt. Die Spezifikation teilt die Prämisse. Ihr Sicherheitsabschnitt sagt, Tools „stehen für beliebige Codeausführung und müssen mit angemessener Vorsicht behandelt werden“, Tool-Beschreibungen „sollten als nicht vertrauenswürdig gelten, sofern sie nicht von einem vertrauenswürdigen Server stammen“, und MCP „kann diese Sicherheitsprinzipien nicht auf Protokollebene durchsetzen“.

Hier die bisherige Bilanz:

• Tool Poisoning. Die Veröffentlichung von Invariant Labs vom April 2025, das add-Tool von oben. Derselbe Beitrag beschrieb Rug Pulls, bei denen ein Server die Beschreibung eines Tools ändert, nachdem du es freigegeben hast, und Shadowing, bei dem ein bösartiger Server das Verhalten des Modells gegenüber einem vertrauenswürdigen Server umschreibt.
• Kompromittierte lokale Server. Im Juli 2025 legte JFrog CVE-2025-6514 in mcp-remote offen, Versionen 0.0.5 bis 0.1.15. Über die Lücke konnte ein bösartiger Server Befehle auf dem Rechner der Nutzer:innen ausführen. Im selben Sommer traf CVE-2025-49596 den MCP Inspector von Anthropic selbst, der standardmäßig ohne Authentifizierung ausgeliefert wurde.
• Aufgeblähte Scopes. Die offiziellen Security Best Practices benennen das Muster: Tokens, die vorab files:* oder admin:* erhalten, weil ein Server jeden Scope aufgelistet und der Client sie alle angefordert hat.
• Offizielle Besorgnis. Im Mai 2026 erklärte die US-amerikanische National Security Agency, die „rasante Verbreitung“ von MCP habe „die Entwicklung seines Sicherheitsmodells überholt“.

Falsch liegt der Einwand bei der Schlussfolgerung. Die Lösung war nie, keine Modelle mehr mit Systemen zu verbinden. Teams taten das längst, mit rohen API-Keys, die in Prompts und Skripte kopiert wurden, ganz ohne Audit-Trail. Die Lösung ist, einen MCP-Server wie jede andere privilegierte Abhängigkeit zu behandeln:

• Installiere Server nur aus Quellen, denen du dieselben Zugangsdaten auch außerhalb von MCP anvertrauen würdest.
• Bevorzuge entfernte Server mit OAuth und engen Scopes gegenüber lokalen Binaries mit langlebigen Schlüsseln.
• Verlange für jeden Schreibzugriff eine menschliche Freigabe, und protokolliere, wer was freigegeben hat.
• Pinne Serverversionen, und prüfe erneut, wenn sich die Beschreibung eines Tools ändert.
• Stelle aufgabenbezogene Tools bereit, keine vollständige API. Ein Modell kann keinen Delete-Endpunkt missbrauchen, der nie freigegeben wurde.

Das Protokoll hat die Kiste standardisiert. Die Fracht zu prüfen bleibt deine Aufgabe.

Einen MCP-Server bauen oder einen vorhandenen nutzen

Öffentliche Verzeichnisse wie mcp.so katalogisieren Server aus der Community, und viele SaaS-Anbieter veröffentlichen eigene. Brevo zum Beispiel liefert einen MCP-Server, der auch in einzelne Server aufgeteilt ist. So kann ein Agent Zugriff auf Kontakte bekommen, ohne an die Kampagnen zu kommen. Die Entscheidung hängt weniger am Aufwand als an der Frage, wem der Zuschnitt der Tools gehören soll.

Welchen MCP-Server sollte dein Agent nutzen?

1. Der Anbieter veröffentlicht einen Server, der die Aufgabe abdeckt

   Nutze den Server des Anbieters

   Er folgt der API, und der Anbieter pflegt ihn.

2. Ein System, aber du brauchst weniger oder sicherere Aktionen

   Nutze ihn, aber eingeschränkt

   Vergib minimale Scopes und gib nur die Tool-Gruppen frei, die der Agent braucht.

3. Interne Daten oder ein System ohne Server

   Bau einen kleinen Server

   Ein paar aufgabenbezogene Tools über deiner eigenen API, mit deiner eigenen Authentifizierung.

4. Die Aufgabe umfasst zwei oder mehr Systeme

   Bau oder übernimm eine kontrollierte Schicht

   Ein Satz Tools, Einwilligungsregeln und ein Audit-Verlauf über alle Systeme hinweg.

Einen einfachen Server zu bauen ist der leichte Teil. Mit einem offiziellen SDK ist ein funktionierender stdio-Server mit einem Tool die Arbeit eines Nachmittags. Die Kosten kommen später: OAuth für die HTTP-Version, Abkündigungen (die Revision 2026-07-28 hat Roots, Sampling und Logging sowie Dynamic Client Registration als veraltet markiert) und die Daueraufgabe, Tool-Beschreibungen zu schreiben, die ein Modell richtig liest. Eine API mit einem Tool pro Endpunkt zu kapseln ist der häufigste Fehler. Jede Tool-Beschreibung ist Text, den das Modell lesen und abwägen muss. Eine kurze Liste aufgabenbezogener Tools schlägt deshalb die gesamte API-Oberfläche.

MCP, APIs, Integrationen und iPaaS

MCP ersetzt keine APIs. Fast jeder MCP-Server ist eine Hülle um eine API. Die API bleibt der Ort, an dem die Arbeit passiert, mit eigenen Rate Limits, eigenem Datenmodell und eigenen Macken. MCP ändert, wer sie aufrufen kann: ein Modell, zur Laufzeit, das den Aufruf anhand einer Beschreibung wählt, statt dass jemand in der Entwicklung ihn vorab fest einprogrammiert.

Diese Unterscheidung zieht eine saubere Grenze zu den zwei anderen Dingen, mit denen MCP verwechselt wird:

• Integrationen und iPaaS (die wichtigsten Plattformen im Vergleich) bewegen Daten nach Zeitplan oder Auslöser, deterministisch, egal ob gerade jemand chattet. Eine nächtliche Synchronisation von 40.000 Bestellungen in ein CRM sollte nicht davon abhängen, dass ein Modell beschließt, 40.000 Tool-Aufrufe zu machen.
• Reverse ETL schiebt modellierte Daten aus einem Data Warehouse zurück in operative Tools. Was Reverse ETL ist und wann es passt ist ein eigenes Thema, und es ist eine Pipeline, keine Unterhaltung.
• MCP ist für die Momente, in denen ein Mensch oder ein Agent über diese Systeme hinweg fragen, nachsehen oder handeln muss, auf Abruf.

Der Fehler läuft in beide Richtungen. Manche Teams bauen MCP-Server für Massensynchronisation und bekommen langsame, teure, nicht reproduzierbare Pipelines. Andere Teams bauen sorgfältige Integrationen und geben ihrem KI-Assistenten dann einen rohen API-Key, um sie abzufragen. Sie bekommen eine unkontrollierte Hintertür.

Bei einer unterstützten Integration sollten der dauerhafte Job und seine Prüftools eine ausdrücklich definierte Berechtigungsgrenze teilen. Prüfe Connector, erlaubte Aktionen und protokollierte Ergebnisse für den jeweiligen Ablauf. Die Integrationsdokumentation unterscheidet Einrichtungshinweise von Wegen, für die noch Produktionsnachweise fehlen. MCP kann separate freigegebene Tools anbieten. Ihre Auflistung beweist nicht, dass ein wiederkehrender Sync oder alle nötigen Kontrollen aktiv sind.

In 22 Monaten ging MCP von sechs Referenzservern zu einem Projekt der Linux Foundation, das Claude, ChatGPT, VS Code und Cursor alle sprechen. Ein Modell mit einem System zu verbinden ist jetzt der billige Teil. Zu entscheiden, was es dort darf, ist die Arbeit.