MCP-Server: Der offene Standard zwischen KI-Hosts und deinen Systemen

Posted on by Christoph Hermanns

Wer KI in ein eigenes System integrieren oder die darin enthaltenen Informationen für ein LLM nutzbar machen will, stößt schnell auf dieselbe Frage: Wie erhält das Modell kontrollierten Zugang zu aktuellen Daten und erlaubten Aktionen? Für einen gemeinsamen, hostübergreifenden Weg bietet MCP dafür einen offenen Standard (Model Context Protocol, 2026a).

Genau deshalb habe ich mich in meinem Projekt ausführlicher mit dem Model Context Protocol beschäftigt. Die Arbeit an einem eigenen MCP-Server ist bereits weit vorangeschritten; mit diesem Artikel hole ich die Dokumentation der Grundlagen nach. Ausgangspunkt meiner Recherche war nicht die Frage, wie man möglichst schnell einen Server implementiert, sondern: Was ist MCP eigentlich, wie funktioniert es – und passt es zu einem Fachsystem?

Der praktische Kern ist schnell beschrieben: Ein Modell kennt nicht automatisch aktuelle Tickets, Berechtigungen, Fachbegriffe oder interne Werkzeuge. Ohne kontrollierten Zugriff bleibt es bei Vermutung, kopiertem Kontext oder einer weiteren Sonderintegration. Vor MCP brauchte jede KI-Anwendung ihre eigene Brücke: der Chat-Client zum Ticketsystem, die IDE zum Dateisystem, das Agentenskript zur REST-API. Lokal konnte das funktionieren. Zusammen wurde daraus ein schwer wartbares Geflecht aus doppelten Toolbeschreibungen, unterschiedlichen Authentifizierungswegen und kaum wiederverwendbaren Sicherheitsentscheidungen. Anthropic beschrieb diese Ausgangslage bei der Veröffentlichung von MCP im November 2024 als Problem fragmentierter Einzelintegrationen zwischen KI-Assistenten und Datenquellen (Anthropic, 2024).

MCP setzt an dieser Stelle an. Die Spezifikation 2026-07-28 beschreibt ein offenes Protokoll, das LLM-Anwendungen mit externen Datenquellen und Tools verbindet: über eine Host-Client-Server-Architektur, JSON-RPC 2.0, einen stateless Protocol Core sowie Bausteine wie Resources, Prompts und Tools (JSON-RPC Working Group, 2013; Model Context Protocol, 2026a; Model Context Protocol, 2026b).

Dieser erste Teil dokumentiert die Grundlagen, die ich für mein Projekt zuerst klären musste – und beantwortet damit die Fragen, die sich am Anfang stellen: Was ist MCP eigentlich? Welches Problem löst es? Und wie funktioniert der Weg von einer Nutzerfrage bis zu den Daten eines Fachsystems? Im zweiten Teil übertrage ich diese Grundlagen auf den MCP-Server meines Projekts und zeige, wie sich daraus eine verantwortbare Oberfläche entwerfen und absichern lässt.

1. Warum MCP?

MCP wird greifbar, wenn man vom praktischen Ausgangspunkt ausgeht: Eine KI-Anwendung soll nicht nur über ein Fachsystem sprechen, sondern bei Bedarf mit dessen aktuellen Daten und erlaubten Funktionen arbeiten. Dafür muss sie wissen, welche Informationen sie anfordern kann, welche Aktionen zulässig sind und unter welchen Grenzen sie stattfinden. Ein KI-Host – also die Anwendung, die Modell, Kontext und MCP-Verbindungen koordiniert – organisiert genau diesen Weg. Damit dieser Weg nicht für jede KI-Anwendung neu gebaut werden muss, braucht es eine gemeinsame Sprache.

1.1 Das konkrete Problem

