Outil gratuit

API REST vers serveur MCP en C#

Ce qu'il faut réellement pour exposer une API REST en serveur MCP avec C# : le SDK, un outil fonctionnel, et la partie qui décide si un agent s'en sert correctement.

SDK officiel modelcontextprotocol/csharp-sdk
Installation
dotnet add package ModelContextProtocol
Un outil MCP fonctionnel en C# 
[McpServerToolType]
public static class OrderTools
{
    [McpServerTool, Description("Look up one order by its id and return its current status.")]
    public static async Task<string> GetOrder(
        IOrderService orders,
        [Description("The order id to look up")] string orderId)
        => await orders.FetchAsync(orderId);
}
Testez ce que vous avez construit Générer des outils depuis une spec OpenAPI

Il tourne. Personne d'autre ne peut le voir.

Un serveur qui fonctionne, c'est là où l'effort s'arrête et où la vente commence. Pointez MCP Showcase dessus et obtenez un playground en direct que vos clients peuvent essayer, avec une documentation générée pour chaque outil.

Commencez gratuitement Explorer l'annuaire des serveurs MCP

Comment ça marche

link
Installez le SDK

Indiqué ci-dessus, avec le fait qu'il soit officiellement maintenu ou communautaire, ce qui compte plus dans certains langages que dans d'autres.

play_circle
Encapsulez un endpoint

Commencez par un seul outil, pas par toute votre API. Les définitions d'outils sont envoyées au modèle à chaque requête, et la justesse de la sélection baisse à mesure que la liste s'allonge.

checklist
Testez avant de brancher un agent

Passez l'URL déployée dans le MCP Inspector pour confirmer que le handshake aboutit et que les outils apparaissent comme prévu.

Le SDK pour C#

dotnet add package ModelContextProtocol — modelcontextprotocol/csharp-sdk, officiellement maintenu.

Des attributs et de l'injection de dépendances

Les outils sont marqués par des attributs et résolus via le conteneur d'injection standard de .NET : un outil peut donc recevoir des services injectés en paramètres, à côté des arguments fournis par le modèle. C'est pratique, et c'est aussi le moyen le plus simple d'exposer accidentellement un service interne à travers une signature d'outil. Vérifiez ce qui est réellement atteignable depuis chacun.

Encapsuler un endpoint REST

Un serveur MCP est une fine couche au-dessus de code que vous avez déjà. Chaque outil a besoin de trois choses : un nom, une description disant ce qu'il fait et quand le choisir, et un schéma d'entrée. Le SDK pour C# s'occupe du protocole ; ce que vous écrivez, c'est la correspondance entre ces arguments et votre appel HTTP existant.

Commencez par un endpoint plutôt que par toute votre API. Les définitions d'outils sont renvoyées au modèle à chaque requête : chacune est donc un coût de contexte permanent, et la capacité du modèle à choisir correctement baisse quand la liste s'allonge. Huit outils bien décrits valent mieux que quatre-vingts.

La partie qui ne dépend pas de C#

Quel que soit le langage, ce sont les descriptions qui décident du comportement de l'agent. Elles sont lues par le modèle, pas par vos collègues, et un outil décrit en trois mots est appelé au hasard. Vous pouvez vérifier les vôtres avec l'analyseur de schémas MCP, et voir ce que la liste coûte par requête avec le calculateur de tokens.

Outils et guides liés

Un serveur qui fonctionne, c'est la moitié du travail

Une fois qu'il tourne, il reste que personne ne peut dire ce qu'il fait. Un prospect ne peut pas lire votre code C# et n'installera pas un client pour le découvrir. MCP Showcase pointe sur la même URL et produit un playground en direct avec une documentation générée pour chaque outil, pour qu'évaluer votre serveur prenne un clic.

Questions fréquentes

Encapsulez chaque endpoint qu'un agent doit atteindre dans un outil : un nom, une phrase disant ce qu'il fait et quand l'utiliser, et un schéma d'entrée. Le SDK pour C# s'occupe du protocole ; ce que vous écrivez, c'est la correspondance entre les arguments de l'outil et votre appel HTTP existant.

Non, et c'est l'erreur la plus fréquente. Les définitions d'outils sont renvoyées à chaque requête : quatre-vingts endpoints, ce sont quatre-vingts descriptions dans la fenêtre de contexte de chaque tour, et la capacité du modèle à choisir le bon chute nettement quand la liste s'allonge. Commencez par les quelques-uns dont un agent a vraiment besoin.

Le badge au-dessus du code vous le dit. Là où il n'y a pas de SDK officiel, les options communautaires suivent la spécification de plus ou moins près : vérifiez à quand remonte la dernière révision du protocole prise en charge, surtout côté transports, avant de bâtir dessus.

Streamable HTTP pour tout ce qui est déployé. Les clients l'essaient de plus en plus en premier et certains ne se replient plus sur l'ancien HTTP+SSE, ce qui se manifeste par un client qui ne voit tout simplement pas votre serveur plutôt que par une erreur.

Vous ne pouvez pas le juger en relisant votre propre code, puisque vous savez déjà ce que font les outils. Passez le serveur dans l'analyseur de schémas : il examine les descriptions et les schémas d'entrée comme un modèle les lit et signale ceux qui obligeraient un agent à deviner.

Autres outils MCP gratuits

MCP Inspector en ligne

Collez l'URL d'un serveur MCP et voyez tous les outils, ressources et prompts exposés, avec les schémas complets et le journal des requêtes. Rien à installer.
Testeur de serveur MCP

Vérifiez que votre serveur MCP fonctionne vraiment. Collez l'URL et obtenez un rapport réussite/échec sur la connexion, le handshake, le transport et les outils annoncés.
Scanner de sécurité MCP

Avant de pointer un agent vers un serveur MCP, regardez ce qu'il demande. Noté de A à F sur le transport, l'authentification, les marqueurs de tool poisoning et les paramètres dangereux.
Calculateur de tokens MCP

Les définitions d'outils sont envoyées à chaque requête, pas une seule fois. Collez l'URL de votre serveur MCP pour voir combien de tokens cela représente, quels outils pèsent le plus et ce que cela coûte.
Voir tous les outils gratuits