Was ist MCP? Wie verbindet das Model Context Protocol AI Agent, Tools, API und JSON Schema?

MCP definiert drei Server-Primitiven: Prompts, Resources und Tools. Daraus folgt die wichtigste Entscheidung für Ihre Architektur: MCP ist ein offenes Protokoll zwischen AI-Anwendung und externen Systemen, aber weder ein Modell noch ein Ersatz für Function Calling. Der Client entdeckt die vom MCP Server veröffentlichten Tool-Schemas, das Modell wählt ein passendes Werkzeug, und die Host-Anwendung steuert die tatsächliche Ausführung sowie die Rückgabe des strukturierten Ergebnisses. (Offizielle MCP-Übersicht)

Symptom: Ihr Agent kennt Ihre API, weiß aber nicht zuverlässig, welches Werkzeug mit welchen Parametern aufgerufen werden darf.
Schnellste Lösung: Trennen Sie Host, Client, Server und API sauber, veröffentlichen Sie jedes Tool mit präzisem JSON Schema und erzwingen Sie Validierung, Berechtigungen und Timeouts außerhalb des Modells.

Für wen diese MCP-Erklärung gedacht ist

Diese Anleitung richtet sich an Entwickler, die einen MCP Server für interne Werkzeuge oder Geschäftssysteme bauen. Sie ist ebenso für Plattformingenieure gedacht, die mehrere AI-Anwendungen und Modelle über eine gemeinsame Schnittstelle anbinden möchten.

Auch Sicherheits- und Betriebsteams profitieren davon: Sie erhalten eine zeitliche Prüfkette für Authentifizierung, Freigaben, Audit-Logs, Remote-Bereitstellung und die Frage, wann ein lokaler Prozess genügt oder ein dauerhaft erreichbarer Dienst erforderlich ist.

Die Rollen vor dem ersten Netzwerkpaket

Viele Fehlentscheidungen entstehen, weil „MCP“ als direkte Modell-API verstanden wird. In einer belastbaren Implementierung gibt es mindestens vier getrennte Verantwortungsbereiche:

• Host: Die AI-Anwendung oder Plattform. Sie verwaltet Benutzerkontext, mehrere Verbindungen, Freigaben, Lebenszyklus und Sicherheitsrichtlinien.
• MCP Client: Eine vom Host verwaltete Verbindung zu genau einem Server. Der Client übernimmt Protokollnachrichten, Capability Negotiation, Tool-Auflistung und Aufrufe.
• MCP Server: Ein lokaler Prozess oder ein Remote-Dienst, der Tools, Ressourcen und Prompts anbietet.
• API oder Zielsystem: Die interne REST-API, Datenbank, Build-Pipeline, Dateioperation oder Automatisierung, die tatsächlich verändert oder abgefragt wird.

Die offizielle Architektur beschreibt eine 1:1-Beziehung zwischen einem Client und einem Server. Ein Host kann jedoch mehrere Clients verwalten und dadurch mehrere Server isoliert miteinander verbinden. Ein Server soll nicht automatisch den vollständigen Gesprächsverlauf oder die Daten anderer Server sehen. Diese Grenze ist für interne Systeme wichtiger als die oft verwendete Vereinfachung, MCP sei lediglich „USB-C für AI“. (Architektur und Verantwortlichkeiten)

Das Modell befindet sich typischerweise im Host-Kontext. Es entscheidet anhand der verfügbaren Beschreibung, ob ein Tool sinnvoll ist. Der Host muss daraus aber erst eine kontrollierte MCP-Anfrage machen. So bleiben Netzwerkzugriff, Zustimmung und Credential-Verwaltung außerhalb der Modellantwort.

Der Verbindungslebenszyklus von MCP

Die folgende Darstellung trennt bewusst drei Ebenen: Die Entscheidung des Modells, den MCP-Aufruf und die anschließende Ausführung im Zielsystem.

Benutzeranfrage
      │
      ▼
Host + Modell ──(Toolauswahl und Argumente)──► MCP Client
                                                    │
                         initialize / capabilities │
                                                    ▼
                                             MCP Server
                                                    │
                              Validierung + Rechte   │
                                                    ▼
                                               API / Tool
                                                    │
                              Ergebnis + Fehler      │
                                                    ▼
Host ◄──────── structuredContent / content ─── MCP Client

