Was ist MCP in KI? Model Context Protocol erklärt

Warum AI externe Verbindungen benötigt

Ein AI-Assistent kann Code erklären oder eine Besprechungsagenda entwerfen. Fordere ihn auf, ein Live-Repository-Problem zu überprüfen oder die privaten Dateien hinter diesem Problem zu inspizieren, und eine Lücke wird sichtbar. Das Gleiche passiert mit deinem Kalender oder einer internen Wissensdatenbank. Das Modell kann die Informationen möglicherweise interpretieren, aber die Anwendung benötigt immer noch eine kontrollierte Möglichkeit, sie abzurufen.

Entwickler bauen diese Verbindungen traditionell einzeln auf. Ein Assistent erhält eine Repository-Integration. Ein anderer benötigt einen Kalender-Connector, während ein dritter das gleiche Problem-Tracking-System über eine andere Schnittstelle erreicht. Mit der Vermehrung von AI-Anwendungen und externen Systemen wachsen auch ihre Integrationen. Jede Verbindung bringt Authentifizierungs- und Berechtigungsentscheidungen mit sich, gefolgt von laufender Wartung und Datenbehandlungsverantwortung. Im großen Maßstab werden einmalige Verbindungen zu wiederholter Ingenieurarbeit.

Das fehlende Element ist nicht ein intelligenteres Modell. Es ist eine wiederverwendbare Verbindungsgrenze zwischen AI-Anwendungen und externem Kontext oder Aktionen. Diese Anleitung lokalisiert diese Grenze und verfolgt eine Anfrage durch sie hindurch. Sie trennt dann benachbarte Konzepte und hilft dir, ihre Eignung zu beurteilen.

Was MCP ist und warum es existiert

Model Context Protocol (MCP) ist ein offener Standard, der kompatiblen AI-Anwendungen eine konsistente Möglichkeit bietet, sich mit externen Systemen zu verbinden, die Daten, Tools und wiederverwendbare Workflows bereitstellen. Dies wiederholt die offizielle Einführung. „Offener Standard” bedeutet, dass Anbieter gemeinsame öffentliche Regeln implementieren können, anstatt ein proprietäres Connector-Format eines Produkts zu verwenden. In der Praxis kann eine Funktion, die über MCP veröffentlicht wird, mehreren kompatiblen Hosts dienen, abhängig von dem, was jeder Host unterstützt und zulässt.

Die häufige Analogie ist „USB-C für AI-Anwendungen”. Anstatt für jede Paarung einen anderen Stecker zu erfinden, können Produkte einen gemeinsamen Verbindungsstandard implementieren. Die Grenze ist genauso wichtig wie die Analogie. Kompatibilität beweist nicht, dass ein System sicher, autorisiert oder von hoher Qualität ist. Es bedeutet auch nicht, dass jeder Host die gleichen Funktionen unterstützt.

Anthropic stellte MCP am 25. November 2024 vor und trug es dann im Dezember 2025 zur Agentic AI Foundation der Linux Foundation bei. Es ist jetzt ein offen verwaltetes, herstellerübergreifendes Projekt und keine proprietäre Funktion nur von Anthropic. Die Unterstützung ist weit verbreitet in großen AI-Anwendungen und Entwicklertools, obwohl die Implementierung und das Genehmigungsverhalten unterschiedlich sind.

MCP-Architektur: Hosts, Clients und Server

Der MCP-Host ist die benutzergerichtete KI-Anwendung. Er koordiniert die Schnittstelle, das Modell und die Verbindungen zu externen Systemen. Die Host-Richtlinie bestimmt, welche Funktionen angezeigt werden und wann eine Genehmigung erforderlich ist. Der Host gibt auch Ergebnisse an den Benutzer zurück. Das Modell läuft darin; es verbindet sich normalerweise nicht direkt mit externen Systemen.

Ein MCP-Client ist die protokollsprechende Komponente, die der Host für eine Serververbindung erstellt oder verwaltet. Es gibt einen Client pro verbundenem Server. Die Produktschnittstelle kann ihn verbergen, aber Client und Host bleiben unterschiedlich. Separate Clients halten Verbindungen und verfügbar gemachte Funktionen unter Kontrolle des Hosts.

