MCP steht in der KI für Model Context Protocol. Erfahre, wie Hosts, Clients und Server KI mit Tools und Daten verbinden und welche Unterschiede zwischen MCP und API sowie zentrale Sicherheitsrisiken bestehen.
MCP steht in der KI für Model Context Protocol. Es ist ein offener Standard, der KI-Anwendungen dabei unterstützt, über eine gemeinsame Schnittstelle eine Verbindung zu externen Tools, Datenquellen und Workflows herzustellen. MCP ersetzt weder APIs noch Function Calling oder RAG. Stattdessen bietet es KI-Anwendungen eine konsistentere Möglichkeit, diese Funktionen zu entdecken und zu nutzen.
MCP steht für Model Context Protocol.
Es handelt sich um einen Open-Source-Standard, der KI-Anwendungen mit externen Systemen wie Dateien, Datenbanken, Suchtools, Kalendern, Code-Repositories und Unternehmenssoftware verbindet. Die offizielle MCP-Dokumentation vergleicht es mit einem USB-C-Anschluss: Verschiedene Geräte können denselben Verbindungsstandard nutzen, anstatt für jede Kombination ein neues Kabel zu benötigen.
Dieser Vergleich ist hilfreich, kann MCP aber auch einfacher erscheinen lassen, als es tatsächlich ist.
MCP ist weder ein KI-Modell noch eine Anwendung oder ein Ersatz für eine API. Es ist ein Kommunikationsstandard, der von kompatiblen KI-Anwendungen und Servern verwendet wird. Die Anwendung benötigt weiterhin ein Sprachmodell, um die Anfrage des Nutzers zu verstehen, während die verbundenen Dienste im Hintergrund oft weiterhin auf ihren bestehenden APIs basieren.
Eine präzisere Definition lautet:
MCP standardisiert, wie eine KI-Anwendung externe Tools und Datenquellen entdeckt, sich mit ihnen verbindet und Informationen mit ihnen austauscht.
Das Wort Kontext ist entscheidend. Ein Sprachmodell kennt nur die Informationen, die in seinen Trainingsdaten enthalten sind oder während der aktuellen Interaktion bereitgestellt werden. MCP kann einer KI-Anwendung Zugriff auf zusätzlichen Kontext geben—etwa auf einen aktuellen Datenbankeintrag, eine lokale Datei oder das Ergebnis einer Live-API-Anfrage—wenn diese Informationen benötigt werden.
Vor MCP erstellten Entwickler in der Regel separate Integrationen für jede Kombination aus KI-Anwendung und externem Dienst.
Stell dir einen KI-Assistenten vor, der mit Google Calendar, GitHub, einer Kundendatenbank und einem internen Abrechnungssystem arbeiten muss. Jede Integration kann ihr eigenes API-Format, Authentifizierungsverfahren, ihre eigenen Funktionsdefinitionen und Regeln zur Fehlerbehandlung haben.
Stell dir nun vor, dieselben Verbindungen für einen weiteren KI-Assistenten erneut erstellen zu müssen.
MCP versucht, diesen wiederholten Integrationsaufwand zu reduzieren. Ein Dienst kann seine Funktionen über einen MCP-Server bereitstellen, während sich kompatible KI-Anwendungen über ein gemeinsames Protokoll verbinden können.
Das bedeutet nicht, dass Entwickler keine Integrationen mehr erstellen müssen. Jemand muss weiterhin den MCP-Server implementieren, ihn mit dem zugrunde liegenden Dienst verbinden, Zugangsdaten verwalten, Anfragen validieren und das System warten. Der Vorteil liegt in der Wiederverwendung: Sobald eine Funktion dem Protokoll entspricht, lässt sie sich möglicherweise leichter mit mehreren kompatiblen KI-Hosts verbinden.
MCP ist besonders wertvoll, wenn die Anzahl der Tools, Datenquellen und KI-Clients zu wachsen beginnt. Bei einer Anwendung, die mit einem stabilen Dienst verbunden ist, kann eine direkte API-Integration weiterhin die einfachere Wahl sein.
MCP verwendet eine Client-Server-Architektur. Die Begriffe können jedoch verwirrend sein, da drei Komponenten beteiligt sind.
Der Host ist die KI-Anwendung, mit der der Nutzer interagiert. Dabei kann es sich um einen Chat-Assistenten, eine Programmierumgebung, eine Desktop-Anwendung oder einen benutzerdefinierten KI-Agenten handeln.
Der Host koordiniert die Unterhaltung, kommuniziert mit dem Sprachmodell, verwaltet Berechtigungen und entscheidet, welche MCP-Verbindungen verfügbar sind.
Ein MCP-Client ist eine Komponente innerhalb des Hosts, die eine Verbindung zu einem MCP-Server aufrechterhält.
Laut der offiziellen MCP-Architektur erstellt ein Host normalerweise für jeden Server eine separate Client-Verbindung. Wenn eine Anwendung eine Verbindung zu einem Dateisystemserver und einem Kalender-Server herstellt, verwaltet sie zwei MCP-Clients.
Ein MCP-Server ist ein Programm, das MCP-Clients bestimmte Funktionen zur Verfügung stellt. Es kann lokal auf dem Gerät des Nutzers oder remote auf einem anderen Server ausgeführt werden.
Ein MCP-Server kann drei grundlegende Arten von Funktionen bereitstellen:
Host und Server handeln zunächst aus, welche Protokollfunktionen sie beide unterstützen. Anschließend kann der Client eine Liste der verfügbaren Funktionen anfordern. Wenn das Modell entscheidet, dass ein Tool relevant ist, leitet der Host die strukturierte Anfrage über den MCP-Client an den richtigen Server weiter.
Das Ergebnis kehrt zur KI-Anwendung zurück und wird zum zusätzlichen Kontext für die nächste Antwort des Modells.
Angenommen, ein Entwickler fragt einen internen KI-Assistenten:
“Prüfe unsere API-Ausgaben für diesen Monat. Wenn sie mehr als 20 % über dem Budget liegen, erstelle eine Warnung für das Engineering-Team.”
Ein vereinfachter MCP-Workflow könnte so aussehen:
get_api_usage und get_budget_limit anbietet.create_alert.MCP standardisiert den mittleren Teil dieses Prozesses: das Entdecken und Beschreiben der Tools und ihrer Eingabeanforderungen, deren Aufruf sowie die Rückgabe strukturierter Ergebnisse.
MCP führt die Berechnung nicht selbst durch, stellt das Sprachmodell nicht bereit und ersetzt weder die Abrechnungs- noch die Messaging-APIs.
Diese Begriffe werden oft als konkurrierende Technologien dargestellt. In der Praxis arbeiten sie auf unterschiedlichen Ebenen und kommen häufig in derselben Anwendung zum Einsatz.
| Konzept | Welches Problem wird gelöst? | Wie verhält es sich zu MCP? |
|---|---|---|
| API | Ermöglicht einem Softwaresystem, Daten oder Aktionen von einem anderen System anzufordern | Ein MCP-Server ruft im Hintergrund häufig bestehende APIs auf |
| Function Calling | Ermöglicht einem Modell, eine strukturierte Anfrage für ein vordefiniertes Tool zu erzeugen | Ein Host kann MCP-Tooldefinitionen in Funktionen umwandeln, die das Modell auswählen kann |
| RAG | Ruft relevante externe Informationen ab, bevor ein Modell antwortet | Ein MCP-Server kann Abruf-Tools oder Ressourcen bereitstellen, aber MCP selbst ist kein RAG |
| MCP | Standardisiert, wie sich kompatible KI-Anwendungen mit Tools und Daten verbinden und mit ihnen interagieren | Dient als Verbindungs- und Interoperabilitätsschicht |
Nein. MCP und APIs lösen verwandte, aber unterschiedliche Probleme.
Eine API definiert, wie ein bestimmter Dienst aufgerufen werden kann. Eine Abrechnungs-API könnte beispielsweise einen Endpunkt definieren, der die Kontonutzung zurückgibt.
MCP definiert, wie eine KI-Anwendung eine von einem kompatiblen Server bereitgestellte Funktion entdecken und nutzen kann. Dieser Server kann die Abrechnungs-API aufrufen, um die eigentlichen Daten abzurufen.
Anders ausgedrückt:
Eine API verbindet Software mit einem Dienst. MCP hilft einer KI-Anwendung, über ein gemeinsames Protokoll mit vielen Diensten zu arbeiten.
Eine direkte API-Integration kann weiterhin schneller und einfacher sein, wenn eine Anwendung nur eine feste Funktion benötigt. MCP wird attraktiver, wenn Entwickler Tools über mehrere KI-Clients hinweg wiederverwenden oder verfügbare Funktionen dynamisch ändern möchten.
Nein. Function Calling ist im Allgemeinen eine Fähigkeit des Modells. Entwickler beschreiben eine oder mehrere Funktionen, und das Modell erzeugt strukturierte Argumente, wenn es entscheidet, dass eine Funktion verwendet werden soll.
MCP ergänzt diesen Prozess. Es kann der Anwendung helfen, Tooldefinitionen von verbundenen Servern zu entdecken, anstatt jedes Tool fest in der Anwendung codieren zu müssen.
Das Modell kann weiterhin auf Function Calling oder Tool Calling zurückgreifen, um ein von MCP bereitgestelltes Tool auszuwählen.
Nein. Retrieval-Augmented Generation (RAG) ist eine Methode, bei der relevante Informationen abgerufen und dem Kontext eines Modells hinzugefügt werden, bevor es antwortet.
Ein MCP-Server könnte ein Tool zur Dokumentensuche bereitstellen, das Teil eines RAG-Systems ist. MCP entscheidet jedoch nicht, wie Dokumente indiziert, Ergebnisse gerankt oder abgerufene Texte einem Prompt hinzugefügt werden.
MCP kann die Anfrage und das Ergebnis übertragen. Das Abrufsystem führt die Suche durch.
MCP kann Tools über kompatible Anwendungen hinweg wiederverwendbarer machen. Außerdem kann eine Anwendung verfügbare Tools und deren erforderliche Eingaben entdecken, anstatt vollständig auf fest codierte Verbindungen angewiesen zu sein.
Einige verbreitete Aussagen gehen jedoch zu weit.
MCP kann nicht:
MCP gewährt einem Modell außerdem keinen uneingeschränkten Zugriff auf jeden verbundenen Dienst. Der Host kontrolliert, welche Server verbunden sind, während die Serverfunktionen und Nutzerberechtigungen bestimmen, was gelesen oder geändert werden kann.
MCP ist eine Überlegung wert, wenn eine Anwendung mit mehreren Tools oder Datenquellen verbunden werden muss, insbesondere wenn diese Funktionen über verschiedene KI-Hosts hinweg wiederverwendet werden sollen.
Typische Situationen sind:
Eine direkte API-Integration kann die bessere Option sein, wenn die Anwendung nur einen eng begrenzten Workflow hat, nur einen Dienst nutzt oder eine präzise Kontrolle auf niedriger Ebene über jede Anfrage benötigt. Das Hinzufügen eines MCP-Servers führt eine weitere Komponente ein, die bereitgestellt, abgesichert, getestet und überwacht werden muss.
MCP reduziert einen Teil der wiederholten Integrationsarbeit. Es beseitigt jedoch nicht die architektonischen Zielkonflikte.
MCP ist nicht automatisch sicher oder unsicher. Die Sicherheit hängt vom Host, vom Server, den zugrunde liegenden Diensten, dem Authentifizierungsprozess und den für die einzelnen Aktionen erteilten Berechtigungen ab.
Ein verbundener Server kann vertrauliche Informationen von der KI-Anwendung erhalten. Ein Tool mit Schreibzugriff könnte außerdem Dateien ändern, Nachrichten versenden, Datensätze erstellen oder andere externe Aktionen auslösen.
Die offizielle MCP-Sicherheitsrichtlinie behandelt Risiken wie Token-Passthrough, serverseitige Request Forgery, Session-Hijacking, kompromittierte lokale Server und Confused-Deputy-Angriffe. Dabei handelt es sich um Implementierungsrisiken und nicht um theoretische Vorteile, die verschwinden, weil ein System ein Standardprotokoll verwendet.
Entwickler sollten mehrere grundlegende Sicherheitsmaßnahmen anwenden:
OpenAI warnt ebenfalls davor, dass benutzerdefinierte MCP-Server Daten empfangen und externe Aktionen ausführen können, und empfiehlt, nur vertrauenswürdige Server zu verbinden. Die aktuelle Implementierung erfordert vor Schreibaktionen in ChatGPT-Unterhaltungen eine Bestätigung. Entwickler sollten jedoch nicht davon ausgehen, dass jeder MCP-Client dieselben Richtlinien anwendet. Die MCP-Dokumentation von OpenAI
Stand Juli 2026 bleibt die neueste stabile MCP-Spezifikation die am 25. November 2025 veröffentlichte Version. Das offizielle Projekt hat erklärt, seitdem keine weitere Spezifikationsversion veröffentlicht zu haben. Die MCP-Roadmap 2026 beschreibt geplante Arbeiten und keine Funktionen, die im stabilen Protokoll bereits garantiert sind.
Die aktuelle Spezifikation definiert zwei standardisierte Übertragungswege:
stdio für die Kommunikation mit lokalen Prozessen.Streamable HTTP hat den älteren HTTP+SSE-Übertragungsweg ersetzt, wobei Clients und Server die Abwärtskompatibilität beibehalten können. Die aktuelle Transportspezifikation enthält außerdem Anforderungen und Empfehlungen zu Authentifizierung, Origin-Validierung, lokaler Netzwerkbindung und Sitzungsverwaltung.
Auch die Governance von MCP hat sich verändert. Im Dezember 2025 wurde das Protokoll zu einem Gründungsprojekt der Agentic AI Foundation der Linux Foundation. Die Foundation berichtete von mehr als 10.000 veröffentlichten MCP-Servern und einer Nutzung in Produkten wie ChatGPT, Claude, Gemini, Microsoft Copilot, Cursor und Visual Studio Code. Ankündigung der Linux Foundation
Die Roadmap für 2026 konzentriert sich auf vier Bereiche: Skalierbarkeit der Übertragung, Agentenkommunikation, Governance und Enterprise-Bereitschaft. Audit-Trails, SSO-integrierte Authentifizierung, Konfigurationsportabilität und Gateway-Verhalten gehören zu den Unternehmensanforderungen, an denen weiterhin gearbeitet wird.
Dieser letzte Punkt ist wichtig. MCP ist über ein Experiment für lokale Entwicklertools hinausgewachsen, doch Teile seines Sicherheits- und Betriebsmodells für Unternehmen befinden sich noch in der Entwicklung.
GPT Proto und MCP gehören zu unterschiedlichen Ebenen einer KI-Anwendung.
MCP verbindet die Anwendung mit externen Tools und Kontext. Die Anwendung benötigt weiterhin ein Modell, das die Anfrage versteht, eine Aktion auswählt und die endgültige Antwort erstellt.
Auf dieses Modell kann über einen Anbieter für Modell-APIs zugegriffen werden. Entwickler, die den GPT Proto-Modellkatalog nutzen, können für diese Inferenzschicht zwischen Text- und Reasoning-Modellen wählen, während MCP-Server die Verbindungen zu externen Systemen verwalten.
Ein vereinfachter Aufbau könnte Folgendes enthalten:
Die beiden Ebenen ergänzen sich. Eine gemeinsame Modell-API kann das Testen oder Austauschen des Modells hinter einer Anwendung erleichtern. MCP kann den wiederholten Aufwand reduzieren, wenn diese Anwendung mit mehreren Tools verbunden wird.
Erstelle Bilder, Videos und mehr mit APIs für den Produktionseinsatz.
Mit dem Erstellen beginnen
Kurzfassung Beste direkte APIs: OpenAI ist die sicherste Standardwahl für allgemeine Anwendungen; Anthropic Claude ist am stärksten bei Programmierung und lang laufenden Agenten; Gemini eignet sich für kostengünstiges multimodales Prototyping, und DeepSeek bietet die niedrigsten Preise pro Text-Token. Beste Multi-Modell-Optionen: OpenRouter ist die naheliegendste Wahl, um viele LLMs zu testen. GPTProto eignet sich besser, wenn ein Produkt Text-, Bild- und Videomodelle unter einem API-Schlüssel und mit einem gemeinsamen Guthaben benötigt. Beste Infrastruktur: Amazon Bedrock passt zu von AWS verwalteten Unternehmensumgebungen, während Replicate, fal.ai und Together AI besser für Open-Modelle oder die Inferenz generativer Medien geeignet sind. Es gibt keinen universellen Sieger. Vergleichen Sie die Eignung für Ihre Workloads, die Modellabdeckung, reale Abrechnungseinheiten, Produktionsfunktionen und Wechselkosten. Preise und Verfügbarkeit wurden am 14. Juli 2026 geprüft. Überprüfen Sie die aktuellen Anbieterseiten vor dem Deployment.
Tiffany Layne | 2026-07-15
Kurzfassung: Kimi K3 ist das leistungsfähigere Coding-Modell, wenn die Aufgabe schwierig, langwierig oder visuell ist. Im von Moonshot veröffentlichten Coding-Vergleich liegt es durchgehend vor GLM-5.2 und akzeptiert über seinen gehosteten Dienst Bilder und Videos. GLM-5.2 bleibt die bessere Standardwahl für alltägliche Repository-Arbeiten: Es kostet deutlich weniger, ist kleiner zu betreiben und nutzt die permissive MIT-Lizenz. Kimi K3 verfügt inzwischen ebenfalls über veröffentlichte Gewichte, doch sein 1,56-TB-Repository, die empfohlene Bereitstellung mit mindestens 64 Beschleunigern und die eigene Lizenz machen Self-Hosting zu einem wesentlich größeren Vorhaben. Wähle Kimi, wenn die Leistungsfähigkeit der Engpass ist; wähle GLM, wenn Kosten und operative Einfachheit täglich wichtig sind. Der interessante Aspekt des GLM-5.2-vs.-Kimi-K3-Codevergleichs ist nicht, dass beide Modelle eine React-Komponente schreiben oder einen kurzen Algorithmus lösen können. Modelle auf diesem Niveau erfüllen diese Anforderungen bereits. Die entscheidende Frage ist, was passiert, wenn die Aufgabe unübersichtlich wird: bei einem Repository-Audit, einer Migration über mehrere Dateien, einem Bug, der nur in einem Screenshot auftritt, oder einem spielbaren Three.js-Prototyp, bei dem mehrere Systeme konsistent zusammenarbeiten müssen. Genau hier beginnt auch der Preisunterschied relevant zu werden. Kimi K3 schneidet bei den schwierigsten öffentlichen Tests besser ab, doch sein offizieller Ausgabepreis liegt mehr als dreimal so hoch wie der von GLM-5.2. Ein Team, das Tausende gewöhnlicher Reviews durchführt, kann mit GLM möglicherweise mehr Arbeit pro Dollar erledigen. Ein Entwickler, der ein schwieriges visuelles Projekt retten muss, zahlt für K3 dagegen möglicherweise gerne.
Tiffany Layne | 2026-07-28
Ich habe viele Menschen dabei beobachtet, wie sie eine wunderschöne KI-Illustration erstellen, begeistert sind und dann ungefähr auf Seite vier still aufgeben. Das erste Bild ist nie das Problem. Das Problem ist, dass Seite vier noch wie derselbe Fuchs aus Seite eins aussieht — und dass jede Seite scharf genug ist, um tatsächlich gedruckt zu werden. Die meisten Websites für „KI-Kinderbuchersteller“ verbergen beide Probleme hinter einer freundlichen Schaltfläche und liefern dir dann ein 1024-Pixel-Bild, das in dem Moment matschig wird, in dem ein Drucker es berührt. Dieser Leitfaden wählt den anderen Weg: eine kleine, wiederholbare API-Pipeline, die du selbst ausführst. Sie richtet sich an Menschen, die programmatische Kontrolle möchten — Stapelverarbeitung, dieselbe Figur über 24–32 Seiten hinweg und Dateien, die Druckspezifikationen erfüllen — und nicht an Nutzer eines Spielzeugs mit nur einem Klick. Wenn du einfach nur ein einzelnes Gute-Nacht-Bild für dein Handy möchtest, ist ein No-Code-Tool tatsächlich schneller, und du solltest eines verwenden. Wenn du ein ganzes Buch produzieren und Kosten sowie Qualität unter Kontrolle halten möchtest, lies weiter. Am Ende hast du einen Workflow, der ein Set von Innenseiten mit Druckauflösung (300 DPI) und konsistenten Figuren sowie ein Cover ausgibt. Dafür werden zwei Modelle über einen einzigen GPTProto API-Schlüssel verwendet, und die Generierungskosten liegen bei ungefähr einem Dollar.
Katherine Lawrence | 2026-06-12
Die Verbindung von GLM-5.2 mit einem Coding-Agenten dauert nur wenige Minuten. Ihm genügend Kontext zu geben, um ein Repository zu reparieren, ohne dass er sich verirrt, ist der schwierigere Teil. Diese Unterscheidung ist wichtig. Ein Modell kann in einem Chatfenster eine saubere Funktion schreiben und trotzdem an einer echten Engineering-Aufgabe scheitern, weil es die falsche Ebene bearbeitet, einen API-Vertrag bricht, die Tests überspringt oder die Hälfte seines Kontexts mit dem Lesen generierter Dateien verbringt. GLM-5.2 ist für längere, toolgestützte Coding-Aufgaben konzipiert, benötigt aber weiterhin einen disziplinierten Agenten-Workflow. Dieser Leitfaden behandelt drei praktische Möglichkeiten: GLM-5.2 mit Claude Code verwenden, die GLM-5.2-API bei GPTProto über einen OpenAI-kompatiblen Agenten aufrufen und die Open Weights lokal ausführen. Anschließend erfahren Sie, wie Sie eine Aufgabe auf Repository-Ebene abgrenzen, den 1M-Token-Kontext verwalten, Änderungen überprüfen und die tatsächlichen Tokenkosten schätzen. Kurzfassung Verwenden Sie Claude Code mit dem Anthropic-kompatiblen Endpunkt von Z.ai, wenn Sie bereits mit diesem Terminal-Agenten arbeiten. Verwenden Sie den OpenAI-kompatiblen Endpunkt von GPTProto für Cline, OpenCode, einen eigenen Agenten oder eine Anwendung, die bereits das OpenAI-SDK nutzt. Senden Sie nicht standardmäßig ein komplettes Monorepo, nur weil GLM-5.2 bis zu 1M Tokens akzeptiert. Beginnen Sie mit einer Repository-Übersicht, den relevanten Dateien, Einschränkungen und Testbefehlen. Verwenden Sie High Reasoning für routinemäßige Untersuchungen und Max für mehrdeutige Aufgaben über mehrere Dateien, bei denen ein falscher Plan teuer wäre. Betrachten Sie die Änderung des Agenten als nicht vertrauenswürdig, bis sie den Build, Linting-, Typprüfungs- und Testprozess des Repositorys erfolgreich durchläuft. Führen Sie das Modell nur lokal aus, wenn Datenschutz, Kontrolle oder eine dauerhafte Nutzung eine ernsthafte Infrastruktur rechtfertigen. “Open Weights” bedeutet nicht “laptopgroß”.
Schuyler Stacy | 2026-07-17
