Qu'est-ce que le MCP ? — Introduction au MCP

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. Tout le reste de ce cours découle de ce déplacement de responsabilité.

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.

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 du cours.

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

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 partie suivante de ce cours. 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.