1. Initialisierung und Transport festlegen

Die erste Interaktion ist initialize. Der Client übermittelt die unterstützte Protokollversion, eigene Fähigkeiten und Implementierungsinformationen. Der Server antwortet mit seinen Fähigkeiten, etwa Tool-Unterstützung, Ressourcen oder Prompt-Vorlagen. Erst danach sendet der Client notifications/initialized und beginnt mit dem normalen Betrieb. (MCP-Lebenszyklus)

Diese Aushandlung verhindert, dass ein Client Funktionen voraussetzt, die der Server gar nicht anbietet. Ein Server darf beispielsweise keine Tool-Änderungsbenachrichtigungen senden, wenn er die entsprechende Fähigkeit nicht angekündigt hat. Planen Sie deshalb in Ihrer Testmatrix nicht nur „Verbindung erfolgreich“, sondern auch:

1. Protokollversion kompatibel?
2. Erwartete Server-Fähigkeit vorhanden?
3. Capability-Fehler verständlich protokolliert?
4. Verbindung nach Neustart sauber wiederhergestellt?

Für den Transport stehen in der aktuellen MCP-Dokumentation zwei Standardwege im Mittelpunkt:

Bei STDIO liest der Server JSON-RPC-Nachrichten aus stdin und schreibt sie nach stdout; Diagnoseausgaben gehören nach stderr. Eine einzige fremde Ausgabe nach stdout kann den Protokollkanal beschädigen. Streamable HTTP ist für einen unabhängigen Dienst besser geeignet, bringt aber eine größere Angriffsfläche und mehr Betriebsaufwand mit sich. (Transporte im MCP)

Achtung: Ein lokaler HTTP-Server, der an alle Netzwerkschnittstellen bindet und keine Origin-Prüfung besitzt, ist kein harmloser Entwicklungsschritt. Für lokale Dienste empfiehlt die Spezifikation die Bindung an 127.0.0.1, sofern kein Remote-Zugriff erforderlich ist.

2. Fähigkeiten und Werkzeuge entdecken

Nach der Initialisierung fragt der Client mit tools/list die verfügbaren Werkzeuge ab. Ein Tool besteht mindestens aus einem Namen, einer Beschreibung und einem inputSchema. Optional kommt ein outputSchema hinzu. Die Liste kann paginiert sein und sich später über eine „list changed“-Benachrichtigung ändern. (Tool-Spezifikation)

Für die Modellauswahl sind dabei zwei Ebenen entscheidend:

1. Maschinenlesbare Struktur: Welche Felder sind erlaubt, welche Pflichtfelder existieren und welche Datentypen gelten?
2. Semantische Orientierung: Was macht das Tool, wann soll es verwendet werden und welche Nebenwirkungen hat es?

Ein formal korrektes Schema mit der Beschreibung „führt Aktion aus“ hilft kaum. Besser ist eine Beschreibung wie: „Liest den Status eines Builds anhand seiner unveränderlichen Build-ID; verändert keine Daten und greift nicht auf Logs anderer Projekte zu.“ Der Name sollte stabil, eindeutig und für Menschen verständlich sein. Interne Datenbanktabellen oder wechselnde Implementierungsdetails gehören nicht in den Toolnamen.

3. JSON Schema als Vertrag, nicht als Sicherheitsgrenze

JSON Schema beschreibt die Form einer Eingabe. Für ein Tool zur Abfrage eines Build-Status könnte der Vertrag sinngemäß so aussehen:

{
  "type": "object",
  "properties": {
    "build_id": {
      "type": "string",
      "description": "Eindeutige Kennung des Builds"
    }
  },
  "required": ["build_id"],
  "additionalProperties": false
}

Damit kann der Client offensichtliche Formfehler erkennen. Trotzdem darf der Server nicht annehmen, dass Schema-Validierung bereits eine Berechtigungsprüfung ist. Ein gültiger String kann zu einem fremden Projekt gehören, eine erlaubte Zahl kann außerhalb des Nutzerkontingents liegen und ein korrektes Datum kann eine nicht freigegebene Datenabfrage auslösen.

Das optionale outputSchema beschreibt die Struktur von structuredContent. Wenn Sie strukturierte Ergebnisse zurückgeben, sollten Sie zusätzlich eine kompatible Textdarstellung für ältere Clients bereitstellen. Der Server muss Ergebnisse entsprechend dem Schema erzeugen; der Client sollte sie validieren. (Schema-Referenz für Tools und Ergebnisse)

