Le protocole MCP

Les modèles d’intelligence artificielle ne sont aussi performants que le contexte dans lequel ils évoluent.Un modèle peut être extrêmement puissant, mais sans les bonnes informations, il sera inefficace.

• Les API connectent les applications aux services backend.
• Le LSP connecte les IDE aux outils de langage.
• Le MCP connecte les IA à tout leur écosystème contextuel.

Sans MCP, chaque application devait maintenir à jour une implémentation spécifique avec des appels spécifiques à des tools.

MCP apporte un développement IA standardisé :

• Pour les développeurs d’applications IA : Connectez votre application à n’importe quel serveur MCP sans travail supplémentaire.
• Pour les développeurs d’outils ou d’API : Construisez un serveur MCP une seule fois, adoptez-le partout.
• Pour les utilisateurs finaux : Des applications IA plus puissantes et enrichies en contexte.
• Pour les entreprises : Une séparation claire des responsabilités entre les équipes produits IA.

MCP est juste un protocole client-server ou l’application joue le rôle du client (aussi appelé host) et ainsi le serveur expose des outils, ressources (documents) et prompts.

‍

‍

FAST MCP

FastMCP est un framework conçu pour faciliter la création de serveurs conformes au Model Context Protocol (MCP). MCP étant un standard permettant aux applications d’intelligence artificielle d’interagir avec des données et des outils externes de manière sécurisée et standardisée, FastMCP vise à accélérer et simplifier ce processus d’intégration pour les développeurs. En utilisant FastMCP, les développeurs peuvent rapidement exposer des outils (fonctions exécutables), des ressources (données accessibles) et des invites (modèles de prompts) à des modèles de langage ou à des applications compatibles MCP.

L’un des principaux avantages de FastMCP réside dans sa capacité à abstraire la complexité du protocole MCP lui même. Plutôt que de devoir implémenter manuellement la logique de communication client serveur, la sérialisation/désérialisation des messages, la gestion des différents types de requêtes (outils, ressources, prompts) et potentiellement les subtilités des transports stdio ou SSE, le développeur peut s’appuyer sur le framework.

FastMCP propose généralement une syntaxe claire et intuitive, souvent inspirée des frameworks web modernes comme FastAPI (auquel son nom fait probablement référence). Cela se traduit typiquement par :

• Approche déclarative : Utilisation de décorateurs (par exemple, @tool, @resource) pour enregistrer simplement des fonctions ou des classes Python comme des composants MCP.
• Validation automatique des données : Intégration fréquente avec des bibliothèques comme Pydantic pour utiliser les ‘type hints‘ Python afin de définir la structure des données attendues et retournées, et pour valider automatiquement les échanges, réduisant ainsi les erreurs.
• Gestion intégrée du protocole : Le framework gère en arrière plan les détails de la communication MCP, permettant au développeur de se concentrer uniquement sur la logique métier de l’outil ou de la ressource qu’il souhaite exposer.
• Support potentiel des transports : Un bon framework FastMCP pourrait offrir un support intégré pour démarrer le serveur en mode stdio ou SSE avec une configuration minimale.

Pour illustrer concrètement la simplicité offerte par FastMCP, voici un exemple minimaliste en Python qui crée un serveur MCP exposant un unique outil capable d’additionner deux nombres :

‍

‍

Analyse de l’exemple :

• Ligne 2 : Nous importons la classe FastMCP, qui est le point d’entrée du framework.
• Ligne 5 : Une instance du serveur est créée. Le nom "Add" pourrait être utilisé par le client pour identifier ce serveur spécifique.
• Ligne 8 (@mcp.tool()) : C’est ici que la magie opère. Ce décorateur transforme la simple fonction Python add définie juste en dessous en un Outil MCP. FastMCP s’occupera de rendre cette fonction découvrable par les clients MCP et de gérer les appels vers elle. C’est un exemple parfait de l’approche déclarative.
• Ligne 9 (def add...) : Il s’agit d’une définition de fonction Python standard. Elle contient la logique métier : additionner a et b.
• Type Hints (a: int, b: int -> int) : Les annotations de type sont cruciales. FastMCP les utilise pour :
  • Définir le "schéma" de l’outil : quels arguments il accepte et quel type de résultat il retourne.
  • Valider automatiquement les données reçues du client. Si le client envoie autre chose qu’un entier pour a ou b, FastMCP peut rejeter la requête avant même que la fonction add ne soit exécutée.
  • Gérer la sérialisation/désérialisation entre les types Python et le format attendu par le protocole MCP.
• Ligne 10 (Docstring) : La chaîne de documentation ("""Additionne deux nombres entiers.""") est souvent utilisée par le framework pour générer la description de l’outil qui sera présentée au client ou au modèle IA.

Cet exemple démontre comment, avec très peu de code (principalement du Python standard, un décorateur et des type hints), FastMCP permet de créer un serveur MCP fonctionnel. Toute la complexité de la gestion du protocole, de la communication et de la validation est prise en charge par le framework, permettant au développeur de se concentrer sur l’implémentation de la fonctionnalité (ici, une simple addition).

Méthodes disponibles (publiques) sur FastMCP :

