De l'idée à un serveur opérationnel : définir le problème, choisir l'outil ou la ressource, les protocoles de transport, les schémas d'outils et les messages…
Un serveur MCP qui mérite d'être écrit commence presque toujours par une irritation. Quelque chose que vous allez chercher trois fois par semaine, dans un système sans API publique utilisable, et dont vous recopiez la réponse à la main dans une fenêtre de chat. C'est tout le test. Si l'irritation est réelle, le serveur tient dans une soirée. Sinon, vous êtes en train de fabriquer un wrapper que personne n'ouvrira deux fois.
Ceci est l'article de construction, pas l'explication. Ce qu'est MCP et pourquoi il existe est traité ailleurs, tout comme les serveurs qui valent la peine d'être installés avant d'écrire le vôtre. La suite suppose le vocabulaire acquis et va droit aux décisions : quoi construire, quelle forme lui donner, comment écrire pour un lecteur qui est un modèle de langage, et les erreurs qui produisent un serveur techniquement irréprochable et désinstallé en une semaine.