Kostenloses Tool

OpenAPI zu MCP-Server in Rust

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

Offizielles SDK modelcontextprotocol/rust-sdk (rmcp)
Installation
cargo add rmcp
Ein funktionierendes MCP-Tool in Rust
#[derive(Debug, Deserialize, JsonSchema)]
struct GetOrderArgs {
    /// The order id to look up
    order_id: String,
}

#[tool_router]
impl MyServer {
    #[tool(description = "Look up one order by its id and return its current status.")]
    async fn get_order(&self, Parameters(args): Parameters<GetOrderArgs>)
        -> Result<CallToolResult, McpError> {
        Ok(CallToolResult::success(vec![Content::text(fetch_order(&args.order_id).await)]))
    }
}

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 Rust verdrahten

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

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 Rust: diese Tools mit modelcontextprotocol/rust-sdk (rmcp) (cargo add rmcp) gegen deine API zu implementieren, in der Form, die oben gezeigt wird.

Async-Runtime und Schema-Ableitung sind beide explizit

rmcp baut auf Tokio auf und leitet Schemas über schemars ab, sowohl die Runtime als auch die Schema-Ableitung sind also Entscheidungen, die du triffst, und keine Vorgaben, die du erbst. Rechne für denselben Server mit mehr Aufwand als in Python — und damit, dass der Compiler die Schema-Fehler findet, die andere SDKs erst zur Laufzeit entdecken.

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