MCP : Protocole de contexte de modèle

Introduction

Si vous avez construit quoi que ce soit autour des LLM – chatbots, assistants internes, outils de développement – ​​vous vous êtes probablement heurté au même mur : le modèle est intelligent, mais il est « piégé ». Il ne peut pas récupérer directement les derniers chiffres de votre base de données, lire les fichiers de votre système ou déclencher de véritables flux de travail à moins que vous ne connectiez tout manuellement.

C’est là MCP (protocole de contexte de modèle) entre.

Protocole de contexte de modèle (MCP) est un protocole ouvert qui standardise la façon dont les applications d’IA se connectent à outils externes et sources de données – il n’est donc pas nécessaire de réinventer les intégrations pour chaque modèle, chaque application et chaque système. Les documents officiels le décrivent comme un moyen universel de connecter les applications LLM au contexte dont elles ont besoin, souvent comparé à un « port USB-C pour les applications IA ».

Dans ce blog, nous aborderons :

• Qu’est-ce que MCP en termes simples
• Comment fonctionne MCP (clients, serveurs, messages, transports)
• Pourquoi MCP est important pour les produits réels et les flux de travail d’entreprise
• Comment MCP connecte les modèles avec des outils et des données externes en toute sécurité
• Un modèle mental simple + un exemple de démarrage sur lequel vous pouvez vous appuyer

Ce que MCP résout réellement (en termes simples)

Avant MCP, la plupart des équipes connectaient les modèles aux outils à l’aide intégrations personnalisées :

• Un connecteur pour Google Drive
• Un autre pour Slack
• Un autre pour les API internes
• Un autre pour les bases de données
  … Et chaque application a réécrit encore et encore un code de colle similaire.

MCP renverse ce modèle.

Avec MCP, les fournisseurs d’outils/de données exposent les fonctionnalités via un serveur MCP, et les applications d’IA agissent comme des clients MCP capables de découvrir et d’appeler ces fonctionnalités de manière cohérente.

Pensez-y comme ceci :

• Apis standardisé la manière dont les applications Web communiquent avec les services
• PCM standardise la façon dont les applications d’IA communiquent avec les outils et les fournisseurs de contexte

Architecture MCP : Client ↔ Serveur

À un niveau élevé, MCP a deux rôles principaux :

1) Client MCP

Il s’agit de la couche d’application IA. Exemples : une application de chat, un assistant IDE, un robot d’entreprise interne.

Le client :

• Se connecte à un ou plusieurs serveurs MCP
• Découvre ce qu’ils proposent
• Demande le contexte ou exécute les actions de l’outilConclusion

2) Serveur MCP

Cela enveloppe un outil/source de données et l’expose via MCP.

Un serveur peut fournir :

• Accès aux fichiers
• Requêtes de base de données
• Outils de création de billets
• Récupération de la politique de l’entreprise
• Une fonction « recherche »
• Un coureur de workflow

Ce modèle client/serveur correspond explicitement à la manière dont MCP est décrit dans l’annonce originale et les documents d’apprentissage officiels.

Comment fonctionne MCP sous le capot

MCP utilise la messagerie JSON-RPC
MCP est construit sur JSON-RPC 2.0ce qui signifie que le client et le serveur communiquent à l’aide de messages de requête/réponse structurés (et peuvent également envoyer des notifications).

C’est important car cela rend les intégrations prévisibles :

• Les requêtes ont un identifiant, une méthode et des paramètres
• Les réponses renvoient un résultat ou une erreur
• Tout est lisible par machine et convivial

MCP prend en charge plusieurs transports

MCP peut fonctionner sur des transports Web standards tels que HTTP et HTTPS, ce qui facilite son déploiement dans les environnements cloud et d’entreprise.
L’utilisation de la communication basée sur HTTP permet aux serveurs MCP de fonctionner comme des services Web classiques, protégés par des mécanismes familiers tels que TLS, des passerelles API et des pare-feu.
Cela rend l’intégration avec l’infrastructure existante simple, sans nécessiter de configuration réseau particulière.
Le protocole étant indépendant du transport, la même logique MCP peut fonctionner sur HTTP aujourd’hui et évoluer demain avec les futures options de transport.

À emporter pratique : MCP peut fonctionner pour les outils de développement locaux et les services d’entreprise distants.

« Primitives » MCP : outils, ressources, invites

La plupart des développeurs se soucient de MCP en raison de ce qu’il expose au modèle. MCP formalise la manière dont les serveurs fournissent des « capacités » aux clients. Les directives officielles en matière d’architecture soulignent qu’il s’agit d’un niveau clé.

Primitives courantes que vous verrez :

Outils
Actions appelables que le modèle peut invoquer.
Exemples :

• search_ko (requête)
• create_jira_ticket (charge utile)
• run_sql(sql)
• résumé_document(doc_id)

Ressources

Contexte lisible que le modèle peut récupérer.
Exemples :

• Un document de politique
• Un chemin de fichier
• Un enregistrement de base de données
• Un article de la base de connaissances

Invites
Modèles d’invites réutilisables ou flux de travail guidés que le serveur peut fournir au client (utiles pour un comportement cohérent entre les équipes).

Flux de bout en bout : que se passe-t-il lorsqu’un utilisateur demande quelque chose ?
Voici une histoire simple de « ce qui se passe réellement » :

L’utilisateur demande : « Pouvez-vous créer un ticket informatique pour l’accès VPN et joindre les détails de mon ordinateur portable ? »