Das in diesem Artikel verwendete Beispiel ist nicht frei erfunden: Ich nutze das Ticketsystem, das im Rahmen meines Projekts entsteht. Dafür habe ich einen MCP-Server entwickelt, der dieser Artikelreihe ihren praktischen Rahmen gibt. Der Server kann einen KI-Host – etwa einen Chat-Client, eine IDE oder ein Agentenwerkzeug – mit dem Ticketsystem verbinden, dessen Daten und Aktionen nur innerhalb der geltenden Berechtigungen zugänglich sein sollen. Ein Anwender kann im KI-Host beispielsweise folgende Frage stellen und eine Antwort erwarten, die sich auf aktuelle, zugelassene Daten aus dem Ticketsystem stützt: „Welche Risiken, offenen Entscheidungen und nächsten Schritte ergeben sich aus allen Tickets zum Thema Kunden-Onboarding?“

Ohne gemeinsamen Standard braucht jeder Host dafür einen eigenen Sonderweg: ein Chat-Client vielleicht ein Plugin, die IDE eine direkte REST-Integration und ein Agentenskript einen eigenen API-Client. Für Anwender sieht das zunächst ähnlich aus – alle drei können Tickets suchen. Für das Team dahinter bedeutet es jedoch dreimal Toolbeschreibungen, dreimal Eingabeprüfung und oft drei verschiedene Wege für Anmeldung, Berechtigungen und Protokollierung. Ändert sich später etwa das Ticketmodell oder eine Sicherheitsregel, müssen alle Integrationen nachvollziehen, was sich geändert hat. Jede Variante kann lokal funktionieren; zusammen entsteht aber ein schwer wartbares Geflecht, in dem Fachobjekte mehrfach beschrieben werden, Sicherheitsentscheidungen schwer vergleichbar sind und kaum etwas zwischen Hosts wiederverwendbar bleibt.

Hier setzt MCP an: Der Server beschreibt seine Fähigkeiten einmal in einer gemeinsamen, von passenden Hosts lesbaren Form. Ein Host kann zunächst entdecken, was der Server anbietet, und dann kontrolliert entscheiden, was davon für die jeweilige Anfrage genutzt wird. Im Ticket-Beispiel gibt es drei leicht unterscheidbare Angebote: Resources sind lesbare Kontextobjekte, etwa ein einzelnes Ticket; Prompts sind wiederverwendbare Arbeitsvorlagen, etwa für eine Risikoanalyse; Tools führen klar benannte Fachoperationen aus, etwa search_tickets, get_ticket oder list_ticket_comments (Model Context Protocol, 2026b; Model Context Protocol, 2026c; Model Context Protocol, 2026d; Model Context Protocol, 2026e).

Diese gemeinsame Beschreibung ersetzt die drei Sonderintegrationen nicht durch Magie, aber sie vermeidet, dass jeder Host dieselbe fachliche Fähigkeit neu erfinden muss. Wichtig bleibt die Kontrollgrenze: Der Host steuert, welche Angebote er dem Modell zeigt, welche Ergebnisse in den Modellkontext gelangen und welche Aufrufe er zulässt. Wie sichtbar ein Aufruf wird oder wann eine Zustimmung nötig ist, entscheidet die jeweilige Host-Implementierung. Die drei Begriffe werden in Abschnitt 3 noch genauer erklärt.

1.2 Die These dieses Artikels

Im Ticket-Beispiel ersetzt MCP die bestehende Ticket-API nicht. Es legt vielmehr ausgewählte Fähigkeiten des Systems so offen, dass ein KI-Host sie verstehen und kontrolliert verwenden kann. Ein MCP-Server ist damit keine zusätzliche Produkt-API im üblichen Sinn, sondern eine KI-orientierte Integrationsoberfläche.

Sein Zweck besteht nicht darin, möglichst viele Funktionen freizulegen. Er soll Kontext, Prompt-Vorlagen und Tools so zuschneiden, dass ein Host sie nachvollziehbar und begrenzt nutzen kann. Wie Freigaben, Protokollierung oder Audit im Einzelnen funktionieren, bleibt dabei Verantwortung der konkreten Host- und Server-Implementierung.

Daraus folgt eine einfache Architekturregel: Man entwirft einen MCP-Server vom Fachsystem her, nicht vom Sprachmodell. Für das Ticketsystem heißt das: Zuerst klärt man, welche Tickets ein Nutzer sehen darf, welche Aktionen Wirkung haben, welche Eingaben zulässig sind und welche Ergebnisse überhaupt in den Modellkontext gelangen dürfen. Erst aus diesen Grenzen entsteht eine gute Auswahl an Tools und Resources.

