Qu'est-ce que MCP

MCP 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. Pour l'entreprise, c'est une économie concrète : les intégrations IA avec les systèmes de travail deviennent moins chères et plus rapides, et l'accès de l'agent aux données reste sous le contrôle explicite de l'entreprise. 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é

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

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

Pour qui MCP n'est (pas encore) adapté

MCP ne résout pas tout, et tout le monde n'en a pas besoin tout de suite :

• Un seul scénario dans un produit fermé. Si tout le workflow IA vit dans un outil avec intégrations intégrées (sans serveur maison ni plusieurs hosts), le protocole ajoute de l'infrastructure sans bénéfice réel.
• Pas de capacité pour maintenir un serveur. Un serveur MCP est un processus séparé à déployer, mettre à jour et surveiller. Sans développeur ou prestataire dédié à cet entretien, le risque dépasse le bénéfice.
• Un seul canal de données, sans intention de l'étendre. Si une intégration unique couvre déjà la tâche concernée et qu'aucune extension n'est prévue, construire un serveur MCP pour cela est un travail superflu.
• Vous avez besoin d'un résultat garanti, pas d'un outil de connexion. MCP standardise l'accès aux données et fonctions, mais ne répond pas de la qualité des réponses du modèle et ne remplace pas les tests d'un scénario avant la production.

Repère pratique pour l'entreprise : si les mêmes données ou outils seront nécessaires dans plus d'un produit IA à terme, MCP est rentable. Si le scénario est ponctuel et fermé, une intégration ciblée suffit.

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.

Si vous avez besoin d'aide pour le développement, l'intégration de l'IA ou la maintenance de site pour votre projet - contactez-moi.

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.

Termes de l'article

MCP — Model Context Protocol — protocole de contexte de modèle

production — live environment serving real users — environnement live avec de vrais utilisateurs

LLM — Large Language Model — grand modèle de langage

SSE — Server-Sent Events — flux d'événements unidirectionnel du serveur vers le navigateur via HTTP

function calling — model returning structured calls to functions — le modèle renvoie des appels de fonctions structurés

VPN — Virtual Private Network — réseau privé virtuel

orchestration — coordinating multiple services or workflow steps — coordination de plusieurs services ou étapes

fallback — backup path used when the primary option fails — voie de secours si l'option principale échoue

RAG — Retrieval-Augmented Generation — génération augmentée par récupération

Jira — Atlassian tool for issues, sprints, and delivery tracking — outil Atlassian pour tickets, sprints et livraison

open source — software with publicly available source code — logiciel au code source public