Ein MCP-Server ist ein Programm, das Funktionen über MCP verfügbar macht – keine Hardwareklasse. Derselbe Server könnte auf einem Laptop laufen und mit ausgewählten lokalen Dateien unter dem Benutzerkonto arbeiten. Führen Sie ihn als Remote-Service aus, und Netzwerkidentität und Verfügbarkeit werden zu betrieblichen Belangen. Seine MCP-Rolle bleibt an beiden Standorten gleich.

Server stellen drei Hauptfunktionstypen zur Verfügung. Ein Tool ist eine Operation, wie das Abrufen eines Problems oder das Erstellen eines Kalendereintrags. Eine Ressource ist lesbarer Kontext, wie eine Datei, ein Datensatz oder ein Schema. Ein Prompt ist eine wiederverwendbare Interaktionsvorlage, wie ein Incident-Review-Prompt.

User request
     ↓
┌─ MCP host: AI application ───────────────────────────┐
│ Interface + model + policy/approval + result handling│
│                                                     │
│ ├─ MCP client A ────────────────────────────────────┼─⇄ Local MCP server
│ └─ MCP client B ────────────────────────────────────┼─⇄ Remote MCP server
└─────────────────────────────────────────────────────┘          │
                                                                 ├─ each exposes tools / resources / prompts
                                                                 ├─ local server ⇄ local files or application
                                                                 └─ remote server ⇄ external API, database, or service

Request/action travels →        Result/context returns ←

Die offizielle Architekturübersicht geht tiefer. Ein Server kann sich vor einer bestehenden API oder Datenbank befinden. Er kann auch Zugriff auf eine Befehlszeilenschnittstelle, ein Dateisystem oder einen Business-Service verfügbar machen. MCP standardisiert Verfügbarmachung und Austausch; das zugrunde liegende System speichert Daten oder führt die Aktion aus.

In Service-Desk-Begriffen koordiniert der Host den Besuch. Jeder Client ist ein protokollsprechender Sachbearbeiter, der einem Schalter zugewiesen ist, während jeder Server ein Funktionsmenü veröffentlicht. Dieses Menü zeigt Verfügbarkeit, nicht Sicherheit.

Wie eine MCP-Anfrage funktioniert

Stellen Sie sich diese Architektur in Aktion vor. Ein Entwickler bittet einen Coding-Assistenten, ein Problem und relevante Repository-Dateien zu überprüfen und die wahrscheinliche Ursache zu erklären. Die Aufgabe ist schreibgeschützt: untersuchen, aber nicht bearbeiten, committen, mergen oder bereitstellen.

Ein typischer konzeptioneller Ablauf hat sechs Stufen:

1. Der Host verbindet sich. Der Assistent ist so konfiguriert, dass er über seine MCP-Clients auf die Problem- und Repository-Server zugreift.
2. Der Host erkennt und filtert Funktionen. Clients erfahren, was ihre Server bieten; der Host begrenzt die Menge durch Konfiguration, Relevanz und Berechtigung.
3. Der Benutzer stellt die Frage. Der Host gibt dem Modell die Anfrage, verfügbaren Kontext und nur die relevanten Funktionsbeschreibungen.
4. Das Modell schlägt einen Vorgang vor. Es wählt ein geeignetes Lese-Tool aus. Der Host wendet Richtlinien an und fordert bei Bedarf Genehmigung an; das Verhalten variiert je nach Host und Konfiguration.
5. Der Server führt die Arbeit aus. Er ruft den Issue-Tracker, die Repository-Schnittstelle oder API auf und gibt strukturierte Ergebnisse über den Client zurück.
6. Das Modell interpretiert die Ergebnisse. Der Host fügt die zurückgegebenen Informationen zum Modellkontext hinzu, und das Modell erklärt sie dem Benutzer.