1.3 Was MCP nicht ist

Die Abgrenzung ist trocken, aber wichtig: MCP ergänzt bestehende Schichten um einen gemeinsamen Integrationsvertrag. Es ersetzt sie nicht.

MCP ist keine Produkt-API: REST oder GraphQL bleiben oft die primären Schnittstellen eines Systems. MCP bietet einem KI-Host nur ausgewählte Fähigkeiten in einer dafür passenden Form an – etwa „Tickets suchen“, nicht die vollständige öffentliche API des Ticketsystems.

MCP ist kein Agent Framework und keine Workflow Engine: Es plant keine Ziele, entscheidet keine mehrstufigen Strategien und führt keine Geschäftsprozesse als eigene Ablaufmaschine aus. Ob mehrere Tools kombiniert, Rückfragen gestellt oder Arbeitsschritte geplant werden, entscheidet der Host, das Modell oder ein darüberliegendes Agentensystem.

MCP ist keine Datenbank: Resources können Daten als Kontext sichtbar machen, aber sie ersetzen weder Speicherung noch Suche, Transaktionslogik, Datenmodell oder Berechtigungssystem des Zielsystems. Im Beispiel bleiben Tickets also weiterhin Tickets des Fachsystems – auch wenn der Host einzelne davon lesen kann.

MCP ist kein vollständiges Plugin-System: Installation, Distribution, Oberfläche, Berechtigungsdialoge und Produktintegration liegen darüber. Ein Produkt kann MCP für eine Integration nutzen und zusätzlich ein Plugin-Erlebnis darum bauen. OpenAI etwa unterscheidet eigene Connectors von beliebigen Remote-MCP-Servern; das ist jedoch eine OpenAI-spezifische Produktkategorie, nicht Teil der MCP-Spezifikation (OpenAI, 2026a).

Und MCP ist keine KI. Ein MCP-Server muss kein Sprachmodell enthalten. Er stellt Kontext und Fähigkeiten bereit; die Interpretation der Nutzerfrage und die Antwortgenerierung erfolgen im LLM-Kontext des Hosts.

Wichtig: MCP standardisiert den Austausch zwischen Host und Server, nicht die Sicherheit eines Fachsystems. Eine verantwortbare Host-Implementierung muss Freigaben, Datenweitergabe und Kontextaufnahme gestalten. Ein produktiver Server muss Authentifizierung, fachliche Berechtigungen, Datenminimierung und Audit selbst umsetzen. Das Protokoll liefert dafür Grenzen und Empfehlungen, aber keine fertige Sicherheitsarchitektur (Model Context Protocol, 2026a; Model Context Protocol, 2026e; Model Context Protocol, 2026f).

2. Die Architekturkarte

Die folgende Skizze ist der wichtigste Orientierungspunkt für den Rest des Artikels. Sie zeigt bewusst die höhere Ebene: Der Host enthält LLM und MCP-Client und bleibt die Kontrollgrenze zwischen Nutzeranfrage, Modell und Fachsystem.

Vereinfachte MCP-Architektur. Das LLM schlägt innerhalb des Hosts eine Handlung vor; der MCP-Client übermittelt nur den vom Host zugelassenen Aufruf. Ergebnisse kehren zunächst in den Host und damit in dessen Modellkontext zurück.

2.1 Die Rollen

Der Host ist die KI-Anwendung, also etwa ein Chat-Client, eine IDE oder ein Agentenwerkzeug. Er koordiniert Nutzeranfrage, Modellkontext, Toolauswahl, Zustimmungen und Antwortausgabe. Die Spezifikation beschreibt den Host als Container und Koordinator, der Client-Instanzen verwaltet, Sicherheitsregeln und Consent-Anforderungen durchsetzt und Kontext aggregiert (Model Context Protocol, 2026b).

Der MCP-Client lebt im Host. Er vermittelt die Protokollnachrichten zwischen dem Host und genau einem MCP-Server. Ein Host kann mehrere Clients haben, etwa einen für Tickets, einen für Dokumentation und einen für Git.

