MCP distant

Qu’est-ce qu’un serveur MCP distant ?

Un serveur MCP distant expose des données, des outils et des capacités d’automatisation aux agents IA, notamment les grands modèles de langage (LLMs) et les systèmes agentiques, via un protocole standardisé. Contrairement aux serveurs locaux, les serveurs MCP distants sont hébergés dans le cloud ou sur Internet, accessibles par tout client IA ou workflow autorisé. Ils agissent comme un “adaptateur” universel pour connecter les agents IA à des API externes, des plateformes SaaS, des outils développeurs et des données d’entreprise.

• Valeur clé : dissocie l’intégration des outils et des données du développement des modèles IA, permettant des connexions sécurisées, évolutives et étendues entre les LLMs et le monde réel.
• Usage typique : récupérer des données en temps réel, invoquer des outils, et enchaîner des automatisations multi-étapes sans code personnalisé pour chaque outil.

Concepts et terminologie clés

Model Context Protocol (MCP)

Le Model Context Protocol (MCP) est un protocole ouvert qui standardise la façon dont les LLMs et les applications agentiques interagissent avec des outils et des données externes. Il établit un contrat universel pour la découverte des outils/ressources, la description des capacités, l’invocation des outils et l’échange de contexte entre clients et serveurs IA.

• Idées principales :
  • Capacités (outils, ressources) décrites dans un schéma lisible par machine
  • Échange standardisé de contexte et d’actions
  • Plusieurs options de transport : stdio, HTTP, SSE, HTTP streamable
  • Authentification et autorisation sécurisées et granulaires

Serveurs MCP locaux vs distants

• Serveur MCP local : s’exécute sur la machine de l’utilisateur, communique via stdio ou un socket local. Confidentialité maximale des données, mais nécessite une configuration et une gestion locales.
• Serveur MCP distant : hébergé dans le cloud ou sur des serveurs publics, communique via HTTP/SSE. Géré de façon centralisée, accessible par tout client autorisé, où qu’il soit.

Clients MCP, Hôtes et Workflows agentiques

• Client MCP : le composant logiciel qui se connecte aux serveurs MCP et coordonne l’invocation des outils (ex. interface chatbot, plateforme d’automatisation, runtime LLM).
• Hôte MCP : l’environnement d’exécution du client (peut être une appli web, un IDE, une plateforme d’agents).
• Workflow agentique : processus de décision autonome d’un agent IA, découvrant dynamiquement et invoquant les outils exposés par les serveurs MCP pour atteindre les objectifs de l’utilisateur.

Server-Sent Events (SSE) et protocole HTTP

• SSE (Server-Sent Events) : protocole basé sur HTTP pour le streaming de mises à jour en temps réel du serveur vers le client. Utile pour le suivi pas à pas d’un LLM ou la progression d’un outil.
• HTTP streamable : alternative moderne et sans état au SSE. Utilise HTTP POST pour la communication client-serveur, et peut diffuser les réponses en streaming, améliorant la fiabilité et la compatibilité avec les infrastructures cloud modernes.

Authentification & Autorisation (OAuth 2.1)

• OAuth 2.1 : le protocole standard du secteur pour un accès sécurisé et délégué. Utilisé par les serveurs MCP distants afin que les utilisateurs puissent accorder des permissions précises et révocables aux agents IA, sans exposer de justificatifs.
• Points clés :
  • Pas de support du flux implicite hérité (pour la sécurité)
  • PKCE obligatoire (Proof Key for Code Exchange)
  • Stratégies modernes de jetons de rafraîchissement
  • Scopes pour un accès granulaire et minimal

Architecture d’un serveur MCP distant

Fonctionnement des serveurs MCP distants

1. Hébergement : déployé sur des plateformes cloud (ex. Cloudflare Workers, AWS, serveurs privés).
2. Exposition des capacités : encapsule des API tierces, bases de données ou outils internes, et les expose comme “outils” ou “ressources” MCP dans un schéma standard.
3. Connexion : les clients se connectent via HTTP(S), s’authentifient avec OAuth et démarrent une session sécurisée.
4. Communication :
   • Le client envoie des requêtes standardisées (ex. invocation d’outil, réflexion) via HTTP POST.
   • Le serveur répond et diffuse les mises à jour/résultats via SSE ou HTTP streamable.
5. Autorisation : l’utilisateur accorde l’accès via les flux OAuth, avec des scopes définis par outil, donnée ou opération.
6. Découverte & invocation : les clients listent dynamiquement les outils disponibles et les invoquent selon les besoins, permettant des workflows flexibles pilotés par l’IA.

Schéma d’architecture :