Hier bedeutet Funktionserkennung, dass der Client erfährt, was ein Server derzeit bietet, anstatt sich auf ein in der Anwendung hardcodiertes Menü zu verlassen. Der Anbieter kann dieses Menü weiterentwickeln, ohne es separat in jedem Host neu zu definieren.

Wie das Diagramm zeigt, verläuft die Anfrage vom Host zum Client, Server und zum zugrunde liegenden System. Die Ergebnisse kehren denselben Weg zurück, bevor das Modell sie verwendet.

Ein kleiner, aufgabenspezifischer Funktionssatz ist oft besser als der vollständige Katalog. Begrenzte Exposition begrenzt unnötige Privilegien. Weniger Beschreibungen reduzieren auch die Token-Nutzung, Kosten und Latenz, während die Werkzeugauswahl weniger verwirrend wird. Die Erkennung bietet Optionen; der Host entscheidet, welche in die Interaktion eingehen.

MCP, APIs, Function Calling, Agents und RAG

MCP, APIs, Function Calling, Agents und Retrieval-Augmented Generation (RAG) werden oft als Konkurrenten dargestellt. Sie lösen unterschiedliche Probleme und arbeiten regelmäßig zusammen.

Die geschichtete Kette kann so aussehen: zugrunde liegender Service/API → MCP Server → MCP Client/Host → Modell-Tool-Auswahl → optionale Agent-Schleife.

Im Repository-Beispiel stellt eine API die Daten bereit, und ein MCP Server macht eine begrenzte Leseoperation verfügbar. Function Calling ermöglicht es dem Modell, diese Operation vorzuschlagen. Eine optionale Agent-Schleife kann genehmigte Lesevorgänge wiederholen. Der Service behält seine bestehende Schnittstelle bei, während kompatible Hosts einen Standard-Weg gewinnen, um die Operation zu entdecken.

„Connector” und „Plugin” sind Produktbezeichnungen, keine MCP-Synonyme. Beide können MCP oder eine proprietäre Integration verwenden; der Name allein offenbart nicht das Protokoll.

Praktische MCP-Anwendungsfälle

MCP-Anwendungsfälle haben zwei praktische Formen. Kontext- und Lesevorgänge sammeln Belege, ohne die Quelle zu ändern. Folgenreiche Aktionen erzeugen eine externe Wirkung, wie das Aktualisieren von Daten oder das Versenden einer Nachricht. MCP kann beide bereitstellen; der Sicherheitsabschnitt erläutert die strengeren Kontrollen, die für die zweite Gruppe erforderlich sind.

Die sichersten ersten Projekte sind daher eng und lesintensiv:

Entwicklungsteams können einen Editor, eine Chat-Schnittstelle und ein Review-Tool gegen dieselben Repositories und Probleme verwenden. Eine gemeinsame Funktion gibt jedem Host denselben scoped Beleg, was die Einrichtungsarbeit vor Beginn einer Untersuchung reduziert.

Für Business-Teams liegt der unmittelbare Wert in einer schnelleren Vorbereitung. Genehmigter Wissensdatenbank- oder CRM-Kontext kann einen Antwortsentwurf oder eine Meeting-Zusammenfassung unterstützen, sodass Mitarbeiter weniger Zeit für die Sammlung von Hintergrundinformationen vor der Überprüfung aufwenden.

Self-Hoster können das gleiche Muster verwenden, um private Dateien und Home-Lab-Dienste zu überprüfen, ohne zwischen mehreren Schnittstellen zu wechseln. Cloud- und IT-Teams können Logs, Metriken und Runbooks in eine Untersuchung einbringen, was die Korrelation von Incident-Belegen erleichtert.

In allen vier Reihen hat ein nützliches erstes Projekt eine benannte Quelle, eine klare Aufgabe und ein beobachtbares Ergebnis. Das macht seinen Wert leichter zu beurteilen, bevor der Umfang wächst.

Lokales vs. Remote MCP