• add_tool(name, function, description, schema) : Méthode pour ajouter programmatoirement un outil (une fonction exécutable) au serveur. Le serveur pourra ensuite exposer cet outil aux clients MCP.
• add_resource(name, data_or_provider, description, schema) : Méthode pour ajouter programmatoirement une ressource (donnée accessible) ou un fournisseur de ressource au serveur.
• add_prompt(name, template, description) : Méthode pour ajouter programmatoirement un modèle de prompt (texte pré défini) au serveur.
• tool(...) : Décorateur (@mcp.tool()) à placer au dessus d'une fonction Python pour l'enregistrer automatiquement comme un outil MCP (comme dans l'exemple de l'article). Plus courant dans FastMCP que add_tool.
• resource(...) : Décorateur (@mcp.resource()) pour enregistrer une fonction ou une classe comme une ressource ou un fournisseur de ressources MCP.
• prompt(...) : Décorateur (@mcp.prompt()) pour enregistrer une chaîne de caractères ou une fonction générant un texte comme un prompt MCP.

Opérations du serveur (Répondre aux requêtes du client) :

• call_tool(tool_name, args) : Méthode interne au serveur qui est déclenchée lorsqu'un client demande à exécuter un outil spécifique. Elle trouve l'outil par son nom, lui passe les arguments fournis par le client, exécute la fonction associée et renvoie le résultat au client.
• get_context() : Méthode interne répondant à la demande du client pour obtenir la liste complète de tous les outils, ressources et prompts actuellement disponibles sur ce serveur.
• get_prompt(prompt_name) : Méthode interne pour récupérer et renvoyer le contenu d'un prompt spécifique demandé par le client.
• list_prompts() : Méthode interne répondant à la demande du client pour lister les noms et descriptions des prompts disponibles.
• list_resource_templates() : Méthode interne pour lister les types ou modèles de ressources disponibles (ex: "fichier", "contact CRM").
• list_resources() : Méthode interne pour lister les instances spécifiques de ressources actuellement accessibles (ex: "/home/user/doc.txt", "Contact ID 123"). La différence avec le précédent est subtile et dépend de l'implémentation.
• list_tools() : Méthode interne répondant à la demande du client pour lister les noms, descriptions et schémas (paramètres attendus, type de retour) des outils disponibles.
• read_resource(resource_name) : Méthode interne qui gère la lecture et le renvoi du contenu d'une ressource spécifique (ex: contenu d'un fichier) demandée par le client.

Gestion du serveur (Lancement et configuration) :

• run(...) : Méthode principale pour démarrer le serveur MCP. Elle pourrait détecter ou prendre en paramètre le type de transport (stdio ou SSE) et lancer la boucle d'écoute appropriée.
• run_sse_async(...) : Lance spécifiquement le serveur en mode SSE (Server Sent Events) sur HTTP, de manière asynchrone. Adapté pour les serveurs réseau.
• run_stdio_async(...) : Lance spécifiquement le serveur en mode stdio (entrée/sortie standard), de manière asynchrone. Adapté pour les serveurs locaux gérés par l'application cliente.
• sse_app(...) : Pourrait exposer l'objet application web sous jacent (par exemple, une instance FastAPI ou Starlette) utilisé lorsque le serveur tourne en mode SSE. Cela permettrait une intégration plus poussée ou l'ajout de routes non MCP si nécessaire.

TYPES DE TRANSPORTS MCP

Le protocole MCP définit deux mécanismes de transport principaux pour la communication entre le client (l’application IA) et le serveur MCP. Le choix du transport dépend de l’endroit où le serveur s’exécute et de la manière dont il est géré.

Transport stdio (Standard Input/Output)

Ce mode de transport est conçu pour les serveurs qui s’exécutent localement sur la même machine que l’application cliente.

• Exécution locale : Le serveur est un processus lancé sur la machine de l’utilisateur.
• Gestion automatique : Typiquement, l’application cliente (comme Cursor) est responsable du démarrage et de l’arrêt du processus serveur.
• Communication directe : L’échange de données se fait via les flux d’entrée standard (stdin) et de sortie standard (stdout) du processus serveur.
• Accès local uniquement : Par nature, ce serveur n’est accessible que par l’application cliente sur la machine locale.
• Configuration : Le client est configuré avec la commande shell nécessaire pour lancer le serveur (par exemple, en utilisant npx pour un serveur Node.js ou python pour un serveur Python).

Transport SSE (Server Sent Events)

Ce mode de transport utilise le protocole Server Sent Events sur HTTP(S), permettant une communication réseau.

• Exécution locale ou distante : Le serveur peut tourner sur la machine locale ou sur un serveur distant.
• Gestion manuelle : L’utilisateur est responsable du démarrage, de l’arrêt et de la gestion du serveur. Il doit s’assurer que le serveur est accessible via le réseau si nécessaire.
• Communication réseau : L’échange de données se fait via des requêtes HTTP vers un point de terminaison spécifique (généralement /sse).
• Partage possible : Un serveur SSE peut être partagé entre plusieurs machines ou utilisateurs s’il est exposé sur le réseau.
• Configuration : Le client est configuré avec l’URL complète du point de terminaison /sse du serveur MCP.

En résumé, le transport stdio est idéal pour une intégration simple et locale gérée par l’application, tandis que le transport SSE offre la flexibilité nécessaire pour les serveurs distants, partagés ou gérés indépendamment.

‍

‍