Von REST-API zu MCP-Server in 10 Minuten

Wenn du eine REST-API hast, hast du 90% eines MCP-Servers. Das ist die Sache, die dir niemand sagt.

Deine Endpoints sind deine Tools. Deine Request-Schemas sind deine Input-Schemas. Deine Response-Formate sind deine Output-Typen. Die Zuordnung ist fast peinlich direkt.

POST /users/create? Das ist ein create_user-Tool. GET /orders/:id? Das ist get_order. Die Parametertypen, die Validierungsregeln, die Fehlerformate — du hast das alles schon geschrieben. Wahrscheinlich zweimal, wenn man die OpenAPI-Spec mitzaehlt.

Das Einzige, was fehlt, ist die Uebersetzungsschicht. Und — das ist der Teil, der dich stolpern laesst — gute Beschreibungen. Nicht "description: erstellt einen Benutzer." Beschreibungen, mit denen ein LLM tatsaechlich denken kann. Dieser Unterschied ist wichtiger als du glaubst.

MCP-Tools bilden sich fast 1:1 auf REST-Endpoints ab. Das ist kein Zufall. Beide beantworten grundsaetzlich dieselbe Frage: Was kann dieser Service, und wie bitte ich ihn, etwas zu tun?

Die Schema-Uebersetzungen sind mechanisch. JSON Schema rein, JSON Schema raus. Pflichtfelder bleiben Pflichtfelder. Enums bleiben Enums. Verschachtelte Objekte bleiben verschachtelt. Wenn du die Augen zusammenkneifst, sieht eine MCP-Tool-Definition aus wie eine OpenAPI-Operation mit besserer Ergonomie.

Man koennte die Konvertierung automatisieren. Wir haben sie automatisiert. Das strukturelle Mapping ist ein geloestes Problem. Darueber musst du nicht nachdenken.

Worueber du nachdenken musst, ist alles, was die Struktur nicht einfaengt. Die impliziten Vertraege. Die Reihenfolge-Abhaengigkeiten. Das Wissen "ruf diesen Endpoint nicht auf, bevor du jenen aufgerufen hast", das in den Koepfen deines Teams lebt und nirgendwo sonst. Das ist die eigentliche Uebersetzungsarbeit.

Hier scheitern die meisten Migrationen. Und es ist nicht, wo man es erwarten wuerde.

Du kopierst die Endpoint-Namen, generierst Schemas aus deiner OpenAPI-Spec und lieferst aus. Alles sieht grossartig aus. Die Tool-Definitionen sind sauber. Die Typen stimmen. Du fuehlst dich produktiv.

Dann ruft das LLM create_user auf, obwohl es update_user aufrufen sollte. Warum? Weil beide Beschreibungen sagen "verwaltet Benutzerdaten." Du hast sie fuer einen Entwickler geschrieben, der den URL-Pfad lesen und den Unterschied verstehen wuerde. Ein LLM liest keine URL-Pfade. Es liest Beschreibungen.

Deine Beschreibungen muessen eindeutig, spezifisch und fuer einen Leser geschrieben sein, der dein System nie gesehen hat und nie sehen wird. "Erstellt ein neues Benutzerkonto mit der angegebenen E-Mail und dem Passwort. Gibt das erstellte Benutzerobjekt mit einer generierten ID zurueck. Schlaegt fehl, wenn die E-Mail bereits registriert ist." Das ist eine Beschreibung, mit der ein LLM arbeiten kann.

Das ist die wirklich schwere Arbeit der Migration. Nicht die Klempnerei — die Benennung.

Hier ist die Abkuerzung. Richte SmeltSec auf deine OpenAPI-Spec oder dein GitHub-Repo. Das ist alles. Das ist der Ausgangspunkt.

Es liest deine Endpoints, leitet die Absicht aus deiner Routenstruktur und vorhandenen Dokumentation ab, generiert MCP-Tools mit korrekten Schemas und schreibt Beschreibungen, die LLMs tatsaechlich parsen koennen. Dann fuehrt es einen Sicherheitsscan durch, um Tool-Poisoning-Vektoren und zu freizuegige Input-Schemas zu erkennen.

Die 10 Minuten im Titel sind grosszuegig. Die meisten Repos brauchen unter 60 Sekunden. Der Flaschenhals ist nicht die Generierung — bist du, der das Ergebnis durchgeht und entscheidet, ob die Beschreibungen praezise einfangen, was jedes Tool tut.

Du koenntest das alles von Hand machen. Du wuerdest ein Wochenende dafuer brauchen. Du wuerdest die Schemas richtig hinbekommen und die Beschreibungen falsch, weil gute Beschreibungen zu schreiben eine Faehigkeit ist, die die meisten Backend-Ingenieure nie entwickeln mussten. Das ist die Art von langweiliger, kritischer Arbeit, die Werkzeuge uebernehmen sollten.

Das Ueberraschende an der Umstellung auf MCP ist nicht die Umstellung. Es ist, was danach passiert.

Deine API hat ploetzlich neue Konsumenten, die du nicht erwartet hast. KI-Agenten beginnen, deine Tools auf Weisen aufzurufen, die du nie getestet hast. Sie kombinieren deine Tools mit anderen Tools von voellig unverbundenen Services — ein Kalender-Tool ruft dein Zahlungs-Tool auf, das ein Benachrichtigungs-Tool aufruft, alles orchestriert von einem LLM, das den Workflow von allein herausgefunden hat.

Du baust nicht mehr eine API. Du traegst zu einem Oekosystem bei. Deine Tools werden Bausteine in Systemen, die du nicht entworfen hast und nicht vorhersagen kannst.

Das ist unbequem, wenn du es gewohnt bist, die gesamte Integrationsoberflaeche zu kontrollieren. Es ist aufregend, wenn du erkennst, was es bedeutet: Dein Service ist gerade auf Weisen nuetzlich geworden, die du dir nicht haettest vorstellen koennen, fuer Nutzer, die du nie treffen wirst, und loest Probleme, von denen du nicht wusstest, dass sie existieren.

Das ist der wahre Grund fuer den Wechsel. Nicht weil MCP neuer oder trendiger ist. Weil es deine Arbeit in einer viel groesseren Welt relevant macht.