Onze idées, une par écran. Chacune est un point à montrer pendant que vous expliquez. Tout se joue dans le regard, alors prenez les silences.
Quatre étapes : saisir ce qu'est MCP, puis apprendre ses trois primitives (outils, ressources, prompts) une par une, côté serveur et côté client.
Sans standard, chaque application se branche à chaque outil à la main. MCP est le connecteur standard qui met fin à l'enchevêtrement.
MCP est un standard, comme l'USB-C pour l'IA : vous développez une fois selon le protocole et tout outil conforme fonctionne. Il sépare aussi le travail : les développeurs d'applications d'un côté, les développeurs d'outils de l'autre.
L'application que vous utilisez est l'hôte. À l'intérieur, chaque client tient une connexion vers un serveur, et le serveur enveloppe l'outil ou les données réels.
Les messages circulent en JSON-RPC sur un transport : stdio pour un serveur local, HTTP pour un serveur distant. L'hôte peut tenir plusieurs clients à la fois, mais chaque client parle à un seul serveur.
Que détient chaque côté ? Le serveur offre les capacités : outils, ressources, prompts. Le le client est la connexion qui atteint un serveur et le met à disposition de l'hôte. Fournisseur contre connecteur.
Le client est-il un tuyau unique et partagé ? Non : un client par serveur. L'hôte ouvre une ligne distincte et nommée vers chaque serveur : vous les accordez et les révoquez un par un.
FastMCP, dans le SDK Python, s'occupe de la tuyauterie du protocole. Vous créez un serveur, vous enregistrez des capacités, et vous le lancez sur un transport.
stdio lance le serveur comme un sous-processus local de l'hôte ; HTTP l'expose comme un service distant. Le code du serveur est le même dans les deux cas : le transport, c'est seulement la façon dont les messages circulent.
Que veut dire « indépendant du transport » ? MCP fixe la langue, pas le canal. Les messages JSON-RPC sont identiques qu'ils passent par un tuyau stdio local ou par une connexion HTTP : la logique ne change d'aucun côté.
Réécrire le serveur pour le passer en remote ? Non. Ses tools, resources et prompts ne changent pas ; vous changez de transport (stdio → HTTP), pas de code.
Décorez une fonction : son nom, sa docstring et ses arguments typés deviennent un schéma que le modèle lit. C'est le modèle qui décide quand l'utiliser.
Un nom et une description clairs comptent : ce texte est tout ce dont le modèle dispose pour décider s'il appelle le tool, et comment. Traitez la docstring comme un prompt, pas comme un commentaire.
L'Inspector se connecte directement à votre serveur, sans LLM. Listez ce qu'il expose, appelez chaque outil à la main, lisez la réponse brute.
Déboguez d'abord le serveur seul. Si l'Inspector liste et appelle tout proprement, le problème vient ensuite du câblage côté client, pas du serveur.
Votre client liste les outils du serveur, transmet leurs schémas à Claude, exécute ce que Claude demande et lui renvoie le résultat, jusqu'à obtenir une réponse.
C'est la même boucle agentique qu'une fenêtre de chat n'a pas : le modèle peut agir, voir le résultat, et décider de la suite. MCP, c'est simplement la façon dont les outils arrivent jusqu'à lui.
Des données en lecture seule que le serveur expose à une adresse. Aucun effet de bord : pensez GET, pas POST.
Un schéma d'URI comme docs:// nomme les données. Une resource directe renvoie une collection ; une resource avec gabarit prend un paramètre pour aller chercher exactement un élément : un document précis, un enregistrement précis.
Contrairement aux outils, le modèle ne va pas chercher les ressources. C'est l'application, souvent l'utilisateur, qui choisit le contexte à apporter.
Voilà la différence avec un outil : l'outil, c'est au modèle de l'appeler ; la ressource, c'est à l'application de la charger. Même serveur, deux modèles de contrôle, et c'est là tout le cœur de MCP.
Un prompt testé et paramétré que le serveur expose, pour que la bonne formulation soit intégrée au lieu d'être réinventée à chaque fois.
Les prompts sortent les formulations durement acquises de la tête des gens pour les mettre sur le serveur. L'auteur les règle une fois ; tous les autres n'ont qu'à les appeler et obtiennent la bonne version.
Le client liste les prompts du serveur et les propose à l'utilisateur. Vous en choisissez un, vous remplissez les arguments, et il se déploie en message complet.
Si vous avez déjà utilisé une commande slash dans Claude Code, vous avez utilisé un prompt MCP. Le serveur livre la commande ; le client en fait une action à une touche.
Tout le protocole en une image : ce que le serveur expose, et qui a le droit de déclencher quoi.
Tout le cours repose là-dessus : les outils que le modèle appelle, les ressources que l'application charge, les prompts que l'utilisateur déclenche. Une fois les propriétaires clairs, le reste suit.
Des outils, des ressources et des prompts, exposés par un serveur et atteints par un client dans votre hôte : le contexte et les capacités se branchent une fois au lieu d'être reconstruits à chaque fois.
tutto.one/praxis · daniel@tutto.one