Outil gratuit

OpenAPI vers serveur MCP en Java

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

SDK officiel modelcontextprotocol/java-sdk
Installation
Maven: io.modelcontextprotocol.sdk:mcp
Un outil MCP fonctionnel en Java
McpServerFeatures.SyncToolSpecification getOrder =
    new McpServerFeatures.SyncToolSpecification(
        new McpSchema.Tool( "get_order",
            "Look up one order by its id and return its current status.",
            ORDER_INPUT_SCHEMA ),
        ( exchange, args ) -> new McpSchema.CallToolResult(
            List.of( new McpSchema.TextContent( fetchOrder( (String)args.get( "orderId" ) ) ) ),
            false ) );

McpSyncServer server = McpServer.sync( transportProvider )
        .serverInfo( "my-server", "1.0.0" )
        .tools( getOrder )
        .build();

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 Java

Reprenez les définitions d'outils générées et implémentez-les face à votre API avec le SDK pour Java, 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 à Java

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 Java : implémenter ces outils face à votre API avec modelcontextprotocol/java-sdk (Maven: io.modelcontextprotocol.sdk:mcp), sous la forme montrée ci-dessus.

Les clients sync et async sont des types distincts

Le SDK Java expose McpSyncServer et McpAsyncServer comme deux types distincts plutôt qu'une seule API avec un indicateur de mode, et le transport se choisit à la construction. Prenez le mauvais et vous réécrivez le câblage, vous ne basculez pas un réglage. Spring AI l'encapsule si vous êtes déjà dans cet écosystème.

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