Qu'est-ce que le Model Context Protocol (MCP) ? Comment ça marche

Le problème que résout le MCP

Avant le MCP, chaque assistant IA qui devait interagir avec un outil externe nécessitait une intégration construite sur mesure. Si vous vouliez que Claude lise vos issues GitHub, il fallait que quelqu'un écrive du code spécifique pour cela. Si vous vouliez ensuite qu'il interroge aussi votre base de données, c'était une intégration séparée. Et si vous passiez de Claude à GPT, vous repartiez de zéro.

Cela a créé un paysage fragmenté où les concepteurs d'outils devaient écrire des adaptateurs différents pour chaque plateforme IA, et où les développeurs IA devaient maintenir une pile grandissante de connecteurs sur mesure.

Le Model Context Protocol change cela en fournissant un standard ouvert et unique pour la manière dont les modèles d'IA communiquent avec des services externes. Pensez-y comme à l'USB des outils IA. Avant l'USB, chaque périphérique avait son propre connecteur. Après l'USB, n'importe quel appareil pouvait se brancher sur n'importe quel ordinateur. Le MCP fait quelque chose de similaire pour l'écosystème de l'IA.

Comment fonctionne le MCP en pratique

Au cœur, le MCP définit une architecture client-serveur. L'assistant IA agit comme client, et les outils externes tournent comme serveurs MCP. Le protocole spécifie exactement comment ces deux parties communiquent : quels messages elles s'envoient, quel format ces messages prennent, et comment les erreurs sont gérées.

Un serveur MCP expose un ensemble de capacités. Cela peut inclure des outils (des fonctions que l'IA peut appeler), des ressources (des données que l'IA peut lire) ou des prompts (des modèles que l'IA peut utiliser). Quand un assistant IA se connecte à un serveur MCP, il découvre les capacités disponibles et peut ensuite les utiliser au cours des conversations.

La communication effective passe par une couche de transport. Pour les serveurs locaux, c'est typiquement stdio (entrée/sortie standard). Pour les serveurs distants, on utilise HTTP avec server-sent events. La couche de transport est séparée du protocole lui-même, ce qui veut dire que de nouveaux mécanismes de transport peuvent être ajoutés sans changer la manière dont les outils sont définis.

Ce qui le distingue du function calling

Une question raisonnable est de savoir en quoi le MCP diffère des capacités de function calling que les modèles comme GPT-4 et Claude possèdent déjà. Le function calling vous permet de définir des outils dans votre requête API et le modèle générera des appels structurés vers ceux-ci. Cela fonctionne bien pour les développeurs d'application qui construisent des produits spécifiques.

Le MCP opère à un niveau différent. Au lieu de définir des outils requête par requête, les serveurs MCP sont des services autonomes que tout client IA compatible peut découvrir et utiliser. Un développeur construit un serveur MCP une fois, et il fonctionne avec Claude Desktop, Cursor, Windsurf et tout autre client qui prend en charge le protocole. Les définitions d'outils vivent avec le serveur, pas dans le code de l'application.

Cette distinction compte parce qu'elle sépare la création d'outil de sa consommation. La personne qui construit un serveur MCP Postgres n'a pas besoin de savoir quel assistant IA l'utilisera. Et la personne qui utilise Claude n'a pas besoin de comprendre comment fonctionne intérieurement le serveur Postgres. Elle se contente de le brancher et de commencer à poser des questions sur sa base de données.

Le modèle de sécurité

Le MCP adopte une approche de sécurité basée sur le consentement. Quand un serveur MCP propose des outils, le client IA présente ces outils à l'utilisateur. Avant d'exécuter le moindre appel d'outil, l'utilisateur doit l'approuver (ou configurer une auto-approbation pour les serveurs de confiance). Cela maintient les humains dans la boucle pour les opérations sensibles.

Le protocole prend également en charge l'authentification. Les serveurs MCP distants peuvent exiger des jetons OAuth ou des API keys, et le client gère le flux d'authentification. Cela veut dire qu'un serveur MCP pour l'API interne de votre entreprise peut imposer les mêmes contrôles d'accès qu'il imposerait à n'importe quel autre client.

Un défi sur lequel la communauté travaille encore est le sandboxing. Un serveur MCP mal écrit ou malveillant pourrait potentiellement accéder à des ressources auxquelles il ne devrait pas. La meilleure pratique actuelle est d'exécuter les serveurs non fiables dans des environnements isolés et de revoir attentivement les permissions que chaque serveur demande.

Pourquoi cela compte pour l'écosystème

L'impact pratique du MCP, c'est qu'il a créé un socle commun pour le développement des outils IA. Avant le MCP, le nombre d'outils disponibles pour un assistant IA donné était limité par le nombre d'intégrations que quelqu'un avait construites spécifiquement pour lui. Après le MCP, le nombre d'outils disponibles croît avec l'écosystème entier.

Au début 2026, plus de 10 000 serveurs MCP sont disponibles à travers divers registres et répertoires. Ils couvrent tout, de l'accès aux bases de données à la gestion de fichiers en passant par les intégrations API avec des services populaires. Une telle échelle n'aurait pas été possible sans un protocole commun.

Pour les développeurs, le MCP signifie que vous pouvez construire un outil une fois et le voir fonctionner partout. Pour les utilisateurs, cela signifie que l'assistant IA que vous choisissez ne limite pas les outils que vous pouvez utiliser. Et pour le secteur dans son ensemble, cela signifie que l'énergie qui partait dans la construction d'intégrations redondantes peut maintenant aller dans la construction de meilleurs outils.

Lectures complémentaires

Parcourez les serveurs MCP sur Skillful.sh. Cherchez plus de 137 000 outils IA sur Skillful.sh.