← Retour à la liste

Qu'est-ce que MCP

MCP (Model Context Protocol) est un protocole ouvert qui standardise la connexion des assistants IA aux données et outils externes. Au lieu d'une intégration distincte par service (GitHub, base de données, CRM, système de fichiers), on exécute un serveur MCP et le client - Cursor, Claude Desktop, Zed et autres - se connecte via un contrat unique. Ci-dessous : ce qu'est MCP, comment fonctionne l'architecture et pourquoi le protocole compte en production.

Définition en termes simples

Le Model Context Protocol est une spécification d'échange entre une application IA (host) et une source de contexte externe (serveur). Un serveur peut exposer :

  • Resources - données lisibles : fichiers, lignes de BD, documents API
  • Tools - actions que le modèle peut appeler : requêtes API, SQL, recherche d'index
  • Prompts - modèles de prompt prêts pour des scénarios courants

Le protocole est ouvert et non lié à un seul fournisseur de LLM. Le host choisit le modèle ; le serveur MCP choisit quelles données et outils fournir. La communication utilise JSON-RPC 2.0 avec transport stdio, HTTP ou SSE.

L'idée d'Anthropic (novembre 2024) : remplacer un « zoo » de plugins sur mesure par une façon unique de brancher le contexte aux agents.

Architecture : host, client, server

