Back

Comment exposer votre API existante aux LLM via MCP : Un guide complet

Comment exposer votre API existante aux LLM via MCP : Un guide complet

Intégrer des grands modèles de langage (LLM) à votre API existante peut être difficile. Traditionnellement, vous auriez besoin de connecteurs personnalisés ou de plugins spécifiques à une plateforme pour permettre l’accès de l’IA à votre service. Le Protocole de Contexte de Modèle (MCP) offre une meilleure solution.

Qu’est-ce que le protocole de contexte de modèle (MCP) ?

MCP est une norme ouverte d’Anthropic (maintenant un projet open-source) qui standardise la façon dont les assistants IA se connectent aux données externes et aux outils. Considérez MCP comme un adaptateur universel—un “port USB-C” pour les applications d’IA. Au lieu de créer des intégrations uniques pour chaque modèle ou plateforme, vous exposez votre API une seule fois via MCP, et n’importe quel LLM compatible avec MCP peut l’utiliser.

Principaux avantages de MCP

  • Standardisation : Remplacez les intégrations fragmentées par un protocole unique et cohérent
  • Réutilisabilité : Construisez votre connecteur d’API une seule fois comme serveur MCP, et plusieurs clients IA peuvent l’exploiter
  • Contrôle : Le serveur MCP s’exécute dans votre environnement, vous permettant d’appliquer la sécurité et de gérer exactement ce à quoi le modèle peut accéder

MCP agit comme un système de plugin universel pour les LLM, fournissant une méthode structurée permettant à une IA d’appeler des fonctions ou de récupérer des données depuis des sources externes.

Comprendre les primitives MCP

