Outil gratuit

OpenAPI vers serveur MCP en TypeScript

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

SDK officiel modelcontextprotocol/typescript-sdk
Installation
npm install @modelcontextprotocol/sdk zod
Un outil MCP fonctionnel en 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) }] })
);

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 TypeScript

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

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 TypeScript : implémenter ces outils face à votre API avec modelcontextprotocol/typescript-sdk (npm install @modelcontextprotocol/sdk zod), sous la forme montrée ci-dessus.

Votre schéma Zod est le contrat que voit le modèle

Le SDK TypeScript construit le JSON Schema à partir de Zod : `.describe()` sur chaque champ n'est donc pas de la documentation pour vos collègues, c'est ce qui indique au modèle quoi y mettre. Des schémas écrits sans cela se valident parfaitement et laissent l'agent deviner à chaque paramètre.

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