Serveurs MCP dans les packages NuGet

NuGet offre un moyen pratique de empaqueter et de distribuer des serveurs MCP écrits dans .NET. Le SDK MCP C# et .NET offrent une plateforme robuste pour la création de serveurs MCP, et NuGet est idéal pour fournir votre serveur MCP aux utilisateurs finaux en tant qu’outil local. Les packages autonomes spécifiques à la plateforme réduisent les problèmes de compatibilité du runtime et la compilation AOT peut améliorer davantage l’expérience utilisateur final.

Pour plus d’informations sur le protocole MCP (Model Context Protocol) en général, consultez l’introduction sur le site web MCP. Pour créer votre propre serveur MCP et le empaqueter à l’aide de NuGet, consultez le guide de démarrage rapide.

Scénarios applicables

L’expédition de votre serveur MCP via NuGet ne s’applique pas à toutes les situations. Le terme « client MCP » est utilisé dans ce document et fait référence à une application qui orchestre l’interaction entre un agent IA ou un LLM et les appels effectués sur un serveur MCP. Certains exemples de clients MCP sont Visual Studio Code, Visual Studio, l’agent de codage GitHub Copilot, Claude Code ou Cursor.

Tenez compte des critères suivants pour déterminer si l’expédition de votre serveur MCP en tant que package NuGet est logique :

• ✅ Vous souhaitez que votre serveur MCP s’exécute localement sur le système de l’utilisateur (par exemple, dans le même contexte que le client MCP).
  • Les serveurs MCP locaux, tels que ceux fournis dans des packages NuGet, s’exécutent dans le même contexte que le client MCP et communiquent avec le client MCP via le transport d’E/S standard (stdio). Le client MCP est responsable du lancement du processus de serveur MCP local.
• ✅ Le Kit de développement logiciel (SDK) .NET est disponible pour le client MCP.
  • Les serveurs MCP NuGet sont des packages d’outils .NET, qui sont installés et exécutés à l’aide dnx du Kit de développement logiciel (SDK) .NET.
• ✅ Vous disposez d’un flux de package NuGet pour héberger votre package de serveur MCP.
  • NuGet.org pouvez être utilisé pour publier des packages de serveur MCP et fournit une expérience personnalisée de navigation et de consommation MCP. Toutefois, tout flux de package NuGet, tel qu’Azure Artifacts, peut être utilisé pour héberger des serveurs MCP si vous souhaitez conserver votre package de serveur MCP privé.

Avantages de l’utilisation de .NET et NuGet pour les serveurs MCP

Il existe plusieurs avantages à utiliser NuGet pour héberger votre serveur MCP :

• Kit de développement logiciel (SDK) officiel : le SDK C# MCP fournit une interface familière pour implémenter votre serveur MCP en C# et facilite l’exposition d’outils aux clients MCP.
• Options d’exécution flexibles : le Kit de développement logiciel (SDK) .NET fournit plusieurs options pour la compilation et l’empaquetage de votre serveur MCP. Pour plus d’informations, consultez la section configuration requise pour le runtime.
• Détectabilité et distribution : NuGet.org permet de présenter votre serveur MCP, ce qui permet aux utilisateurs potentiels de trouver votre serveur MCP et de l’utiliser facilement à partir de VS Code ou de Visual Studio. NuGet.org encourage l’utilisation d’un incorporé .mcp/server.json pour déclarer des entrées et un McpServer type de package pour permettre aux serveurs MCP d’être différenciés d’autres packages d’outils ou de dépendances.
• Flux de travail de création familiers : si vous utilisez déjà NuGet pour créer des packages de dépendances, la création et la publication d’un serveur MCP sont une expérience très similaire.

Téléchargement et exécution du package

Pour récupérer un serveur MCP local, le code du serveur doit être localisé et téléchargé à l’aide d’un mécanisme (protocole) spécifique à l’écosystème de packages. Cela s’effectue généralement avec une commande « single-shot » qui prend le nom et les arguments du package à télécharger, puis exécutez le package en tant qu’application de ligne de commande.

Pour les serveurs MCP basés sur NuGet, nous vous recommandons d’utiliser dnx (une nouvelle commande fournie dans .NET 10 Preview 6) pour acquérir et exécuter le package. dnx est actuellement fourni avec le Kit de développement logiciel (SDK) .NET, mais il est question d'inclure dnx dans l'environnement d'exécution .NET.

