Construire un agent IA avec le Model Context Protocol (MCP)

Chaque intégration d’un LLM à un outil externe (une base de données, une API interne, un système de fichiers) a longtemps demandé une intégration sur mesure. Le Model Context Protocol (MCP) standardise cette connexion : un même serveur MCP peut être branché à n’importe quel client compatible, sans réécrire l’intégration à chaque fois. Voici un panorama pratique pour concevoir un serveur MCP.

Sommaire

1. Qu’est-ce que le Model Context Protocol
2. Tools, Resources et Prompts
3. Anatomie d’un serveur MCP minimal
4. Transport : stdio vs HTTP
5. Sécurité et permissions
6. Cas d’usage concrets

Qu’est-ce que le Model Context Protocol

MCP est un protocole ouvert qui définit comment un agent IA (le « client ») découvre et invoque des capacités exposées par un « serveur » externe — outils, données, invites préconçues — via une interface standardisée. Plutôt que d’écrire une intégration spécifique pour chaque agent qui doit accéder à un même système (une base de données, un CRM, un système de fichiers), un seul serveur MCP suffit : tout client compatible avec le protocole peut s’y connecter.

Tools, Resources et Prompts

Un serveur MCP expose trois types de capacités. Les tools sont des fonctions que l’agent peut appeler avec des paramètres (rechercher un enregistrement, créer une tâche, exécuter une requête) — l’équivalent du function calling classique. Les resources exposent des données en lecture, adressables par une URI, que le client peut choisir d’inclure dans le contexte de la conversation. Les prompts sont des modèles de requêtes réutilisables, paramétrables, que l’utilisateur peut invoquer explicitement plutôt que de les taper en clair.

Anatomie d’un serveur MCP minimal

Un serveur MCP minimal déclare ses tools avec un nom, une description et un schéma de paramètres (généralement en JSON Schema), puis implémente la logique appelée lorsqu’un client invoque ce tool. Les SDK officiels (TypeScript, Python) gèrent la sérialisation du protocole et laissent le développeur se concentrer sur la logique métier : une fonction rechercher_client(nom: string) qui interroge une base de données et retourne un résultat structuré, par exemple.

Transport : stdio vs HTTP

MCP définit plusieurs mécanismes de transport. Le transport stdio (entrée/sortie standard) convient à un serveur lancé localement par le client, communiquant en processus enfant — le cas le plus simple pour un outil utilisé sur son propre poste. Le transport HTTP (avec Server-Sent Events pour le flux de réponses) convient à un serveur distant, partagé entre plusieurs utilisateurs ou déployé indépendamment du client — pertinent dès qu’un serveur MCP doit être accessible en dehors d’une seule machine.

Sécurité et permissions

Un tool MCP capable d’écrire des données (créer, modifier, supprimer) doit systématiquement passer par une étape de confirmation explicite côté client avant exécution — le protocole prévoit cette distinction entre lecture et action à effet de bord. Côté serveur, chaque tool doit valider ses paramètres d’entrée aussi rigoureusement qu’un endpoint d’API classique : un agent IA qui construit ses appels n’est pas plus digne de confiance qu’un utilisateur humain quant à la validation des données reçues.

Cas d’usage concrets

Les cas d’usage les plus fréquents : connecter un agent à un CRM ou un ERP interne pour qu’il puisse consulter et mettre à jour des fiches sur demande ; exposer une base de connaissances documentaire en lecture pour du RAG piloté par l’agent plutôt que par un pipeline fixe ; ou encapsuler des outils internes (déploiement, monitoring, requêtes de base de données en lecture seule) pour qu’un agent de développement puisse les invoquer directement pendant une session de travail.

Chez Any In IT, nous concevons des serveurs MCP sur mesure pour connecter les agents IA de nos clients à leurs systèmes internes, avec une attention particulière portée à la validation des entrées et aux permissions sur les actions à effet de bord.