Schéma typique à trois rôles :

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  MCP Host   │────▶│ MCP Client  │────▶│ MCP Server  │
│ (Cursor,    │     │ (dans       │     │ (GitHub,    │
│  Claude)    │     │  l'app)     │     │  Postgres…) │
└─────────────┘     └─────────────┘     └─────────────┘
  • MCP Host - application avec LLM : IDE, client de chat, plateforme d'agents. Gère la session, appelle le modèle et décide quand invoquer un tool.
  • MCP Client - composant dans le host qui parle à un ou plusieurs serveurs via MCP.
  • MCP Server - processus ou service qui expose resources, tools et prompts. Peut être local (fichiers sur disque) ou distant (API d'entreprise).

Un host peut avoir plusieurs clients - un par serveur MCP. Dans Cursor, par exemple, des serveurs pour le système de fichiers, le navigateur, GitHub et des MCP personnalisés du config peuvent tourner en parallèle.

Ce que MCP apporte en pratique

Un contrat au lieu de N intégrations

Avant MCP, chaque produit écrivait ses connecteurs : son format pour « lire un fichier », un autre pour « appeler une API ». MCP fixe :

  • comment les outils sont déclarés (nom, schéma de paramètres, description)
  • comment les résultats sont renvoyés
  • comment les resources sont demandées et les abonnements aux changements

Le même serveur MCP PostgreSQL peut servir Claude Desktop et un autre host s'il supporte le protocole.

Sécurité et limites d'accès

Le serveur tourne dans un processus ou conteneur séparé. Le host n'accède pas à tout le système - seulement à ce que le serveur expose explicitement. En entreprise, c'est important : donner à l'agent un accès lecture seule à un datamart sans accès complet à la BD de production.

Scénarios locaux et cloud

  • Local - transport stdio : le host lance le binaire serveur en processus fils (typique IDE et clients desktop).
  • Distant - HTTP/SSE : serveur MCP partagé en VPN ou cloud pour toute l'équipe.

Les deux sont dans la spec ; le choix dépend de la politique de sécurité et de l'emplacement des données.

MCP et function calling

Le function calling (tool use) est le mécanisme côté LLM : le modèle renvoie une demande structurée « appeler la fonction X avec les arguments Y ». MCP est une couche plus basse et plus large : elle standardise d'où viennent ces fonctions et données, comment elles sont enregistrées et comment le host communique avec elles.

Flux d'interaction :

  1. Le host se connecte au serveur MCP et obtient la liste des tools.
  2. La liste est passée au modèle au format du fournisseur (OpenAI tools, Anthropic tools, etc.).
  3. Le modèle choisit un tool ; le host exécute l'appel via MCP client → server.
  4. Le résultat revient dans le contexte du modèle pour l'étape suivante.

MCP ne remplace pas le raisonnement du modèle - il unifie le « câblage » entre l'agent et le monde extérieur.

Où MCP est déjà utilisé

Environnement Rôle de MCP
Cursor Serveurs MCP intégrés et personnalisés : fichiers, terminal, navigateur, APIs tierces
Claude Desktop Connecteurs officiels et serveurs communautaires via claude_desktop_config.json
Zed, Continue, Cline Support MCP pour étendre le contexte dans l'éditeur
Agents enterprise Serveurs maison sur APIs internes, tickets, wikis

La communauté publie des serveurs prêts : GitHub, Google Drive, Slack, Puppeteer, SQLite, Postgres, Brave Search et des centaines d'autres dans des registres comme modelcontextprotocol/servers sur GitHub.

Comment créer ou connecter un serveur MCP

Chemin minimal pour les développeurs :

  1. Choisir un SDK : bibliothèques officielles pour TypeScript, Python, C#, Java et autres.
  2. Décrire tools et resources dans le code serveur (nom, inputSchema, handler).
  3. Lancer le serveur avec transport stdio ou HTTP.
  4. Ajouter la config dans le host (dans Cursor - .cursor/mcp.json ou réglages IDE).

Exemple de logique tool en Python (simplifié) :

@server.tool()
async def get_weather(city: str) -> str:
    """Météo actuelle pour une ville."""
    return await weather_api.fetch(city)

Au démarrage de session le host demande les capabilities du serveur ; le modèle voit get_weather avec description et schéma JSON du paramètre city.

Les équipes sans dev dédié se contentent souvent d'un serveur du registre plus config et secrets (clés API via env, pas dans le dépôt).

Limites et points de vigilance

MCP résout la standardisation des connexions, mais pas :

  • la qualité du raisonnement du modèle
  • l'orchestration de workflows complexes multi-étapes (territoire des frameworks d'agents)
  • l'autorisation entre utilisateurs (couche OAuth/RBAC séparée sur le serveur nécessaire)

En pratique, tenir compte de :

  • Latence - chaque tool call est un aller-retour ; des chaînes de 10+ appels demandent un budget temps et tokens.
  • Versioning - serveurs et hosts doivent s'aligner sur la version de spec (2025-03 et suivantes évoluent activement).
  • Fiabilité - un serveur MCP en panne coupe l'accès aux données ; en production il faut health checks et fallback.

MCP vs RAG vs APIs sur mesure

Approche Force Faiblesse
MCP Tools/resources standard pour tout host Support MCP requis dans le client
RAG Recherche dans de gros corpus sans tout charger en contexte Pas d'actions arbitraires (write, mutation API)
API sur mesure Contrôle total Duplication de travail par client IA

Les systèmes matures utilisent souvent MCP + RAG : RAG pour la connaissance documentaire, MCP tools pour requêtes live sur BD, tickets, déploiements.

Synthèse

MCP est un protocole de contexte ouvert pour agents IA : le host se connecte aux serveurs, obtient resources et tools, le modèle les invoque via un contrat unique. Cela réduit le coût d'intégration, facilite le portage de scénarios entre Cursor, Claude Desktop et autres clients, et pose des limites claires d'accès aux données.

Ordre pratique pour les développeurs : commencer par des serveurs communautaires pour votre stack, puis encapsuler les APIs internes dans votre propre serveur MCP quand les mêmes tools servent dans plusieurs apps host.

Questions fréquentes

En quoi MCP diffère-t-il d'une API REST classique ?

Une API REST est l'interface d'un service précis pour vos appels HTTP. MCP est un protocole entre le host IA et un « adaptateur » vers ces services : il décrit comment le host découvre les tools, les appelle et lit les resources dans un format compréhensible par l'agent. Un serveur MCP peut envelopper les API REST GitHub ou Jira ; le host n'écrit pas une intégration distincte par produit.

Ai-je besoin de MCP si je n'utilise qu'un seul chat (par ex. ChatGPT) ?

Si tout le flux vit dans un produit fermé avec plugins intégrés - pas forcément. MCP vaut le coup avec plusieurs hosts (IDE + desktop + agent maison), pour réutiliser les mêmes tools ou garder des données sensibles sur votre serveur avec contrôle d'accès explicite.

Est-il sûr de connecter des serveurs MCP à des données de travail ?

Cela dépend du serveur et de la configuration. Serveurs de confiance de la communauté en open source, accès lecture seule et secrets via variables d'environnement - minimum de base. En production : processus séparé, moindre privilège, audit des tool calls, pas d'accès écriture de l'agent sans validation humaine.

Puis-je utiliser MCP avec des modèles locaux (Ollama, LM Studio) ?

Oui, si le host supporte MCP et votre fournisseur local. MCP n'est pas lié à une API cloud - il fournit contexte et tools ; le modèle peut être local. La limite est côté host : tous les clients ne combinent pas aussi bien LLM local et jeu complet de MCP tools.

Par où commencer la configuration MCP dans Cursor ?

  1. Ouvrir les réglages MCP dans Cursor (ou .cursor/mcp.json dans le projet).
  2. Ajouter un serveur prêt de la doc (ex. filesystem, GitHub) avec commande de lancement et env pour les tokens.
  3. Redémarrer Cursor et vérifier que le serveur est connected.
  4. Dans le chat agent, demander explicitement d'utiliser un tool - vérifier que l'appel fonctionne et que le résultat apparaît dans la réponse.

Ensuite, ajouter un serveur personnalisé pour votre API interne - vous verrez ainsi le cycle complet sans réécrire la logique d'intégration pour chaque outil.

Contact