Kostenloses Tool

OpenAPI zu MCP-Server in Ruby

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

Community-SDK community SDKs
Installation
gem install mcp
Ein funktionierendes MCP-Tool in Ruby
# Community SDK; check the gem tracks a current spec revision before relying on it.
server = MCP::Server.new(name: "my-server")

server.register_tool(
  name: "get_order",
  description: "Look up one order by its id and return its current status.",
  input_schema: { type: "object",
                  properties: { orderId: { type: "string",
                                           description: "The order id to look up" } },
                  required: ["orderId"] }
) { |args| fetch_order(args["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 Ruby verdrahten

Nimm die generierten Tool-Definitionen und implementiere sie gegen deine API mit dem SDK für Ruby, 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 Ruby

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 Ruby: diese Tools mit community SDKs (gem install mcp) gegen deine API zu implementieren, in der Form, die oben gezeigt wird.

Kein einzelnes offizielles SDK

Für Ruby gibt es kein unter modelcontextprotocol gepflegtes SDK, die Optionen sind also Community-Gems von unterschiedlicher Vollständigkeit und Aktualität. Prüfe, wann das Gem zuletzt einer Spezifikationsrevision gefolgt ist, bevor du dich darauf festlegst — das Protokoll hat sich schneller bewegt als die meisten Community-Portierungen, besonders bei Transporten.

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 Ruby 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