Das ist der Unterschied zwischen Function Calling und MCP:

• Function Calling beschreibt meist, wie ein Modell ein Werkzeug in einer konkreten Modellinteraktion auswählt und Argumente erzeugt.
• MCP standardisiert, wie Werkzeuge entdeckt, beschrieben, aufgerufen und über Client-Server-Verbindungen zurückgegeben werden.
• Die eigentliche API bleibt hinter dem MCP Server. MCP ersetzt weder deren Authentifizierung noch ihre Geschäftsregeln.

4. Tool-Aufruf und API-Ausführung

Der Ablauf nach der Auswahl ist nicht „Modell ruft API auf“. Er sieht kontrolliert etwa so aus:

1. Das Modell schlägt den Toolnamen und Argumente vor.
2. Der Host prüft, ob dieses Tool für die aktuelle Sitzung freigegeben ist.
3. Der Client sendet tools/call an den MCP Server.
4. Der Server validiert Schema, Identität, Mandant und Geschäftsregeln.
5. Der Server ruft die interne API oder ein anderes Zielsystem auf.
6. Das Ergebnis wird als content und gegebenenfalls als structuredContent zurückgegeben.
7. Der Host übergibt das Ergebnis dem Modell oder zeigt es direkt an.

Die Trennung der Fehlerarten ist entscheidend. Ein unbekanntes Tool oder eine ungültige MCP-Nachricht ist ein Protokollfehler. Ein erreichbares Tool, dessen Ziel-API wegen eines Rate Limits scheitert, sollte dagegen als Tool-Ergebnis mit isError: true zurückgegeben werden. So kann das Modell den Fehler erkennen und beispielsweise einen sicheren Alternativschritt vorschlagen, statt eine Protokollstörung zu vermuten. (Fehlerbehandlung bei Tool-Aufrufen)

Für produktive Tools müssen Sie außerdem vier Betriebsfälle definieren:

• Timeout: Nach einer maximalen Laufzeit abbrechen und einen eindeutigen Status zurückgeben.
• Cancellation: Bei abgebrochenen Benutzeraufträgen laufende Arbeit tatsächlich stoppen, soweit das Zielsystem dies erlaubt.
• Idempotenz: Wiederholungen bei Netzwerkfehlern nur automatisch zulassen, wenn derselbe Aufruf keine zusätzliche Nebenwirkung erzeugt.
• Agent-Schleifen: Maximale Aufrufanzahl, Budget oder Zustandswechsel im Host begrenzen.

Ein Tool, das „Bestellung anlegen“ ausführt, darf nicht dieselbe Wiederholungsstrategie erhalten wie ein Tool, das „Status lesen“ ausführt. Die optionalen Tool-Anmerkungen wie readOnlyHint, destructiveHint und idempotentHint unterstützen die Einordnung, sind aber laut Spezifikation keine vertrauenswürdige Sicherheitsgarantie. (Tool-Anmerkungen und Sicherheitsregeln)

Berechtigungen und Zugangsdaten im laufenden Betrieb

Beginnen Sie bei internen Werkzeugen mit drei Risikoklassen:

• Nur lesend: Suche, Statusabfrage, Dokumentenabruf, Metriken.
• Schreibend: Ticket anlegen, Konfiguration ändern, Deployment starten.
• Destruktiv: Löschen, Widerrufen, Produktionsdaten überschreiben oder Schlüssel rotieren.

Für jede Klasse sollten Sie eigene Freigaberegeln definieren. Ein lesendes Tool kann automatisch laufen, sofern Mandant und Datensicht stimmen. Schreibende Aktionen sollten eine sichtbare Zusammenfassung der Argumente erhalten. Destruktive Aktionen benötigen eine explizite Bestätigung und möglichst eine zweite serverseitige Schutzbedingung.

Erfahrung aus der Plattformpraxis: Ein Feld wie environment: "production" darf nicht allein darüber entscheiden, ob ein gefährlicher Aufruf zulässig ist. Die Umgebung muss aus Identität, Richtlinie und Serverkonfiguration bestimmt oder zusätzlich gegen eine Allowlist geprüft werden.

