Outil gratuit

OpenAPI vers serveur MCP en Rust

Vous avez déjà une spécification OpenAPI. Voici comment elle devient un serveur MCP fonctionnel en Rust, et quelles parties un convertisseur ne peut pas faire à votre place.

SDK officiel modelcontextprotocol/rust-sdk (rmcp)
Installation
cargo add rmcp
Un outil MCP fonctionnel en 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)]))
    }
}

Généré, en marche, et toujours invisible.

Convertir une spécification vous donne un serveur. Cela ne vous donne personne qui veuille l'utiliser. MCP Showcase transforme le même endpoint en playground en direct, avec une documentation lisible pour chaque outil.

Comment ça marche

link
Convertissez la spécification

Le convertisseur OpenAPI transforme chaque opération en définition d'outil MCP, dans votre navigateur, sans envoyer votre spécification.

play_circle
Câblez-la en Rust

Reprenez les définitions d'outils générées et implémentez-les face à votre API avec le SDK pour Rust, sous la forme montrée ci-dessus.

checklist
Réduisez la liste

Une spécification convertie vous donne un outil par opération, ce qui est presque toujours beaucoup trop. Gardez ceux dont un agent a besoin.

De la spécification à Rust

La moitié mécanique l'est vraiment : chaque opération OpenAPI devient un outil MCP, sa summary devient la description, et ses paramètres de chemin, de requête et de corps s'aplatissent en un seul schéma d'entrée. Le convertisseur OpenAPI fait cette partie dans votre navigateur, sans envoyer votre spécification.

Ce qui reste a la forme de Rust : implémenter ces outils face à votre API avec modelcontextprotocol/rust-sdk (rmcp) (cargo add rmcp), sous la forme montrée ci-dessus.

Runtime asynchrone et dérivation de schéma sont tous deux explicites

rmcp repose sur Tokio et dérive les schémas via schemars : le runtime comme la dérivation de schéma sont donc des choix que vous faites, pas des valeurs par défaut dont vous héritez. Attendez-vous à plus de mise en place qu'en Python pour le même serveur, et à ce que le compilateur attrape les erreurs de schéma que les autres SDK découvrent à l'exécution.

Ce qu'aucun convertisseur ne fera pour vous

  • L'authentification. Le code généré appelle votre API sans identifiants. Câbler l'en-tête, le jeton ou le flux OAuth vous revient.
  • Réécrire les descriptions. Une summary OpenAPI est écrite pour un développeur qui lit la documentation. Une description d'outil MCP est lue par un modèle qui décide quoi appeler. Ce sont deux métiers différents, et les summaries demandent en général une réécriture une fois converties.
  • Choisir ce que vous exposez. Un convertisseur vous donnera un outil par opération. Pour la plupart des API, c'est un ordre de grandeur de trop.
  • Développer les corps $ref. Les résoudre demande votre section components : ils arrivent donc sous forme d'objet générique.

Pourquoi le nombre d'outils compte tant

Les définitions d'outils sont envoyées au modèle à chaque requête, pas une fois par session. Quatre-vingts opérations, ce sont quatre-vingts descriptions et quatre-vingts schémas dans la fenêtre de contexte de chaque tour — payés en continu, et mesurablement moins bons à la sélection qu'une liste courte. Le calculateur de tokens montre ce que coûte une liste donnée ; l'analyseur de schémas montre si les descriptions ont survécu à la conversion dans un état exploitable.

Outils et guides liés

Généré n'est pas la même chose qu'utilisable

Un serveur converti prouve que la correspondance a fonctionné. Cela ne dit rien à un client potentiel : il ne sait pas lire Rust et ne configurera pas un client pour le découvrir. MCP Showcase transforme le même endpoint en playground en direct avec une documentation par outil, que n'importe qui peut essayer dans un navigateur.

Questions fréquentes

La correspondance est mécanique : chaque opération devient un outil, sa summary devient la description, et ses paramètres deviennent un seul schéma d'entrée aplati. Ce qui ne l'est pas : l'authentification, la gestion des erreurs, et le choix des opérations qui méritent d'être dans la liste d'outils.

L'authentification, que vous ajoutez vous-même. Les corps de requête derrière un $ref, dont la résolution demande votre section components. Et le jugement : un convertisseur vous donnera volontiers quatre-vingts outils, ce qui est pire que huit.

Parce que les définitions d'outils sont envoyées au modèle à chaque requête. Quatre-vingts opérations, ce sont quatre-vingts descriptions et quatre-vingts schémas dans le contexte de chaque tour, payés en continu, tout en rendant le modèle mesurablement moins bon pour choisir entre eux.

Oui, et il vaut mieux le savoir avant de convertir. Une summary OpenAPI est écrite pour un développeur qui lit la documentation ; une description d'outil MCP est lue par un modèle qui décide quoi appeler. Ce sont deux métiers différents, et les summaries demandent en général une réécriture ensuite.

Déployez-le et passez l'URL dans le MCP Inspector pour confirmer le handshake et la liste des outils, puis dans l'analyseur de schémas pour voir si les descriptions ont assez bien survécu pour qu'un modèle choisisse correctement.

Autres outils MCP gratuits