+---------------------+      HTTP/SSE      +---------------------+
|   Agent IA (Client) | <----------------> | Serveur MCP distant |
+---------------------+                    +---------------------+
             |                                         |
           OAuth (AuthN/AuthZ)                 Service/API externe
             |                                         |
      L'utilisateur accorde l'accès                (ex. API Jira, BD)

Comparatif d’architecture : Serveurs MCP locaux vs distants

Protocoles de transport : stdio, HTTP, SSE, HTTP streamable

• stdio : utilisé pour les serveurs MCP locaux (processus à processus ou socket local).
• HTTP/SSE : le client envoie des requêtes HTTP ; le serveur diffuse les réponses/événements via SSE.
• HTTP streamable : transport moderne et sans état sur HTTP POST, permettant un streaming robuste et compatible cloud.
• Avantages du HTTP streamable : meilleure scalabilité, compatible avec les proxies, prend en charge les réponses chunkées/streamées, évite les limitations des anciens navigateurs.

Cas d’usage et exemples

Intégration LLM et workflows agentiques

Exemple : le serveur MCP distant d’Atlassian connecte Jira et Confluence à Claude ou d’autres LLMs. L’agent peut :

• Résumer des tickets ou de la documentation
• Créer ou modifier des éléments de travail directement depuis le chat
• Enchaîner des workflows multi-étapes (ex. création en masse de tâches, extraction d’objectifs, mise à jour des statuts en une seule fois)

Automatisation inter-outils

Exemple : un agent marketing intègre trois serveurs MCP différents :

• CMS : rédige ou met à jour des pages web
• Analytics : récupère les données de trafic/conversion
• SEO : effectue des audits, suggère des optimisations

L’agent enchaîne les appels à tous les serveurs dans un workflow (“Résume la performance du blog d’hier et propose des améliorations”).

SEO, contenu et automatisation web

Exemple : un serveur MCP distant expose une API d’audit SEO. Un agent IA peut :

• Récupérer et analyser des pages web en direct
• Auditer les données structurées, balises meta
• Retourner des rapports/actionnables SEO

Accès aux données d’entreprise et opérations développeur

Exemple : l’équipe DevOps expose le statut CI/CD, le suivi des incidents et les contrôles de déploiement via un serveur MCP interne. Les agents IA peuvent :

• Vérifier le statut des builds/déploiements
• Déclencher des rollbacks ou redémarrages
• Ouvrir des tickets/incidents, résumer les logs

Fonctionnalités principales et avantages

Atouts

• Protocole universel : un seul standard pour connecter tout agent IA à tout outil ou service.
• Scalabilité : gère de nombreux clients et un haut débit dans des environnements cloud.
• Sécurité : OAuth 2.1 garantit des permissions granulaires et révocables.
• Aucune configuration locale : les utilisateurs n’ont qu’à se connecter et accorder l’accès.
• Contrôle centralisé : les entreprises peuvent gouverner l’accès depuis un point unique.
• Intégration rapide : pas besoin de code personnalisé par outil ; les outils s’enregistrent avec le schéma MCP.

Limites et compromis

Sécurité et autorisation

Intégration OAuth

Les serveurs MCP distants utilisent OAuth 2.1 pour une authentification/autorisation sécurisée et déléguée :

• L’utilisateur accorde l’accès : le client IA lance le flux OAuth, l’utilisateur approuve les scopes/capacités.
• Émission de jeton : le serveur MCP émet son propre jeton d’accès à durée de vie courte, sans jamais exposer les identifiants du fournisseur en amont.
• Permissions granulaires : seuls les outils/actions pré-approuvés sont disponibles pour les agents.

Bonnes pratiques :

• Aucun flux implicite (supprimé dans OAuth 2.1)
• Imposer PKCE pour tous les flux
• Utiliser les jetons de rafraîchissement de façon sécurisée

Risques de sécurité : empoisonnement des outils et agence excessive

• Empoisonnement des outils : des attaquants peuvent injecter des instructions malveillantes dans les métadonnées des outils, trompant les LLMs pour divulguer des données ou effectuer des actions nuisibles.
  • Contremesures : assainir toutes les descriptions d’outils, valider les entrées, restreindre les métadonnées des outils aux sources de confiance.
• Agence excessive : une exposition trop permissive des outils permet des actions non désirées ou dangereuses par les agents IA.
  • Contremesures : utiliser des scopes minimalistes, revoir régulièrement l’exposition des outils.

Bonnes pratiques

• N’exposer que les capacités minimales et nécessaires
• Mettre en place une validation/assainissement robuste pour toutes les métadonnées d’outils et entrées utilisateur
• Utiliser des jetons à durée de vie courte, émis par le serveur
• Auditer et journaliser toutes les requêtes/réponses
• Revoir et mettre à jour régulièrement les scopes OAuth