Zugangsdaten gehören weder in inputSchema, Prompttexte noch öffentliche Serverkonfiguration. Bei STDIO können lokale Clients Credentials aus einer geschützten Umgebung beziehen. Für HTTP-basierte MCP Server sieht die Spezifikation einen OAuth-orientierten Autorisierungsweg vor. Dazu gehören geschützte Ressourcenmetadaten, Token-Audience-Prüfung, sichere Token-Speicherung und PKCE für Clients. Ein vom Client empfangenes Token darf nicht ungeprüft an eine nachgelagerte API weitergereicht werden. Der Server muss für das Zielsystem einen passenden, separat validierten Zugriff verwenden. (Offizielle Autorisierungsspezifikation)

Planen Sie zusätzlich:

• Mandanten- und Projektgrenzen vor dem API-Aufruf,
• Rate Limits pro Benutzer, Client und Tool,
• Korrelation-ID über Host, Client, Server und Ziel-API,
• Audit-Log mit Toolname, Ergebnisstatus und Freigabeentscheidung,
• Maskierung von Tokens und personenbezogenen Daten,
• getrennte Rollen für Entwicklung, Test und Produktion.

Bei personenbezogenen Daten müssen Sie die Verarbeitung, Aufbewahrung und Löschung mit Ihren DSGVO-Vorgaben abgleichen. Eine Übersicht der Datenschutzinformationen finden Sie im Datenschutzbereich von Kvmjet.

Vom lokalen MCP Server zum Remote-Dienst

Die richtige Betriebsform hängt nicht davon ab, ob ein Server technisch per HTTP erreichbar ist, sondern davon, wer ihn benötigt und welche Ressourcen er kontrolliert.

Lokal mit STDIO ist sinnvoll, wenn ein einzelner Entwickler auf lokale Dateien, Entwicklungswerkzeuge oder einen persönlichen Testdienst zugreift. Die Installation ist kleiner, und es gibt keinen zusätzlichen öffentlichen Endpunkt. Der Nachteil: Jeder Arbeitsplatz benötigt eigene Konfiguration, Updates, Prozesse und Credential-Verwaltung.

Remote mit Streamable HTTP passt zu einem Team, das einen zentralen Dienst mit einheitlichen Richtlinien benötigt. Sie erhalten einen festen Endpunkt, zentrale Logs und eine gemeinsame Versionierung. Dafür müssen Sie TLS, Authentifizierung, Skalierung, Session-Verhalten, Netzwerkzugriff und Ausfallszenarien betreiben.

Hybrid ist oft die vernünftigste Lösung: Nicht-sensitive Abfragen laufen über einen zentralen Server, während lokale Datei- oder Entwicklungsaktionen auf dem Arbeitsplatz bleiben. So vermeiden Sie, dass ein Remote-Dienst unnötig lokale Rechte erhält.

Entscheidungsbedingungen für die Bereitstellung

• Wenn nur eine Person und ein lokales Zielsystem beteiligt sind, wählen Sie zunächst STDIO.
• Wenn mehrere Nutzer dieselbe API mit zentralen Berechtigungen benötigen, setzen Sie auf Streamable HTTP mit TLS und OAuth-kompatibler Autorisierung.
• Wenn ein Tool lokale Dateien oder lokale Geräte benötigt, lassen Sie diese Funktion lokal oder bauen Sie einen ausdrücklich begrenzten Agenten ein.
• Wenn der Dienst dauerhaft erreichbar sein muss, definieren Sie Health Checks, Neustartverhalten, Logs und ein Updateverfahren vor dem produktiven Rollout.
• Wenn das Tool Schreib- oder Löschrechte besitzt, starten Sie mit Allowlist und Bestätigung; automatische Vollfreigabe ist kein geeigneter Standard.
• Wenn die Zielumgebung dauerhaft macOS, Xcode-Sitzungen oder Apple-Automatisierung benötigt, prüfen Sie einen reservierten Remote-Mac erst nach der Berechtigungs- und Stabilitätsanalyse. Für allgemeine APIs ist ein Mac keine notwendige MCP-Grundlage.

Für die technische Abnahme sollten Sie mindestens diese fünf Abläufe testen:

1. Verbindung mit kompatibler und inkompatibler Protokollversion.
2. Tool-Auflistung mit leerer, großer und geänderter Tool-Liste.
3. Gültige, fehlende und unerlaubte Argumente.
4. Erfolgreiche API-Antwort, fachlicher Fehler und Timeout.
5. Abbruch während eines laufenden Aufrufs sowie Neustart des Servers.

