MCP erklärt: So nutzt dein KI-Assistent deine bestehende REST-API

Montag, kurz nach acht, im Innendienst eines Sanitärgroßhändlers. Ein Installateur ruft an und will wissen, ob 30 Thermostatventile bis Donnerstag da sind. Die Kollegin am Telefon nutzt seit ein paar Wochen einen KI-Assistenten. Der formuliert ihr in Sekunden eine freundliche Antwort. Nur die eine Information, auf die es ankommt, fehlt ihm: der Bestand.

Der steht in der Warenwirtschaft. Die hat sogar eine REST-API, über die der Onlineshop seit Jahren Bestände abfragt. Der Assistent kommt trotzdem nicht ran. Also klickt die Kollegin selbst in die Warenwirtschaft und tippt die Zahl ab.

Für genau diese Lücke gibt es das Model Context Protocol, kurz MCP. Hier geht es darum, was MCP ist, wie aus einer bestehenden REST-API ein MCP-Server wird und wann sich das lohnt.

Was MCP ist

MCP ist ein offener Standard, den Anthropic vorgestellt hat. Er verbindet KI-Anwendungen wie Claude oder ChatGPT mit externen Datenquellen, Werkzeugen und Abläufen. Die offizielle Projektseite vergleicht MCP mit einem USB-C-Anschluss für KI: ein Stecker, viele Geräte.

Vorher sah es so aus: Jede KI-Anwendung brauchte für jede Datenquelle eine eigene Integration. Mit MCP baust du die Anbindung einmal, als MCP-Server. Jede Anwendung, die MCP spricht, kann ihn nutzen.

flowchart LR
  subgraph ohne["Ohne MCP"]
    C1["Claude"] -- "eigene Integration" --> W1["Warenwirtschaft"]
    C1 -- "eigene Integration" --> T1["Ticketsystem Kundenservice"]
    G1["ChatGPT"] -- "eigene Integration" --> W1
    G1 -- "eigene Integration" --> T1
  end
  subgraph mit["Mit MCP"]
    C2["Claude"] --> MW["MCP-Server Lager"]
    C2 --> MT["MCP-Server Tickets"]
    G2["ChatGPT"] --> MW
    G2 --> MT
    MW --> W2["Warenwirtschaft"]
    MT --> T2["Ticketsystem Kundenservice"]
  end

Im Artikel über REST, GraphQL, tRPC und gRPC war die Leitfrage: Wer ruft eure Schnittstelle in drei Jahren auf? Mit MCP steht ein neuer Kandidat auf der Liste, nämlich ein Sprachmodell.

Wie ein MCP-Server aufgebaut ist

MCP kennt drei Rollen. Der Host ist die KI-Anwendung, mit der jemand arbeitet. Darin steckt ein Client, der die Verbindung hält. Am anderen Ende sitzt der Server, also dein Adapter zur Warenwirtschaft. Laut MCP-Spezifikation tauschen die drei Nachrichten im Format JSON-RPC 2.0 aus.

Ein Server kann drei Dinge anbieten, so beschreibt es die MCP-Dokumentation:

• Tools sind Aktionen, die das Modell aufrufen kann, zum Beispiel „Bestand abfragen“.
• Resources sind Daten, die als Kontext gelesen werden, zum Beispiel die aktuellen Lieferbedingungen.
• Prompts sind wiederverwendbare Vorlagen, zum Beispiel „Antwort auf eine Lieferanfrage“.

Für eine REST-API sind fast immer Tools der Einstieg. Für die Verbindung gibt es laut Server-Dokumentation des TypeScript-SDK zwei Wege: stdio, wenn der Server lokal auf dem Rechner läuft, und Streamable HTTP für einen zentralen Server, den mehrere Leute nutzen. Ein Schritt-für-Schritt-Tutorial zeigt beide Varianten.

Aus der REST-API wird ein MCP-Server

Die gute Nachricht: Deine API bleibt, wie sie ist. Ein MCP-Server ist eine dünne Schicht über vorhandenem Code. Jedes Tool braucht einen Namen, eine Beschreibung und ein Schema für die Eingaben. Mit dem offiziellen TypeScript-SDK sieht das für unseren Großhändler so aus:

// MCP-Server als dünne Schicht über der bestehenden Lager-API
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const LAGER_API = "https://warenwirtschaft.intern/api/v1";

const server = new McpServer({ name: "lager", version: "1.0.0" });