Der MCP-Server stellt spezialisierte Fähigkeiten bereit. Er macht Resources, Prompts und Tools verfügbar und übersetzt Aufrufe in Fachoperationen gegen das Zielsystem. Ein produktiver Server muss dabei eingehende Anfragen innerhalb seiner eigenen Authentifizierungs-, Berechtigungs- und Fachgrenzen prüfen. Das Zielsystem ist die eigentliche Anwendung: Ticketsystem, Dokumentationsplattform, Datenbank, Monitoring-System oder internes Betriebssystem.

Das LLM formuliert Antworten und kann Toolaufrufe vorschlagen. Es ist aber nicht selbst der MCP-Server und greift nicht direkt auf das Zielsystem zu. Diese Trennung ist der Kern der Architektur.

Eine hilfreiche Analogie ist das Language Server Protocol (LSP). LSP war eine ausdrückliche Inspiration für MCP: nicht als technische Vorstufe oder direkte Erweiterung, sondern wegen seines Integrationsprinzips. LSP hat nicht alle Editoren und Programmiersprachen gleich gemacht, sondern einen gemeinsamen Integrationsvertrag geschaffen: eine festgelegte Sprache dafür, welche Anfragen ein Editor stellen kann und wie ein Sprachserver antwortet. Dadurch müssen Editor und Sprachserver nicht jeweils jedes Gegenüber speziell kennen. MCP überträgt diesen Gedanken auf Kontext und Tools für KI-Anwendungen (Model Context Protocol, 2026a; Microsoft, 2026).

2.2 Der Ablauf einer MCP-Anfrage

Spielen wir Abbildung 1 mit dem Ticket-Beispiel einmal durch. Ein Produktmanager fragt im KI-Host: „Welche Risiken, offenen Entscheidungen und nächsten Schritte ergeben sich aus allen Tickets zum Thema Kunden-Onboarding?“ Für ihn ist das eine normale Frage. Technisch durchläuft sie jedoch eine kontrollierte Kette – keine direkte Leitung vom Modell ins Ticketsystem:

  1. Der Host baut Kontext auf. Er stellt die Informationen zusammen, nach denen das Modell arbeiten soll: die Nutzerfrage, dauerhafte Regeln der Anwendung – etwa Sicherheits- und Formatvorgaben – sowie die ausgewählten MCP-Fähigkeiten. Optional kann er eine vom Server bereitgestellte Prompt-Vorlage abrufen und in den Modellkontext übernehmen. Bis hierhin wurde noch kein Ticket gelesen.
  2. Das LLM schlägt vor, was als Nächstes nötig ist. Reicht der vorhandene Kontext, kann es direkt antworten oder eine Rückfrage formulieren. Braucht es aktuelle oder detailliertere Informationen, kann es einen passenden Toolaufruf vorschlagen – etwa zunächst search_tickets mit { "topic": "Kunden-Onboarding", "limit": 20 }. Verweist ein gefundenes Ticket auf zwei weitere Tickets, kann das LLM nach dem ersten Ergebnis anschließend get_ticket für diese Tickets vorschlagen. Auch ein solcher Vorschlag ist noch keine ausgeführte Fachoperation.
  3. Der Host lässt den Aufruf zu – oder nicht. Seine konkrete Policy entscheidet, welche Tools sichtbar sind, welche Argumente akzeptiert werden und ob der Nutzer eine Freigabe erteilen muss. Wenn der Aufruf zugelassen ist, sendet der MCP-Client ihn als JSON-RPC-Nachricht an den MCP-Server. Das Zielsystem kann dahinter weiterhin REST, Datenbankzugriff oder eine andere interne Schnittstelle verwenden (Model Context Protocol, 2026b; Model Context Protocol, 2026h).
  4. Der Server führt die Fachoperation innerhalb seiner eigenen Grenzen aus. Ein produktiver Ticketserver muss dabei selbst Authentifizierung, Fachberechtigungen, Projektgrenzen und Limits durchsetzen; MCP nimmt ihm diese Verantwortung nicht ab. Er ruft das Zielsystem auf und bereitet das Ergebnis begrenzt und strukturiert für den Host auf.
  5. Der Host entscheidet über die Rückgabe in den Modellkontext. Erst dann kann das LLM die erlaubten Ticketdaten auswerten, bei Bedarf einen weiteren Aufruf vorschlagen oder die Antwort formulieren.