Wenn Sie die Serverkonfiguration, Zugangsschutz oder Datenverarbeitung prüfen möchten, können Sie zusätzlich das Hilfe-Zentrum von Kvmjet als Support-Einstieg nutzen.

Häufige Fragen zu MCP, AI Agent und JSON Schema

Wie hängt MCP mit einem großen Sprachmodell zusammen?

MCP ist die Verbindungsschicht zwischen AI-Anwendung und externen Systemen. Das Modell erhält Toolbeschreibungen und schlägt passende Argumente vor. Host und Client verwalten jedoch Sitzung, Berechtigungen, Transport und Ausführung. Das Modell sollte daher weder als Netzwerkclient noch als sicherer Credential-Speicher betrachtet werden.

Wie wird aus einer bestehenden API ein MCP Server?

Sie kapseln einen klaren API-Anwendungsfall als Tool. Der Server veröffentlicht Name, Beschreibung und inputSchema, prüft die eingehenden Argumente und übersetzt sie in einen internen API-Aufruf. Die Antwort wird anschließend als MCP-Ergebnis ausgegeben. Authentifizierung, Rate Limits, Geschäftsregeln und Logs bleiben im Server.

Warum verwendet MCP JSON Schema?

JSON Schema definiert Typen, Pflichtfelder und erlaubte Strukturen für Tool-Argumente und optionale Ergebnisse. Dadurch können Clients Eingaben prüfen und Modelle besser passende Aufrufe erzeugen. Das Schema ersetzt aber keine Autorisierung: Ob ein Nutzer eine gültige Ressource tatsächlich lesen oder verändern darf, muss der Server separat entscheiden.

Wer führt einen Tool-Aufruf aus?

Das Modell wählt ein Werkzeug und erzeugt Argumente. Der Host kann den Aufruf blockieren oder bestätigen lassen. Der MCP Client sendet die Nachricht, und der MCP Server führt nach Validierung den API-, Datenbank- oder Systemaufruf aus. Das Zielsystem verarbeitet also nicht direkt die Modellantwort, sondern eine kontrollierte Serveroperation.

Wie wird ein lokaler Server remote erreichbar?

Sie stellen den Server als unabhängigen HTTP-Dienst bereit, verwenden einen MCP-kompatiblen Streamable-HTTP-Transport und ergänzen TLS, Authentifizierung, Origin-Prüfung, Tokenvalidierung und Protokollierung. Öffnen Sie nicht einfach den lokalen Port nach außen. Für viele Entwickler bleibt ein lokaler STDIO-Server die sicherere und wartungsärmere Wahl.

Was Ihre aktuelle Lösung gegenüber einer Mac-Bereitstellung verliert

Wenn Ihre MCP-Werkzeuge dauerhaft auf lokale Entwicklungsumgebungen verteilt sind, entstehen häufig drei konkrete Nachteile: unterschiedliche SDK- und Serverstände, ungleich gepflegte Zugangsdaten sowie Unterbrechungen, sobald der Arbeitsplatz schläft, neu startet oder eine Benutzerbestätigung benötigt. Ein gewöhnlicher Cloud-Dienst löst diese Punkte nicht automatisch, wenn Ihre Workflows weiterhin auf eine konkrete macOS-Umgebung, Xcode, Signierung oder Apple-Automatisierung angewiesen sind.

Für reine API- und Datenbankwerkzeuge bleibt ein Linux- oder Containerbetrieb meist die sachlichere Wahl. Wenn Ihr MCP Server jedoch dauerhaft auf eine macOS-Ressource zugreifen muss, kann eine gemietete, kontrolliert erreichbare Mac-Umgebung die Betriebsunterbrechungen lokaler Rechner vermeiden und die Zuständigkeit für Wartung, Erreichbarkeit und Zugriff klarer abgrenzen. Prüfen Sie vor einer Anfrage bei Kvmjet, ob Sie wirklich eine dauerhafte Mac-Sitzung, physische Schnittstellen oder eine bestimmte Signierumgebung benötigen. Für kurzfristige Tests, Migrationen und zeitlich begrenzte Agent-Workflows ist dieser Weg meist nachvollziehbarer als der vorschnelle Kauf eigener Hardware.