MCP utilise trois concepts principaux pour exposer des fonctionnalités :

  1. Ressources : Ce sont comme des points d’accès de données en lecture seule. Une ressource est identifiée par un URI (par exemple, todo://list) et fournit des données au modèle. Les ressources sont destinées à charger du contexte dans le modèle (comme récupérer un document, un enregistrement de base de données ou une liste de tâches). Elles sont similaires aux requêtes GET et ne modifient généralement pas l’état.
  2. Outils : Ce sont des actions ou opérations que le modèle peut invoquer—essentiellement des fonctions avec des paramètres et des valeurs de retour que le LLM peut appeler. Les outils peuvent avoir des effets secondaires ou effectuer des calculs. Considérez les outils comme des “fonctions que l’IA peut appeler”.
  3. Prompts : MCP permet de définir des modèles de conversation ou des flux de travail réutilisables. Les prompts sont comme des extraits de conversation prédéfinis que le serveur peut fournir au client.

En résumé : les ressources chargent des données pour le modèle, les outils exécutent des actions, et les prompts guident les interactions.

Implémentation : Guide étape par étape

Parcourons ensemble l’exposition d’une simple API REST à un assistant IA en utilisant MCP.

Étape 1 : Configurer un exemple d’API REST simple

Nous utiliserons une API basique de liste de tâches comme exemple. Voici une implémentation minimale utilisant Flask :

from flask import Flask, request, jsonify

app = Flask(__name__)
tasks = [ {"id": 1, "title": "Sample Task", "done": False} ]

@app.route('/tasks', methods=['GET'])
def get_tasks():
    # Return the full list of tasks
    return jsonify(tasks)

@app.route('/tasks', methods=['POST'])
def create_task():
    # Add a new task from the JSON request body
    data = request.get_json()
    new_task = {
        "id": len(tasks) + 1,
        "title": data.get("title"),
        "done": False
    }
    tasks.append(new_task)
    return jsonify(new_task), 201

# Run with: flask run

Cette API a deux points d’accès :

  • GET /tasks - Récupérer toutes les tâches
  • POST /tasks - Ajouter une nouvelle tâche

Dans un scénario réel, cela pourrait être n’importe quelle API existante avec une base de données en backend.

Étape 2 : Créer un serveur MCP pour encapsuler l’API

Maintenant, nous allons créer un serveur MCP en Python qui expose notre API de tâches à un LLM :

D’abord, installez le package MCP :

pip install "mcp[cli]"

Ensuite, créez un fichier nommé todo_mcp_server.py :

from mcp.server.fastmcp import FastMCP
import requests  # we'll use requests to call our REST API

# Initialize an MCP server with a descriptive name
mcp = FastMCP("To-Do API MCP Server")

# Define a Resource for reading tasks (like a GET endpoint)
@mcp.resource("todo://list")
def list_tasks() -> list:
    """Fetch all to-do tasks from the API."""
    response = requests.get("http://localhost:5000/tasks")
    response.raise_for_status()
    return response.json()  # return the list of tasks

# Define a Tool for adding a new task (like a POST operation)
@mcp.tool()
def add_task(title: str) -> dict:
    """Add a new task via the API and return the created task."""
    payload = {"title": title}
    response = requests.post("http://localhost:5000/tasks", json=payload)
    response.raise_for_status()
    return response.json()  # return the new task data

if __name__ == "__main__":
    mcp.run(transport="stdio")

Analysons ce qui se passe :

  • Nous créons une instance FastMCP nommée "To-Do API MCP Server", qui configure le serveur et enregistre nos outils/ressources.
  • Nous utilisons @mcp.resource("todo://list") pour exposer une ressource qui renvoie la liste des tâches. Cela correspond au point d’accès GET de notre API.
  • Nous utilisons @mcp.tool() pour exposer un outil qui ajoute une nouvelle tâche. Cela correspond au point d’accès POST de notre API.
  • Les docstrings pour chaque fonction sont importantes - le LLM verra ces descriptions lorsqu’il décidera comment utiliser les outils.
  • Nous exécutons le serveur avec mcp.run(transport="stdio"), qui communique en utilisant l’entrée/sortie standard (idéal pour le développement local).

À ce stade, nous avons un serveur MCP avec deux capacités : une ressource todo://list (pour obtenir les tâches) et un outil add_task (pour créer une tâche). Celles-ci correspondent aux fonctionnalités de notre API. En effet, nous avons encapsulé l’API REST avec MCP.

Étape 3 : Exécuter et tester le serveur MCP localement

Avant d’exécuter le serveur MCP, assurez-vous que votre API Flask est en cours d’exécution (par exemple, avec flask run).

Maintenant, démarrez le serveur MCP en mode développement :

mcp dev ./todo_mcp_server.py

La commande mcp dev lance un tableau de bord de développement interactif dans votre navigateur. Ce tableau de bord vous permet de :

  1. Voir le nom de votre serveur MCP et les outils/ressources disponibles
  2. Tester la ressource todo://list - elle devrait renvoyer la liste actuelle des tâches
  3. Tester l’outil add_task - entrez un titre de tâche et exécutez-le
  4. Vérifier les résultats et voir les journaux dans le panneau d’historique

Ce tableau de bord est inestimable pour le développement et le débogage. Il utilise le même protocole MCP qu’un véritable client LLM utiliserait, mais avec une interface graphique pour les tests.

Étape 4 : Connecter le serveur MCP à un client LLM

Maintenant, connectons un LLM actif à notre serveur MCP. Plusieurs assistants IA et outils prennent en charge MCP, notamment :

Connexion avec Claude Desktop

L’application Claude Desktop d’Anthropic prend en charge nativement les serveurs MCP locaux. Pour l’intégrer :

mcp install ./todo_mcp_server.py

Cela enregistre votre serveur auprès de Claude. Dans l’interface de Claude, vous devriez voir votre “To-Do API MCP Server” disponible. Maintenant, lorsque vous avez une conversation avec Claude, vous pouvez :

  • Demander : “Liste mes tâches à faire” - Claude utilisera la ressource todo://list
  • Demander : “Ajoute une tâche pour acheter du lait” - Claude utilisera l’outil add_task

Claude gérera l’exécution du serveur MCP et le routage des requêtes lorsque l’IA décidera de l’utiliser.

Connexion avec l’IDE Cursor

Cursor est un éditeur de code avec un assistant IA qui prend en charge MCP. Pour se connecter :

  1. Allez dans les paramètres de Cursor sous “Model Context Protocol”
  2. Ajoutez votre serveur MCP en fournissant le chemin vers todo_mcp_server.py
  3. Spécifiez le transport (stdIo)

Une fois connecté, Cursor détectera les outils et ressources de votre serveur. Vous pouvez alors poser à l’assistant Cursor des questions comme “Quelles tâches sont dans ma liste de choses à faire ?” ou “Ajoute ‘écrire un article de blog’ à mes tâches.”

Notes générales sur les clients LLM

Les étapes exactes de connexion varient selon le client :

  • Pour Claude Desktop, utilisez mcp install ou l’interface de l’application
  • Pour Cursor, configurez le serveur dans les paramètres
  • D’autres environnements peuvent avoir des approches différentes

Après la connexion, testez en incitant l’IA d’une manière qui encourage l’utilisation des outils. De nombreux clients MCP indiqueront visuellement quand l’IA utilise un outil.

Note de sécurité : Lorsque vous connectez un serveur MCP, le LLM aura accès à tout ce que ce serveur expose. Les serveurs MCP s’exécutent généralement localement ou au sein de votre infrastructure, ce qui est bon pour la sécurité. Si votre API nécessite une authentification, vous pouvez inclure ces identifiants dans le code de votre serveur MCP.

Comparaison de MCP avec les approches traditionnelles

Comparons comment l’utilisation de MCP pour exposer une API diffère des autres méthodes d’intégration :

Appels API LLM directs (Sans MCP)

Sans MCP, vous pourriez :

  • Utiliser l’appel de fonction ou des plugins spécifiques à une plateforme (liés à OpenAI ou à un environnement spécifique)
  • Intégrer les détails de l’API dans les prompts, ce qui est sujet aux erreurs - le modèle pourrait halluciner des points d’accès ou envoyer des formats incorrects

GraphQL ou autres langages de requête

Avec GraphQL, vous pourriez faire construire des requêtes par le LLM, mais :

  • Le modèle doit toujours connaître le schéma et la syntaxe de requête
  • Vous auriez probablement besoin d’une couche d’intégration personnalisée pour vérifier les requêtes du modèle

L’avantage MCP

L’utilisation de MCP abstrait ces détails dans une interface standardisée :

  • Le LLM n’a pas besoin de connaître les méthodes HTTP ou la syntaxe des requêtes
  • Il interroge le serveur MCP pour les outils et ressources disponibles, qui ont des noms et descriptions lisibles par l’homme
  • Le processus se concentre sur les capacités plutôt que sur les appels de bas niveau
  • Le même serveur MCP fonctionne pour n’importe quel client qui prend en charge le protocole

Voici une comparaison détaillée :

Aspect Intégration API traditionnelle Intégration via MCP Standardisation Pas de standard unifié - chaque plateforme a sa propre méthode d’intégration ou format de plugin Un standard ouvert sur toutes les plateformes - construisez une fois, utilisez partout Découverte des actions Le LLM doit être informé des points d’accès/requêtes disponibles, ou ils sont codés en dur Les clients LLM peuvent lister programmatiquement les outils/ressources disponibles depuis un serveur MCP Accès aux données Les réponses API sont souvent envoyées via des prompts, atteignant les limites de contexte Les ressources MCP chargent les données directement dans le contexte du LLM de manière gérée Effort de codage Élevé - appels HTTP personnalisés, analyse et gestion des erreurs pour chaque modèle Simplifié - le SDK MCP gère les détails du protocole ; vous écrivez des fonctions Python Sécurité et contrôle Le modèle pourrait générer des appels HTTP arbitraires s’il n’est pas contraint Le serveur MCP agit comme un gardien - vous décidez exactement ce qui est exposé Flexibilité Difficile à adapter à de nouveaux LLM ou cas d’utilisation Très flexible - les modèles peuvent orchestrer plusieurs appels MCP ; ajoutez facilement de nouveaux outils

En bref, MCP offre une couche plus adaptée à l’IA par-dessus votre API. Plutôt que de traiter des appels HTTP bruts, le modèle interagit avec des actions et des données nommées qui ont du sens dans la conversation.

Conclusion

Exposer votre API REST existante aux LLM via MCP peut grandement simplifier l’intégration. Au lieu de créer des connexions uniques pour chaque plateforme d’IA, vous implémentez le Protocole de Contexte de Modèle une seule fois et gagnez en compatibilité avec n’importe quel client le supportant.

MCP fournit une manière standardisée, sécurisée et flexible de faire le pont entre l’IA et vos données. Il transforme votre API en un composant modulaire que n’importe quelle IA avancée peut utiliser de manière responsable et intelligente. Cela ouvre de nouvelles possibilités : votre assistant alimenté par LLM pourrait combiner votre API avec d’autres connecteurs MCP, le tout dans le même cadre unifié.

FAQ

Oui. MCP est assez flexible – vous pouvez encapsuler n'importe quelle API ou service externe tant que vous pouvez écrire du code pour y accéder. Que votre API renvoie du JSON, XML ou autre chose, vous pouvez le traiter en Python et renvoyer un type de données Python (MCP se chargera de le sérialiser pour le LLM).

Le LLM lui-même ne 'parle' pas intrinsèquement MCP – c'est la combinaison du modèle et d'un client MCP qui permet cela. En 2025, Claude, Cursor, Zed, Replit et d'autres intègrent des clients MCP. Il existe également une bibliothèque cliente Python officielle si vous souhaitez scripter une interaction entre un LLM et un serveur MCP sans client UI complet.

Ils répondent à des objectifs similaires – permettre à une IA d'appeler des API externes – mais MCP est une norme ouverte et fonctionne avec différents systèmes d'IA. Les plugins ChatGPT sont propriétaires de l'interface ChatGPT d'OpenAI, et l'appel de fonction dans GPT-4 est spécifique à l'API d'OpenAI. Un serveur MCP peut servir de nombreux modèles/clients différents.

MCP est encore relativement nouveau mais mûrit rapidement. En termes de sécurité : comme MCP permet à une IA d'exécuter du code ou de récupérer des données, traitez votre serveur MCP avec la même prudence qu'une API. N'exposez que ce qui est nécessaire. L'IA ne peut appeler que les outils que vous avez définis, rien d'autre. Un avantage de MCP est que vous pouvez exécuter le serveur dans votre pare-feu ou localement, réduisant l'exposition.

Python dispose actuellement du SDK le plus mature, mais MCP est indépendant du langage. Le protocole lui-même (qui utilise généralement JSON-RPC sur stdio ou SSE) peut être implémenté dans n'importe quel langage. Il existe des SDK et des exemples dans d'autres langages, notamment C# et JavaScript.

Absolument. Un serveur MCP peut exposer plusieurs outils et ressources, même s'ils concernent différents systèmes. Vous pourriez créer un seul serveur MCP avec des outils pour une API de tâches, une API météo et des ressources pour un fichier de base de données local. Alternativement, vous pourriez exécuter plusieurs serveurs MCP (un par service) et les connecter tous au client.