Der zentrale Informationsfluss lautet also: MCP ist kein direkter Tunnel vom Modell ins Ticketsystem. Der Host kontrolliert, welche Modellvorschläge zu MCP-Aufrufen werden; der Server setzt die fachlichen und sicherheitlichen Grenzen gegenüber dem Zielsystem durch. Beide Seiten müssen ihre Verantwortung konkret implementieren.

2.3 Die wichtige Versionierungsnuance

Dieser Artikel bezieht sich auf die MCP-Spezifikation 2026-07-28. Diese Revision beschreibt MCP als stateless, also ohne verbindungsgebundenen Protokollzustand: Jede Anfrage bringt ihre Protokollinformationen selbst mit. Ältere Clients und Server können dagegen noch das frühere, sessionbasierte Protokoll verwenden. An der Architektur aus Abbildung 1 ändert das nichts; die Details für produktive Remote-Server gehören in Teil 2 (Model Context Protocol, 2026b; Model Context Protocol, 2026g; Model Context Protocol, 2026h).

3. Was durch den MCP-Server fließt

Ein MCP-Server liefert nicht einfach “Daten an die KI”. Er bietet dem Host mehrere klar getrennte Dinge an.

Für diesen Grundlagenartikel reichen fünf Leitfragen: Wie findet der Host heraus, was ein Server kann? Welche Datenobjekte kann er als Kontext lesen? Welche Arbeitsanweisungen kann er als Prompt-Vorlagen übernehmen? Welche Funktionen kann er als Tools ausführen lassen? Und über welchen Transport sprechen Client und Server miteinander?

In MCP heißen diese Bausteine Discovery, Resources, Prompts, Tools und Transport. Die Begriffe wirken zunächst ähnlich, markieren aber unterschiedliche Stellen im Informationsfluss aus Abbildung 1.

3.1 Discovery und Fähigkeitsabgleich

Bevor ein Host eine Fähigkeit sinnvoll verwenden kann, muss er wissen, welche Angebote ein Server macht. Dieser Fähigkeitsabgleich passiert in der aktuellen Spezifikation nicht als verbindungsgebundener Startdialog, sondern pro Anfrage: Clients übermitteln ihre Protokollversion, Client-Informationen und Fähigkeiten als Metadaten jeder Anfrage. Mit server/discover können sie außerdem vorab die unterstützten Protokollversionen, Fähigkeiten und Serverinformationen abfragen (Model Context Protocol, 2026b).

Im Ticket-Beispiel kann der Server also sichtbar machen, dass er Kontextobjekte, Prompt-Vorlagen und ausführbare Werkzeuge unterstützt. Der konkrete Toolbestand kann vom Autorisierungskontext abhängen: Ein Produktmanager sieht vielleicht search_tickets und list_ticket_comments, aber kein administratives Exporttool. Die Spezifikation erlaubt ausdrücklich, dass die zurückgelieferte Tool- oder Resource-Liste von den Credentials der Anfrage abhängt, solange sie nicht versteckt vom Zustand einer Verbindung abhängt (Model Context Protocol, 2026c; Model Context Protocol, 2026e).

Discovery ersetzt keine Berechtigungsprüfung. Sie verhindert nur falsche Erwartungen. Der Server muss jeden späteren Aufruf weiterhin serverseitig prüfen.

3.2 Resources: Kontextobjekte

Resources sind Kontextobjekte. Die Spezifikation beschreibt sie als standardisierten Weg, Daten für Clients bereitzustellen, etwa Dateien, Datenbankschemata oder anwendungsspezifische Informationen. Jede Resource wird über eine URI identifiziert. Clients können Resources auflisten und lesen; wenn der Server es unterstützt, können sie außerdem Änderungsbenachrichtigungen für Resources erhalten (Model Context Protocol, 2026c).

Im Ticket-Beispiel könnte ein einzelnes Ticket als ticket://ONB-123 erscheinen. Diese Resource ist noch keine automatische Modellwahrheit. Der Host entscheidet, ob er sie dem Anwender zur Auswahl anbietet, aufgrund einer Suche lädt oder als Kontext in die Modellkonversation einfügt. Genau diese Trennung ist wichtig: Eine Resource macht Kontext auffindbar und referenzierbar, aber sie zwingt den Host nicht, alles ungefiltert ins Modell zu kippen.

