Kostenloses Tool

OpenAPI zu MCP-Server in TypeScript

Du hast bereits eine OpenAPI-Spezifikation. So wird daraus ein funktionierender MCP-Server in TypeScript — und das sind die Teile, die dir ein Konverter nicht abnehmen kann.

Offizielles SDK modelcontextprotocol/typescript-sdk
Installation
npm install @modelcontextprotocol/sdk zod
Ein funktionierendes MCP-Tool in TypeScript
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

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

server.tool(
  "get_order",
  "Look up one order by its id and return its current status.",
  { orderId: z.string().describe("The order id to look up") },
  async ({ orderId }) => ({ content: [{ type: "text", text: await fetchOrder(orderId) }] })
);

Generiert, läuft — und immer noch unsichtbar.

Eine Spezifikation zu konvertieren bringt dir einen Server. Es bringt dir niemanden, der ihn nutzen will. MCP Showcase macht aus demselben Endpunkt ein Live-Playground mit lesbarer Doku für jedes Tool.

So funktioniert es

link
Spezifikation konvertieren

Der OpenAPI-Konverter macht aus jeder Operation eine MCP-Tool-Definition — in deinem Browser, ohne deine Spezifikation hochzuladen.

play_circle
In TypeScript verdrahten

Nimm die generierten Tool-Definitionen und implementiere sie gegen deine API mit dem SDK für TypeScript, in der Form, die oben gezeigt wird.

checklist
Die Liste zusammenstreichen

Eine konvertierte Spezifikation gibt dir ein Tool pro Operation, und das sind fast immer viel zu viele. Behalte die, die ein Agent braucht.

Von der Spezifikation zu TypeScript

Die mechanische Hälfte ist wirklich mechanisch: Jede OpenAPI-Operation wird ein MCP-Tool, ihre Summary wird die Beschreibung, und ihre Pfad-, Query- und Body-Parameter werden zu einem einzigen flachen Input-Schema. Der OpenAPI-Konverter erledigt diesen Teil in deinem Browser, ohne deine Spezifikation hochzuladen.

Was bleibt, hat die Form von TypeScript: diese Tools mit modelcontextprotocol/typescript-sdk (npm install @modelcontextprotocol/sdk zod) gegen deine API zu implementieren, in der Form, die oben gezeigt wird.

Dein Zod-Schema ist der Vertrag, den das Modell sieht

Das TypeScript-SDK baut das JSON-Schema aus Zod, `.describe()` an jedem Feld ist also keine Dokumentation für deine Kollegen — es ist das, was dem Modell sagt, was dort hineingehört. Schemas ohne diese Angaben validieren einwandfrei und lassen den Agenten bei jedem Parameter raten.

Was dir kein Konverter abnimmt

  • Authentifizierung. Generierter Code ruft deine API ohne Zugangsdaten auf. Header, Token oder OAuth-Flow zu verdrahten ist deine Sache.
  • Die Beschreibungen umschreiben. Eine OpenAPI-Summary ist für Entwickler geschrieben, die Doku lesen. Eine MCP-Tool-Beschreibung liest ein Modell, das entscheidet, was es aufruft. Das sind zwei verschiedene Aufgaben, und Summaries muss man nach der Konvertierung meist umschreiben.
  • Auswählen, was du bereitstellst. Ein Konverter gibt dir ein Tool pro Operation. Für die meisten APIs ist das eine Größenordnung zu viel.
  • $ref-Bodies auflösen. Dafür braucht es deine components-Sektion, sie kommen also als generisches Objekt herüber.

Warum die Anzahl der Tools so sehr zählt

Tool-Definitionen gehen bei jeder Anfrage ans Modell, nicht einmal pro Sitzung. Achtzig Operationen heißt achtzig Beschreibungen und achtzig Schemas im Kontextfenster jeder Runde — dauerhaft bezahlt und messbar schlechter bei der Auswahl als eine kurze Liste. Der Token-Rechner zeigt, was eine bestimmte Liste kostet; der Schema-Linter zeigt, ob die Beschreibungen die Konvertierung in brauchbarem Zustand überstanden haben.

Verwandte Tools und Anleitungen

Generiert ist nicht dasselbe wie nutzbar

Ein konvertierter Server beweist, dass die Abbildung funktioniert hat. Einem potenziellen Kunden sagt er nichts — er kann kein TypeScript lesen und wird keinen Client konfigurieren, um es herauszufinden. MCP Showcase macht aus demselben Endpunkt ein Live-Playground mit Doku pro Tool, das jeder im Browser ausprobieren kann.

Häufig gestellte Fragen

Die Abbildung ist mechanisch: Jede Operation wird ein Tool, ihre Summary die Beschreibung, ihre Parameter ein flaches Input-Schema. Nicht mechanisch sind Authentifizierung, Fehlerbehandlung und die Entscheidung, welche Operationen überhaupt in die Tool-Liste gehören.

Die Authentifizierung, die du selbst ergänzt. Request-Bodies hinter einem $ref, für deren Auflösung deine components-Sektion nötig ist. Und das Urteilsvermögen — ein Konverter gibt dir bereitwillig achtzig Tools, was schlechter ist als acht.

Weil Tool-Definitionen bei jeder Anfrage ans Modell gehen. Achtzig Operationen heißt achtzig Beschreibungen und achtzig Schemas im Kontext jeder Runde — dauerhaft bezahlt, während das Modell messbar schlechter darin wird, zwischen ihnen zu wählen.

Ja, und das solltest du vor dem Konvertieren wissen. OpenAPI-Summaries sind für Entwickler geschrieben, die Doku lesen; MCP-Tool-Beschreibungen liest ein Modell, das entscheidet, was es aufruft. Das sind zwei verschiedene Aufgaben, und Summaries muss man hinterher meist umschreiben.

Deploye es und lass die URL durch den MCP Inspector laufen, um Handshake und Tool-Liste zu bestätigen, danach durch den Schema-Linter, um zu sehen, ob die Beschreibungen gut genug übernommen wurden, dass ein Modell richtig wählt.

Weitere kostenlose MCP-Tools