Install
npx @modelcontextprotocol/inspectorÀ qui ça s'adresse
Utilisez mcp-builder pour créer un serveur MCP (Model Context Protocol) de qualité, afin qu'un modèle appelle une API ou un service externe via des outils bien conçus. Le langage peut être Python (FastMCP) ou Node/TypeScript (MCP SDK). C'est un guide de construction, pas un hébergeur pour un serveur non nommé.
Le bon prérequis : vous acceptez de faire d'abord une recherche approfondie et une planification, au lieu d'écrire des interfaces tout de suite. Le matériau présente TypeScript comme le choix avec un meilleur support SDK et une meilleure compatibilité sur plusieurs environnements d'exécution (par exemple MCPB). Il ne donne ni liste de produits d'agent ni chemin d'installation de dépôt. La page officielle du guide est
https://raw.githubusercontent.com/anthropics/skills/main/skills/mcp-builder/SKILL.md
Premier essai en 3 minutes
Ce guide ne donne pas de commande d'installation de skill ; n'inventez pas de chemin au premier essai. Le chemin recommandé commence à l'étape 1 : Deep Research and Planning. Un serveur MCP de qualité a quatre étapes principales ; l'extrait n'écrit complètement que le titre de la première, donc le premier essai est de la planification seulement — n'écrivez pas de processus serveur.
Prérequis : vous avez déjà une API ou un service externe à brancher. Action à bas risque : lister quelles requêtes de ce service sont en lecture seule et lesquelles changent des données, et décider que le distant utilise Streamable HTTP. Le résumé mentionne aussi stdio en local, mais l'extrait n'écrit que Streamable HTTP pour le distant ; n'assumez pas que les arguments stdio sont déjà complets.
Signal de succès : une page peut dire clairement « quels outils le modèle reçoit, et quelles contraintes portent sur les entrées ». Ne faites pas d'abord npm init d'un projet non planifié. Après confirmation du plan, passez à l'implémentation. Côté TypeScript, Zod peut servir de schema d'entrée ; les champs ont besoin de contraintes et de descriptions claires, avec des exemples dans les descriptions. Confirmez le répertoire avant d'écrire des fichiers.
Cas d'usage
Cas 1 : planifier un serveur distant sur la pile TypeScript recommandée. Choisir le MCP SDK, Streamable HTTP pour le transport, Zod pour les entrées, contraintes et exemples dans les descriptions. Le résumé mentionne aussi outputSchema/structuredContent et des annotations telles que readOnlyHint et destructiveHint, mais l'extrait n'écrit pas d'exemples complets de ces champs. Le critère de fin : le plan sépare les outils en lecture seule de ceux qui changent des données, pas que toutes les annotations sont déjà remplies. Ne lancez pas en même temps une pile Python comme « chemin principal » ; Python FastMCP et Pydantic sont des options parallèles, pas une double écriture obligatoire.
Cas 2 : après l'implémentation, compiler et inspecter. Le chemin TypeScript est d'abord npm run build pour confirmer la compilation, puis MCP Inspector : npx @modelcontextprotocol/inspector. Inspector ouvre une interface d'inspection, donc il a des effets de bord ; confirmez que vous testez le serveur local ou distant que vous venez de construire, puis exécutez. Le critère de fin : le build passe et Inspector se connecte au service nommé. L'extrait n'écrit pas tous les drapeaux Inspector ; n'inventez pas de paramètres de connexion.
Limites d'usage
Les quatre étapes principales commencent par la recherche approfondie et la planification ; plus loin le résumé esquisse implémenter puis inspecter/tester, mais les autres titres d'étape ne sont pas développés dans l'extrait. Le transport distant est écrit Streamable HTTP. Le schema d'entrée utilise Zod ou Pydantic. Les commandes de contrôle TypeScript sont npm run build et l'Inspector officiel.
N'inventez pas un chemin d'installation dans le dépôt. Le matériau ne donne pas de liste de clients et ne dit pas comment sauter la planification pour publier directement. Au-delà de ces étapes, options de langage et commandes de contrôle déjà écrites, ce guide ne couvre rien.