Guide · Connecter
Model Context Protocol et tool use
Le Model Context Protocol est un standard ouvert qui connecte les assistants IA à des systèmes extérieurs : fichiers, bases de données, API et applications. Anthropic l'a publié en novembre 2024 et son adoption a largement dépassé la maison. Il remplace une intégration sur mesure par outil et par assistant par un serveur que tout client sait lire.
Combien de temps faut-il pour l'apprendre ?
Connecter un serveur existant prend dix minutes. Comprendre ce que vous venez d'autoriser prend une soirée. Écrire votre propre serveur tient dans un week-end si vous codez déjà, et c'est le moment où l'idée cesse d'être abstraite.
Le chemin le plus rapide, dans l'ordre
- 01
Apprendre les trois pièces
Un hôte est l'application que vous utilisez, un client vit dedans, un serveur expose un système. Cette séparation est toute l'idée : le serveur est écrit une fois et tous les clients peuvent s'en servir, ce qui est la raison d'être du standard.
- 02
Connecter d'abord un serveur existant
Filesystem, GitHub ou un serveur Postgres, branché sur un client que vous utilisez déjà. Voir un assistant lire votre propre dépôt est ce qui fait comprendre l'abstraction, et cela ne coûte rien.
- 03
Comprendre tools, resources et prompts
Les tools sont des actions que le modèle peut déclencher, les resources sont ce qu'il peut lire, les prompts sont des modèles réutilisables offerts par le serveur. La confusion sur MCP vient presque toujours de ces trois notions mélangées.
- 04
Mesurer l'autorisation que vous venez de donner
Un appel d'outil est du code qui s'exécute sur votre machine avec vos accès. Lisez ce qu'un serveur peut faire avant de le brancher, et traitez un serveur tiers comme une extension de navigateur qui demande tous les droits.
- 05
Écrire un petit serveur à vous
Un outil, une ressource, sur quelque chose que vous utilisez vraiment. Les SDK officiels rendent cela faisable en un après-midi, et en avoir écrit un rend tous les autres lisibles.
- 06
Concevoir pour l'échec
Les outils expirent, renvoient n'importe quoi et sont appelés avec des arguments imprévus. Un serveur qui échoue clairement vaut mieux qu'un serveur à dix fonctions, parce que le modèle lit votre message d'erreur et peut agir dessus.
Les outils qui valent votre temps
| Outil | À quoi ça sert |
|---|---|
| Claude Desktop et Claude Code | Les clients de référence : le moyen le plus rapide d'avoir un MCP qui tourne aujourd'hui. |
| SDK MCP officiels | Bibliothèques TypeScript et Python pour écrire un serveur sans gérer le protocole soi-même. |
| MCP Inspector | Outil local pour appeler les tools de votre serveur à la main, c'est ainsi qu'on le débogue. |
| Serveur Filesystem | La première connexion canonique : lecture et écriture limitées à un dossier que vous choisissez. |
| Serveur GitHub | Issues, pull requests et code, ce qui donne à l'assistant une vraie connaissance du projet. |
| Serveurs de base de données | Postgres et consorts, en lecture seule tant que vous n'êtes pas certain. Commencez ainsi, restez-y un moment. |
Les annuaires de serveurs grossissent vite et ne sont curés dans aucun sens sérieux. Un serveur tourne avec vos permissions sur votre machine. Lisez le code de ce que vous n'avez pas écrit, préférez les serveurs dont la portée se restreint, et connectez-en un à la fois.
Les erreurs qui coûtent des semaines
Tout connecter le premier jour
Douze serveurs, un assistant qui a trop d'outils pour bien choisir, et aucune idée de lequel vient de faire une chose surprenante. Ajoutez-en un, utilisez-le une semaine, puis passez au suivant.
Donner l'écriture pour démarrer plus vite
La lecture seule enseigne la même chose sans le risque. L'écriture est une décision à prendre délibérément, une fois que vous savez exactement ce que le serveur atteint.
Croire que MCP ne sert qu'au code
C'est un protocole pour relier un modèle à des systèmes, et les systèmes les plus rentables sont souvent les plus ennuyeux : notes, agendas, documents internes, une base de votre propre travail.