Gute Resources sind eng und verständlich. Ein Ticketobjekt mit Titel, Status, Zuständigkeit, Kurzbeschreibung und Link ist meist hilfreicher als ein undifferenzierter Datenbankdump. Je besser die Resource geschnitten ist, desto leichter kann der Host mit Datenminimierung, Quellenanzeige und Nutzerkontrolle arbeiten.

3.3 Prompts: Arbeitsanweisungen, keine Ausführung

Prompts sind wiederverwendbare, parametrisierbare Arbeitsanweisungen. Inhaltlich kann eine solche Vorlage ein ganz normaler Prompt sein, den auch ein Mensch formulieren könnte. Die Spezifikation beschreibt sie als Prompt Templates, die Server für Clients bereitstellen; Hosts können sie zum Beispiel als auswählbare Aktionen in ihrer Oberfläche anbieten (Model Context Protocol, 2026d).

Im Ticket-Beispiel könnte der MCP-Server einen Prompt analyze_onboarding_tickets anbieten: „Analysiere Tickets zum Thema {topic}. Gruppiere die Erkenntnisse nach Risiken, offenen Entscheidungen und nächsten Schritten. Nenne Quellen pro Aussage.“ Als MCP-Prompt ist diese Arbeitsanweisung nicht nur kopierbarer Text: Sie hat einen stabilen Namen, beschreibt erwartete Parameter wie topic oder output_style und kann vom Host entdeckt werden. So können Chat-Client, IDE und Agentenwerkzeug dieselbe fachlich gepflegte Vorlage verwenden, statt jeweils eigene Varianten mitzuführen.

Wenn der Host die Vorlage verwendet, ruft er sie beim Server ab, füllt ihre Parameter und übernimmt die daraus entstehenden Nachrichten bei Bedarf in den Modellkontext. Die Vorlage kann statisch sein oder sich anhand ihrer Parameter und des Berechtigungskontexts verändern. Sie startet aber keine Analyse: Der MCP-Server hat bis dahin keine Tickets gelesen, keine Schlussfolgerungen gezogen und keine Antwort formuliert.

Das ist mehr als ein Implementierungsdetail. Ein Prompt-Parameter konfiguriert eine Arbeitsanweisung; Argumente eines Toolaufrufs wie search_tickets bestimmen dagegen eine serverseitige Fachoperation. Diese Trennung verhindert die Verwechslung von Prompts und Tools.

Eine Prompt-Vorlage ordnet jedoch keine Tools technisch zu. Der Host macht die nach seiner Policy zugelassenen Tools sichtbar; das LLM entscheidet anhand der Arbeitsanweisung, welche davon es vorschlägt. Der Host prüft anschließend jeden konkreten Toolvorschlag.

3.4 Tools: ausführbare Fachfähigkeiten

Tools sind ausführbare Funktionen. Sie können Datenbanken abfragen, APIs aufrufen, Berechnungen ausführen oder Fachaktionen vorbereiten. Die Spezifikation beschreibt Tools als modellkontrolliert: Das Modell kann verfügbare Tools entdecken und aufgrund des Kontexts aufrufen. Zugleich betont sie, dass Anwendungen Toolaufrufe sichtbar machen und für relevante Operationen eine menschliche Ablehnung oder Bestätigung ermöglichen sollten (Model Context Protocol, 2026e).

Für den Host sind Tools zunächst eine Liste beschriebener Fähigkeiten: Name, Zweck und erwartete Parameter sagen ihm und dem LLM, was ein Tool leisten kann. Der Host macht nur die nach seiner Policy zulässigen Tools sichtbar. Das LLM vergleicht Nutzerfrage, bisherigen Kontext und diese Beschreibungen und schlägt das passende Tool mit konkreten Argumenten vor. Für eine Ticketanalyse könnte es zuerst search_tickets wählen, anschließend mit get_ticket Details nachladen und bei Bedarf list_ticket_comments vorschlagen. Die Auswahl ist damit eine Modellentscheidung auf Grundlage klarer Toolbeschreibungen – die Ausführung bleibt trotzdem bei Host und Server.

