Introduction au Model Context Protocol — Construire avec l'API Claude

Le Model Context Protocol (MCP) est une couche de communication qui fournit à Claude du contexte et des outils sans que vous ayez à écrire d’intégrations complexes. Son principe tient en une phrase : la définition et l’exécution des outils sont déléguées à des serveurs MCP spécialisés, au lieu d’être implémentées dans votre propre serveur. Toute cette section découle de ce déplacement de responsabilité. À la fin de cette leçon, vous saurez quel problème MCP résout, ce qu’est un serveur MCP, et en quoi il diffère du simple tool use.

Le problème que MCP résout

Prenons une situation concrète. Vous construisez une interface de chat où vos utilisateurs posent des questions sur leurs données GitHub, et l’un d’eux demande : « Quelles pull requests sont ouvertes sur tous mes dépôts ? » La question paraît simple, la réponse ne l’est pas : Claude ne connaît pas l’état de ses dépôts, il lui faut des outils qui interrogent l’API GitHub.

Or GitHub est immense. Dépôts, pull requests, issues, projets, actions : la surface fonctionnelle se compte en centaines d’opérations. Sans MCP, c’est à vous d’écrire les centaines de schémas d’outils JSON correspondants, d’implémenter les fonctions qui les exécutent, puis de tester et de maintenir tout ce code d’intégration. Le travail initial est considérable, et il ne s’arrête jamais vraiment : chaque évolution de l’API se répercute sur votre base de code, alors que cette intégration n’est pas votre produit.

Comment MCP fonctionne

MCP déplace ce travail vers des serveurs MCP dédiés. Au lieu d’écrire vous-même tous ces outils GitHub, vous vous connectez à un serveur MCP pour GitHub qui les a déjà définis. Votre application ne parle plus à l’API GitHub, elle parle au serveur MCP, qui parle à l’API GitHub.

Votre serveur
    └── MCP Client ──► Serveur MCP GitHub ──► API GitHub
                            (outils déjà définis)

Le serveur MCP encapsule toute la fonctionnalité de GitHub et l’expose sous forme d’un ensemble standardisé d’outils. Votre application se connecte à ce serveur au lieu de tout implémenter depuis zéro. Reprenons la question de tout à l’heure : votre code n’a plus qu’à demander la liste des outils disponibles, la transmettre à Claude, puis exécuter celui que Claude choisit. Les centaines de schémas ne sont plus votre problème.

La documentation officielle nomme les trois participants : l’hôte MCP est l’application d’IA (Claude Desktop, Claude Code, votre propre application) ; elle crée un client MCP par connexion, et chaque client dialogue avec un serveur MCP. Un serveur « local » tourne sur la même machine et communique par entrée/sortie standard ; un serveur « distant » tourne ailleurs et parle Streamable HTTP. Dans les deux cas, le serveur est le programme qui fournit du contexte, où qu’il s’exécute.

Les serveurs MCP expliqués

Un serveur MCP fournit un accès à des données ou à des fonctionnalités via une interface standardisée. Ce qu’il expose se range dans trois catégories, appelées primitives, que vous implémenterez toutes les trois au fil de la section.

Primitive	Description
Outils	Fonctions que Claude peut appeler (ex: `get_repos()`)
Ressources	Données en lecture seule accessibles par URI
Prompts	Instructions pré-construites pour des workflows courants

D'après la leçon « Introducing MCP » (Claude Academy, Building with the Claude API) et l'aperçu d'architecture de modelcontextprotocol.io.

Le mot « standardisée » est la clé de cette définition. Parce que la forme est la même quel que soit le service, un client capable de parler à un serveur MCP GitHub sait aussi parler à un serveur MCP pour une base de données ou pour un système de fichiers, sans une ligne de code supplémentaire.

Questions fréquentes

Qui crée les serveurs MCP ? N’importe qui peut en créer un — y compris vous, dès la leçon 67 de cette section. Les fournisseurs de services publient souvent leurs propres implémentations officielles : AWS, par exemple, pourrait publier un serveur MCP officiel pour ses services, écrit par les gens qui connaissent le mieux ces services.

En quoi est-ce différent d’appeler une API directement ? Un serveur MCP vous fournit des schémas et des fonctions déjà définis. Si vous appelez l’API directement, rien ne vous dispense d’écrire vous-même toutes ces définitions d’outils, avec les descriptions d’arguments qui permettront à Claude de les utiliser correctement.

MCP n’est-il pas juste du tool use ? C’est la confusion la plus fréquente. Les serveurs MCP et le tool use sont complémentaires mais différents : MCP fournit des outils déjà implémentés, tandis que le tool use décrit comment Claude appelle ces outils. La différence tient en une phrase : avec MCP, quelqu’un d’autre a déjà fait le travail d’implémentation.

L’avantage MCP

Au lieu de maintenir un ensemble complexe d’intégrations, vous utilisez des serveurs MCP qui prennent en charge le travail lourd de connexion aux services externes. Votre code reste court, lisible, et concentré sur la logique applicative, c’est-à-dire sur la seule partie que personne d’autre ne peut écrire à votre place. Et comme le standard est ouvert, les mêmes serveurs servent claude.ai (où ils s’appellent des connecteurs), Claude Desktop, Claude Code, Cowork et vos propres applications.

À vous de jouer

Choisissez un service que vous utilisez au quotidien et listez cinq opérations que Claude devrait pouvoir y faire. Pour chacune, décidez : outil (une action), ressource (une donnée à lire), ou prompt (un workflow que l’utilisateur déclenche).
Cherchez dans le répertoire officiel des serveurs ou dans le répertoire des connecteurs si un serveur MCP existe déjà pour ce service. Si oui, combien d’outils expose-t-il ? C’est précisément le code que vous n’aurez pas à écrire.
Expliquez en deux phrases, à voix haute, la différence entre MCP et le tool use.

Sources officielles : Introducing MCP (Claude Academy) · Aperçu de l’architecture MCP · Serveurs de référence

Points clés à retenir

MCP déplace la définition et l’exécution des outils vers des serveurs MCP spécialisés : vous ne réécrivez plus les centaines de schémas d’une API comme GitHub.
Hôte, client, serveur : l’application crée un client par connexion ; le serveur fournit du contexte, en local (stdio) ou à distance (Streamable HTTP).
Un serveur expose trois primitives : outils (actions), ressources (données en lecture seule), prompts (workflows prêts).
MCP et tool use sont complémentaires : MCP fournit des outils déjà implémentés, le tool use décrit comment Claude les appelle.