server.registerTool(
  "bestand_abfragen",
  {
    title: "Lagerbestand abfragen",
    // Diesen Text liest das Modell, bevor es entscheidet, ob es das Tool nutzt
    description:
      "Liefert den aktuellen Lagerbestand und den nächsten Wareneingang " +
      "zu einer Artikelnummer. Nur lesend, ändert nichts.",
    inputSchema: {
      artikelnummer: z
        .string()
        .regex(/^\d{6}$/)
        .describe("Sechsstellige Artikelnummer aus der Warenwirtschaft, z. B. 104233"),
    },
  },
  async ({ artikelnummer }) => {
    // Derselbe Endpunkt, den der Onlineshop seit Jahren nutzt
    const antwort = await fetch(`${LAGER_API}/artikel/${artikelnummer}/bestand`, {
      headers: { Authorization: `Bearer ${process.env.LAGER_API_TOKEN}` },
    });

    if (!antwort.ok) {
      // Fehler als Text zurückgeben, damit das Modell ihn erklären kann
      return {
        isError: true,
        content: [{ type: "text", text: `Lager-API antwortet mit Status ${antwort.status}` }],
      };
    }

    const bestand = await antwort.json();
    return { content: [{ type: "text", text: JSON.stringify(bestand) }] };
  },
);

// Lokal per stdio; für einen zentralen Server wäre es Streamable HTTP
await server.connect(new StdioServerTransport());

Der meiste Code ist Beschreibung, nicht Logik. Das ist Absicht. Aus dem Zod-Schema baut das SDK ein JSON-Schema, und die Texte in description und .describe() sind alles, was das Modell über dein Werkzeug weiß. Schreib die Beschreibung so, als würdest du einer neuen Kollegin erklären, wann sie in die Warenwirtschaft schauen soll.

Das Schema prüft außerdem die Eingabe, bevor deine API sie sieht. Fragt das Modell nach „Thermostatventil groß“ statt nach einer Artikelnummer, kommt der Aufruf gar nicht erst bei der Warenwirtschaft an.

Ein Werkzeug statt der ganzen API

Es ist verlockend, alle Endpunkte auf einmal als Tools anzubieten. Tu es nicht. Die Tool-Definitionen gehen bei jeder Anfrage mit ans Modell, und je länger die Liste wird, desto schlechter wählt es das richtige Werkzeug aus.

Fang also mit der Frage an, die im Alltag am häufigsten gestellt wird. Beim Großhändler ist das „Ist es da, und wann kommt Nachschub?“. Dafür reicht ein Tool. Ein zweites kommt erst dazu, wenn das erste zuverlässig läuft und jemand eine neue Frage hat.

Dazu kommt eine zweite Regel: erst lesen, dann schreiben. Ein Tool, das Bestände zeigt, kann im schlimmsten Fall eine falsche Auskunft geben. Ein Tool, das Bestellungen anlegt, kann Ware verschicken.

Was MCP bringt und wo du aufpassen musst

Der Nutzen ist ziemlich handfest. Du baust die Anbindung einmal und bist nicht an einen KI-Anbieter gebunden. Wechselt ihr nächstes Jahr den Assistenten, bleibt der Server. Der Zugang zu euren Daten liegt in eurem Code und nicht in der Konfiguration eines Chat-Tools. Laut Projektseite sinken so Aufwand und Komplexität beim Anbinden von KI-Anwendungen.

Dafür gilt: Ein MCP-Server ist eine Schnittstelle wie jede andere, nur dass jetzt ein Modell entscheidet, wann sie aufgerufen wird. Die MCP-Spezifikation verlangt deshalb, dass Nutzer dem Datenzugriff und jedem Tool-Aufruf ausdrücklich zustimmen. Das ist eine Pflicht für die Anwendung, keine Garantie. Absichern musst du deinen Server trotzdem selbst.

Und weil ein Tool Code ist, bekommt es Tests wie jede andere Funktion: Was passiert bei einer unbekannten Artikelnummer, bei einer Zeitüberschreitung, bei einem leeren Lager? Ein Modell, das eine Fehlermeldung bekommt, kann sie erklären. Ein Modell, das gar keine Antwort bekommt, rät.

Für den Anfang reicht ein Tool, ein Leserecht und eine gute Beschreibung. Wenn die Kollegin im Innendienst danach nicht mehr in die Warenwirtschaft klicken muss, um eine Lieferzeit durchzugeben, weißt du auch, welches Werkzeug als Nächstes dran ist.