Ein MCP-Server ist eine Softwarerolle, die an zwei häufigen Orten existieren kann. Ein lokaler Server ist ein Prozess, den der Host startet oder über stdio erreicht, was direkte Standard-Ein-/Ausgabe zwischen lokalen Prozessen bedeutet. Er befindet sich in der Nähe lokaler Dateien und Anwendungen, bedient oft einen Client und kann mit den Berechtigungen des Benutzers ausgeführt werden.

Ein Remote-Server ist ein kontinuierlich erreichbarer Service, auf den über HTTPS mit MCPs Remote-Transport (derzeit Streamable HTTP) zugegriffen wird. Er kann einen oder viele kompatible Hosts bedienen. “Remote” bedeutet erreichbar durch seine beabsichtigten Netzwerk-Clients, nicht unbedingt dem öffentlichen Internet ausgesetzt.

Local:  AI host → stdio → local MCP process → scoped local files/app
                        [same-machine trust boundary]

Remote: AI host → HTTPS → remote MCP service → API/database/business system
                        [network + identity trust boundary]

Das Ausführen von MCP remote schafft gewöhnliche Service-Verantwortungen. Zugriff und Geheimnisse benötigen Schutz, während Protokolle und Überwachung das Verhalten sichtbar machen. Patching, Verfügbarkeit und Netzwerkgrenzen werden ebenfalls zu Betriebsanliegen. Der nächste Abschnitt behandelt diese Kontrollen vollständig.

Ein Standard-AlexHost VPS kann für einen kleinen, immer aktiven Remote-MCP-Service oder Gateway geeignet sein. AlexHost AI-Hosting ist nur relevant, wenn selbstgehostete Modell-Inferenz eine separate, rechenintensive Arbeitslast ist. MCP selbst benötigt keine GPU.

MCP-Sicherheit und Vertrauen

Kompatibilität wird zur Sicherheitsfrage, wenn Daten und Aktionen die Grenze überschreiten. Ein Server kann ausgewählte Daten empfangen oder Tools bereitstellen, die externe Aktionen auslösen. Der Name und die Beschreibung eines Tools sind Softwareansprüche, kein Beweis für sicheres Verhalten. Die gleiche Vorsicht gilt für seine Anmerkungen.

Die Platzierung ändert das Risiko. Ein lokaler Server ist ausführbarer Code, der möglicherweise den Datei- und Netzwerkzugriff des Benutzers erbt. Ein Remote-Server empfängt Daten über ein Netzwerk, daher sind seine Identität und Autorisierungskontrollen wichtig. Die Verbindung hängt auch vom Transportschutz und dem Vertrauen in den Betreiber ab.

⚠️ Warnung: Verbindungskompatibilität ist kein Vertrauenszertifikat. Wie bei USB-C entscheidet Interoperabilität nicht darüber, ob eine Komponente Ihre Daten oder Berechtigungen erhalten sollte.

Verwenden Sie diese sechsteilige Grundlage:

1. Wählen Sie bewusst. Bevorzugen Sie offizielle, überprüfte oder intern kontrollierte Server. Überprüfen Sie den genauen Befehl und das Paket vor dem Ausführen von lokalem Code.
2. Halten Sie die Exposition eng. Erlauben Sie nur notwendige Server, Funktionen, Verzeichnisse, Datensätze und Tools. Beginnen Sie schreibgeschützt und wenden Sie das Prinzip der geringsten Berechtigung an – den minimalen erforderlichen Zugriff.
3. Kontrollieren Sie folgenreiche Aktionen. Erfordern Sie explizite Genehmigung oder eine strikte Richtlinie für Senden, Löschen, Zahlen, Bereitstellen, Berechtigungsänderungen und ähnliche Operationen.
4. Schützen Sie Remote-Zugriff. Verwenden Sie angemessene Authentifizierung und Autorisierung, HTTPS, begrenzte Anmeldedaten und sorgfältige Geheimnisbehandlung.
5. Isolieren Sie lokale Prozesse. Sandbox sie, wo praktisch, besonders wenn sie keinen breiten Dateisystem- oder Netzwerkzugriff benötigen.
6. Behalten Sie nützliche Protokolle. Zeichnen Sie Verbindungen, Datenaustausch, Tool-Aufrufe, Genehmigungen, Fehler und Ergebnisse zur Prüfung auf.

