Outil gratuit

OpenAPI vers serveur MCP en Go

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

SDK officiel modelcontextprotocol/go-sdk
Installation
go get github.com/modelcontextprotocol/go-sdk
Un outil MCP fonctionnel en Go
type GetOrderArgs struct {
    OrderID string `json:"orderId" jsonschema:"the order id to look up"`
}

server := mcp.NewServer(&mcp.Implementation{Name: "my-server"}, nil)

mcp.AddTool(server, &mcp.Tool{
    Name:        "get_order",
    Description: "Look up one order by its id and return its current status.",
}, func(ctx context.Context, req *mcp.CallToolRequest, args GetOrderArgs) (*mcp.CallToolResult, any, error) {
    return textResult(fetchOrder(args.OrderID)), nil, nil
})

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 Go

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

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 Go : implémenter ces outils face à votre API avec modelcontextprotocol/go-sdk (go get github.com/modelcontextprotocol/go-sdk), sous la forme montrée ci-dessus.

Les tags de struct portent le schéma

Go n'a ni décorateurs ni annotations de type à l'exécution : les schémas d'outils viennent donc de tags sur un type d'entrée. C'est plus cérémonieux que la version Python et nettement plus explicite, ce qui tend à produire de meilleurs schémas par accident : vous ne pouvez pas oublier de décrire un champ que vous avez dû déclarer.

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