Im Ticket-Beispiel sind search_tickets, get_ticket und list_ticket_comments gute Starttools. Sie sind fachlich benannt, lesend, begrenzt und leicht erklärbar. Ein generisches query_database wäre deutlich riskanter: Es verschiebt zu viel Semantik in einen freien Query-String und macht Berechtigungsmodell, Eingabeprüfung und Audit schwerer.

Für ein erstes produktives Setup sollte der Ticketserver deshalb bei eng beschriebenen Lese-Tools beginnen. Das ist keine harte MCP-Reihenfolge, sondern eine abgeleitete Sicherheitsentscheidung. Die MCP-Spezifikation betont Sichtbarkeit und menschliche Ablehnung oder Bestätigung bei Toolaufrufen. OpenAI formuliert für Plugin- und API-Integrationskontexte außerdem Anforderungen an klare Tooldefinitionen, korrekte Annotationen, möglichst datenarme Eingaben und serverseitige Autorisierung für jeden Request (Model Context Protocol, 2026e; OpenAI, 2026b; OpenAI, 2026c).

Praktisch heißt das: Ein späteres Tool add_internal_comment kann vertretbar sein, wenn es einen eigenen Write-Scope, Projektbindung, maximale Länge, interne Sichtbarkeit, strukturierte Fehler, korrekte Read-only-/Destructive-Annotationen und Audit ohne Volltext hat. Ein Tool change_ticket_status ist riskanter, weil es Workflow-Wirkung hat. Dafür braucht es mindestens eine konkrete Vorschau, eine ausdrückliche Freigabe, Retry-Sicherheit oder erkennbare Nicht-Idempotenz und Audit-Korrelation (OpenAI, 2026b; OpenAI, 2026c).

3.5 Transport: Wie Host und Server Nachrichten austauschen

Resources, Prompts und Tools beschreiben, was ein MCP-Server anbietet. Der Transport beantwortet die andere, einfachere Frage: Auf welchem Weg gelangen die Protokollnachrichten zwischen Host und Server? Er ändert weder die Rollen aus Abbildung 1 noch die fachliche Verantwortung; er ist nur der technische Übertragungsweg.

Die Spezifikation 2026-07-28 nennt dafür zwei Standardwege. Bei stdio startet der Host den MCP-Server als lokalen Prozess und tauscht Nachrichten über dessen Standard-Ein- und -Ausgabe aus. Das passt gut zu lokalen Entwicklerwerkzeugen, etwa für Dateien, Git oder Builds. Bei Streamable HTTP läuft der MCP-Server als erreichbarer Dienst; Host und Server sprechen über eine Webverbindung miteinander. Das passt eher zu SaaS-Diensten, Unternehmensanwendungen und anderen entfernten Systemen (Model Context Protocol, 2026h).

Für das Grundverständnis genügt diese Unterscheidung: stdio ist typischerweise lokal und prozessnah, Streamable HTTP typischerweise remote und netzwerkbasiert. Die genaue Übertragungstechnik sowie die Betriebsanforderungen eines produktiven Remote-Servers – etwa HTTPS, Authentifizierung, Rate Limits und Monitoring – gehören in Teil 2.

Kurzes Fazit und Ausblick

Bis hierhin ging es um das Verständnis der Architektur: Wer spricht mit wem, wann kommen Daten in den Modellkontext, und warum ist MCP kein direkter Tunnel vom Modell ins Zielsystem? Die zentrale Erkenntnis lautet: Der Wert eines MCP-Servers entsteht nicht nur aus Tools, sondern aus der kontrollierten Strecke zwischen KI-Host und Fachsystem.

Teil 2 fragt deshalb nicht nur, wie man Tools programmiert. Er zeigt, wie aus einer vorhandenen Fach-API eine verantwortbare MCP-Oberfläche wird: Welche Fähigkeit wird zu einem Tool, welche Information zu einer Resource – und wie verhindert man, dass ein hilfreicher Assistent unkontrolliert zu weitreichenden Aktionen kommt?

Quellenverzeichnis

Externe Primärquellen

Grundlagen und Einordnung

Category: AI, Data & Automation

Leave a Reply

Your email address will not be published. Required fields are marked *