Ein Register unterstützt die Erkennung, eine Open-Source-Lizenz ermöglicht die Überprüfung, und eine gültige Implementierung stellt Kompatibilität her. Keine allein garantiert Sicherheit. Die offizielle MCP-Sicherheitsleitlinie geht tiefer für Implementierer.

Sicherheit bleibt geteilt. Der Host kontrolliert die Exposition, und der Server setzt seine Grenzen durch. Der Betreiber schützt die Bereitstellung und Anmeldedaten, während das zugrunde liegende System jede Anfrage autorisiert.

Wann MCP verwendet werden sollte

MCP rechtfertigt seine zusätzliche Grenze, wenn unabhängig bereitgestellte Funktionen über kompatible Hosts hinweg wiederverwendet werden müssen. Runtime-Erkennung kann auch wichtig sein, wenn sich diese Funktionen im Laufe der Zeit ändern. Eine gemeinsame Grenze kann dann die Governance konsistent halten, während sich die Funktionalität und der Host separat weiterentwickeln.

Wenn eine Anwendung nur eine kleine, stabile Integration benötigt, kann ein direkter API-Aufruf oder eine anwendungseigene Funktion einfacher sein. Wenn der Code die Operationsreihenfolge bereits kennt, verwenden Sie einen deterministischen Workflow: eine vordefinierte Sequenz, die Vorhersagbarkeit und Nachvollziehbarkeit gegenüber modellgesteuerten Schritten bevorzugt.

Verwenden Sie diese sechs Fragen als praktischen Filter:

1. Werden mehr als ein kompatible AI-Host die Funktionalität wiederverwenden? Falls nein, kann eine direkte Integration ausreichen.
2. Muss sich die Funktionalität unabhängig vom Host weiterentwickeln oder dynamisch erkannt werden? Falls nein, können anwendungseigene Funktionen einfacher sein.
3. Sollte ein Modell zwischen Operationen wählen, oder ist die Sequenz bereits bekannt? Bekannte Sequenzen bevorzugen deterministischen Code.
4. Kann das Team diese Grenze steuern? Falls nein, fügen Sie noch keine bedeutsamen MCP-Tools hinzu; wenden Sie zunächst die Kontrollen aus dem Sicherheitsabschnitt an.
5. Rechtfertigen zusätzliche Latenz, Fehler bei der Funktionsauswahl und Service-Operationen die Wiederverwendung? Falls nein, halten Sie die Grenze kleiner.
6. Unterstützen Ziel-Hosts die Primitiven und das Genehmigungsverhalten, das das Projekt benötigt? Falls unsicher, überprüfen Sie die Kompatibilität, bevor Sie sich auf MCP standardisieren.

Ein „Ja” zur dynamischen Erkennung ist kein Grund, den vollständigen Katalog freizulegen. Zu viele Beschreibungen verbrauchen Token, erhöhen Kosten und Latenz und machen die Auswahl weniger zuverlässig. Mehr Tools garantieren keine bessere Anwendung.

Beginnen Sie mit der einfachsten Integration, die funktioniert. Wählen Sie MCP nur, wenn die Checkliste einen klaren Vorteil gegenüber einer direkten Integration zeigt.

Fazit

Zurück zum Assistenten vom Anfang. MCP hat die Reasoning-Fähigkeit des Modells nicht verändert. Es gab dem Host eine definierte Möglichkeit, ausgewählten externen Kontext abzurufen.

Das mentale Modell ist einfach: Der Server stellt bereit; der Client verbindet sich; der Host kontrolliert; das zugrunde liegende System führt die Arbeit aus. MCP ist eine Verbindungsschicht innerhalb eines größeren AI-Stacks.

Bevor Sie MCP einführen, identifizieren Sie eine enge, schreibgeschützte Fähigkeit, von der mehr als ein AI-Host profitieren würde. Wenn Sie keine benennen können, beginnen Sie stattdessen mit einer direkten Integration.