Une commande permettant de démarrer un serveur MCP ressemble à ceci :

dnx NuGet.Mcp.Server@0.1.2-preview --yes

Les variables d’environnement et les arguments de ligne de commande peuvent être utilisés pour configurer votre serveur MCP de manière personnalisée. Ces entrées vous permettent de personnaliser le comportement de votre serveur MCP en fonction des besoins spécifiques.

Cela télécharge le NuGet.Mcp.Server package de version 0.1.2-preview à partir de vos sources de package configurées (NuGet.org par défaut) et lance l’outil CLI contenu. Pour un serveur MCP, vous pouvez voir apparaître les messages de log dans stderr, mais le processus peut sembler se bloquer. Cela est attendu, étant donné que le processus attend les messages de protocole MCP sur stdin de votre client MCP.

En règle générale, votre client MCP appelle cette commande via une configuration MCP spécifique à l’outil, telle que le mcp.json fichier utilisé par Visual Studio Code et Visual Studio.

Tous ces outils prennent en charge l’installation d’autres sources. Par exemple, dnx prend en charge l’installation à partir d’Azure DevOps à l'aide du paramètre --source, permettant la consommation de serveurs MCP privés, à condition que les informations d'identification ou les fournisseurs d'informations d'identification nécessaires soient configurés.

Configuration requise pour le runtime

Une fois le package téléchargé, un runtime est nécessaire pour exécuter le code à l’intérieur du package. Les packages d’outils .NET (et par extension les serveurs MCP basés sur NuGet) prennent en charge diverses options pour la façon dont l’outil est compilé et empaqueté. Ces options vous permettent, l’auteur du serveur MCP, de décider quelles conditions d’exécution doivent être placées sur les utilisateurs de votre serveur MCP.

Il existe trois options principales pour empaqueter votre serveur MCP :

1. Dépendant de l’infrastructure : nécessite que le client MCP ait accès à un runtime .NET compatible. Si dnx est utilisé pour télécharger et exécuter le package, un environnement d'exécution sera disponible.
2. Autonome : regroupe le runtime avec le package. L’utilisation du découpage peut réduire la taille du package. Les outils .NET autonomes utilisent <PublishSelfContained>true</PublishSelfContained>.
3. Compilation anticipée (AOT) : paquet autonome avec compilation AOT activée. Pour plus d'informations, consultez le déploiement natif AOT. Les outils AOT .NET utilisent <PublishAot>true</PublishAot>.

Pour les serveurs MCP, nous vous recommandons d’utiliser l’option #2 (package autonome sans AOT), car elle élimine la nécessité d’une version spécifique du runtime .NET présente dans l’environnement de l’utilisateur. Si vous pouvez garantir une version d’exécution compatible sur l’environnement d’exécution prévu, l’option n° 1 est raisonnable. L’option n° 3 (à l’aide d’AOT) est également une bonne option, mais elle vous oblige ou vos dépendances à rendre votre code compatible avec la compilation AOT. Le SDK MCP C# est compatible AOT, mais d’autres dépendances que vous envisagez d’utiliser peuvent ne pas encore être compatibles avec AOT.

Envisagez d’utiliser le mcpserver modèle dans le package de modèle Microsoft.Extensions.AI.Templates pour utiliser les derniers paramètres par défaut recommandés.

Comparaison avec d’autres écosystèmes

D’autres écosystèmes ont des exigences et des flux de travail similaires pour l’empaquetage et l’exécution de serveurs MCP :

• NuGet/.NET : utilise la dnx commande pour télécharger et exécuter des packages d’outils .NET. Nécessite le Kit de développement logiciel (SDK) .NET pour dnx. Des dépendances d’exécution supplémentaires peuvent être regroupées dans le package.
• npm : utilise la npx commande pour télécharger et exécuter des packages npm et installer des dépendances transitivement. Nécessite Node.js.
• Python : utilise la uvx commande pour télécharger et exécuter des packages Python et installer des dépendances transitivement. Nécessite un runtime Python.
• Docker : utilise la docker run commande pour télécharger et exécuter des images. Nécessite le moteur Docker. Les images Docker peuvent cibler plusieurs architectures de processeur et fournir une excellente isolation, mais sont généralement plus grandes que les packages NuGet, npm ou Python.

Dans tous ces cas, le client MCP doit disposer de l’outil spécifique à l’écosystème nécessaire (par exemple, dnx, npx) pour télécharger et exécuter le serveur MCP basé sur un package.