1. Le client reçoit le message de l’utilisateur
2. Le client décide qu’il a besoin d’actions externes (système de tickets + informations sur l’appareil)
3. Le client appelle un serveur MCP pour :
   • récupérer les détails de l’ordinateur portable/de l’appareil (ressource).
   • créer un ticket (outil)
4. Le serveur MCP répond avec des résultats structurés
5. Le client renvoie des résultats pertinents dans le modèle
6. Le modèle produit une réponse finale destinée à l’utilisateur (« Ticket créé : INC-12345 … »)

Idée d’illustration

Un diagramme simple : Utilisateur → Application AI (client MCP) → Serveur(s) MCP → Outils/Données → retour à l’application AI → Utilisateur

Pourquoi MCP est important (au-delà de « encore un autre protocole »)

1) Moins de travail d’intégration personnalisée
Au lieu d’écrire des connecteurs uniques pour chaque combinaison modèle/application/outil, MCP propose un contrat partagé.

2) Séparation plus nette des préoccupations

• Les fournisseurs d’outils se concentrent sur la création de serveurs
• Les équipes d’applications d’IA se concentrent sur l’expérience produit
• Vous pouvez échanger des modèles sans reconstruire toute la couche d’outils

3) De meilleurs flux de travail « agent »
Les agents ne se contentent pas de discuter : ils prennent des mesures, extraient du contexte et exécutent des étapes. MCP offre un moyen standardisé de le faire entre les systèmes.

4) La sécurité devient un sujet de premier ordre
L’accès aux outils est sensible. MCP propose des conseils explicites en matière de sécurité et d’autorisation (y compris des flux modernes de style OAuth dans ses documents/tutoriels).

Sécurité et contrôle d’accès : que faire dans des systèmes réels
Si vous exposez des outils puissants (comme « envoyer un e-mail », « exécuter SQL », « accéder aux fichiers RH »), la sécurité ne peut pas être une réflexion après coup.

Les directives de sécurité MCP couvrent les risques et les meilleures pratiques en matière d’autorisation et de fonctionnement sécurisé, y compris les demandes authentifiées par jeton.

Check-list pratique de sécurité :

• Préférer accès limité sur des jetons tout ou rien
• L’outil de journalisation des appels (qui, quoi, quand) pour l’auditabilité
• Valider et désinfecter les entrées (défense d’injection rapide)
• Utilisez HTTPS + stockage de jetons sécurisé le cas échéant
• Limiter les autorisations des outils par rôle (outils RH ≠ outils d’ingénierie)

Code : Construisez un petit serveur MCP en Python

Il s’agit d’un serveur MCP minimal utilisant l’assistant FastMCP

1) Installer les dépendances

# If you use uv (recommended in MCP docs)
uv venv
source .venv/bin/activate
uv add "mcp[cli]"

2) Créez mini_mcp_server.py

Cet exemple expose 2 outils :

• greet(name) – outil de démonstration simple
• add(a,b) – outil « d’action » de base

from mcp.server.fastmcp import FastMCP

# Name your server (clients will display this)
mcp = FastMCP("mini-tools")

@mcp.tool()
def greet(name: str = "World") -> str:
"""Return a friendly greeting."""
return f"Hello, {name}!"

@mcp.tool()
def add(a: int, b: int) -> int:
"""Add two integers."""
return a + b

def main():
# Use stdio transport for local MCP hosts (Claude Desktop, some IDE clients)
mcp.run(transport="stdio")

if __name__ == "__main__":
main()

Cela correspond au même modèle utilisé dans le didacticiel MCP : créez FastMCP, décorez les outils avec @mcp.tool(), puis mcp.run(transport= »stdio »).

3) Exécutez le serveur

uv run mini_mcp_server.py

À ce stade, votre serveur écoute via stdio un hôte/client compatible MCP.

Connectez-le à un client (exemple : config Claude Desktop)
De nombreuses personnes testent les serveurs MCP en les connectant à un hôte de bureau capable de découvrir des outils. Le didacticiel du serveur MCP montre comment ajouter une entrée de serveur MCP dans la configuration JSON de Claude Desktop, y compris la commande et les arguments.

Une configuration typique ressemble à cette forme :

{
"mcpServers": {
"mini-tools": {
"command": "uv",
"args": ["--directory", "/ABSOLUTE/PATH/TO/FOLDER", "run", "mini_mcp_server.py"]
}
}
}

Après avoir redémarré l’hôte, il devrait découvrir les outils exposés par votre serveur.

Ce que fait réellement le client (dans une courte liste de contrôle)

Lorsque vous demandez à l’IA quelque chose comme « Dites bonjour à Ashish et ajoutez 2 + 5 », le client :

1. Appels outils de liste sur le serveur MCP
2. Envoie votre message au LLM avec des descriptions d’outils
3. Le LLM décide s’il a besoin d’un appel d’outil
4. Le client exécute l’outil via MCP
5. Les résultats des outils sont renvoyés au LLM
6. La réponse finale est affichée à l’utilisateur

C’est l’idée clé : le modèle n’appelle pas directement votre base de données. Le client orchestre et MCP standardise cette connexion.

Conclusion

MCP est un changement pratique dans la façon dont nous connectons l’IA à la réalité.

Au lieu de procéder aux intégrations une par une, MCP vous propose un protocole partagé dans lequel :

• Les serveurs exposent les outils et les données de manière cohérente
• Les clients (applications IA) les découvrent et les utilisent de manière fiable
• Le modèle obtient de meilleures réponses car il peut extraire un contexte réel et prendre de vraies actions
• La sécurité et la gouvernance peuvent être intégrées dès le départ au flux de travail