Serveurs MCP

Définition

Qu’est-ce qu’un serveur MCP ?

Un serveur MCP est la porte d’entrée d’un système vers les modèles. Il décrit, dans un format que le modèle comprend, les actions disponibles et les données lisibles, puis il exécute les appels que l’application hôte lui transmet. Le système d’origine (base, CRM, CMS, service interne) reste inchangé derrière.

L’intérêt du protocole tient en un mot : la standardisation. Sans lui, chaque intégration entre une IA et un outil métier est un développement spécifique, à refaire pour chaque application cliente. Avec lui, vous décrivez vos capacités une fois.

Un serveur MCP n’ajoute aucune intelligence. Il n’interprète pas la demande de l’utilisateur et ne décide pas de la stratégie. Il expose un périmètre, exécute, renvoie un résultat. Le raisonnement reste du côté de l’agent IA.

Hôte, client et serveur : les rôles dans le Model Context Protocol

L’architecture MCP repose sur trois rôles distincts, et confondre les deux premiers conduit à mal placer les contrôles de sécurité. L’application hôte embarque un client MCP, qui se connecte à un ou plusieurs serveurs MCP.

L’hôte est l’application avec laquelle l’utilisateur interagit : assistant conversationnel, IDE, agent maison. C’est elle qui gère l’autorisation et demande, le cas échéant, une confirmation avant une action. Le client MCP est le composant interne à l’hôte qui parle le protocole : il ouvre la connexion, interroge le serveur sur ses capacités et transmet les appels. Le serveur définit ce qui est exposé et exécute les appels reçus.

Cette répartition a une conséquence pratique : le modèle ne s’attribue pas de droits. Il ne peut demander que ce que le serveur a publié, et l’hôte peut refuser d’exécuter. Deux barrières indépendantes, à concevoir séparément.

Tools, resources et prompts : les trois primitives exposées

Un serveur MCP expose trois types de primitives, et chacune répond à un besoin différent. Les confondre produit des serveurs difficiles à sécuriser, où tout passe par des actions exécutables.

Les tools sont des actions exécutables : créer un enregistrement, lancer une recherche, envoyer une notification. Chacun porte un nom, une description et un schéma de paramètres, sur lesquels le modèle s’appuie pour choisir. Les resources sont des données lisibles, identifiées par une adresse : un fichier, un enregistrement, le résultat d’une requête. Elles alimentent le contexte sans rien modifier. Les prompts sont des modèles d’invite réutilisables, préparés côté serveur pour une tâche récurrente.

La règle de conception est simple : tout ce qui se lit passe par une resource, tout ce qui écrit passe par un tool. Cette séparation vous permet ensuite d’accorder la lecture largement et l’écriture au compte-gouttes.

Cadre de sécurité

Sécurité, permissions et limites d’un serveur MCP

La sécurité d’un serveur MCP se joue au moment où vous décidez de ce qui est exposé, pas au moment où l’agent l’utilise. Ce que vous ne publiez pas est hors de portée du modèle. Le tableau ci-dessous relie chaque niveau d’exposition au contrôle correspondant.

Niveau d’exposition	Ce que le serveur publie	Contrôle à mettre en place	Point de vigilance
Lecture seule	Des resources et des tools de consultation	Filtrage des champs sensibles avant renvoi	Une lecture large suffit à faire fuiter des données par le contexte
Écriture cadrée	Des tools de création ou de mise à jour sur un périmètre défini	Validation stricte des paramètres, compte technique dédié	Un paramètre non contraint élargit le périmètre sans qu’on le voie
Écriture étendue	Des tools agissant sur l’ensemble des données du système	Confirmation côté hôte, quotas, traçabilité par utilisateur	La confirmation perd son sens quand elle devient systématique
Actions irréversibles	Suppression, envoi externe, opérations financières	Exclusion du serveur ou double barrière hors protocole	Aucun retour arrière possible en cas d’appel erroné

Deux risques méritent une attention particulière. L’injection par le contenu d’abord : une donnée lue peut contenir des instructions destinées au modèle, qui les traitera comme du contexte légitime. L’accumulation de serveurs sur un même hôte ensuite, où des capacités inoffensives séparément forment une chaîne d’actions imprévue.

Journalisez systématiquement l’identité de l’appelant, le tool appelé, les paramètres reçus, le résultat et l’horodatage. Sans cette trace, vous ne pourrez ni expliquer une action ni distinguer une erreur du modèle d’un défaut de votre serveur.

Applications

Cas d’usage

• Exposer une base de données interne en lecture seule à un assistant IA
• Autoriser un LLM à créer et modifier des contenus dans un système de gestion
• Permettre à un agent d’interroger un outil de ticketing et d’y ouvrir des demandes
• Fournir à une IA l’accès à un corpus documentaire pour alimenter un RAG

Vos questions

Questions fréquentes

Quelle différence entre un serveur MCP et une API REST ?

Une API REST est conçue pour un développeur qui lit la documentation avant d’écrire son code. Un serveur MCP est conçu pour un modèle qui découvre les capacités à l’exécution : descriptions et schémas de paramètres font partie du protocole, pas d’un document séparé.

Les deux ne s’opposent pas. Un serveur MCP s’appuie très souvent sur une API existante qu’il enveloppe en la restreignant. Le sujet est détaillé sur la page MCP et API.

Faut-il héberger son serveur MCP en local ou à distance ?

En local si le serveur manipule des ressources propres au poste de travail, à distance s’il donne accès à un système partagé par plusieurs utilisateurs. Le critère est la localisation des données, pas la commodité de mise en place.

Le piège tient à la maintenance. Un serveur local doit être installé et mis à jour sur chaque poste, ce qui devient ingérable au-delà de quelques utilisateurs ; un serveur distant règle ce point mais vous impose la supervision d’un service exposé.

Comment limiter ce qu’une IA peut faire via un serveur MCP ?

En n’exposant que les capacités nécessaires. Le périmètre se restreint d’abord par le catalogue publié, ensuite par la validation des paramètres côté serveur, enfin par les droits du compte technique utilisé pour agir sur le système sous-jacent.

N’attendez rien des consignes textuelles adressées au modèle. Une instruction du type « ne supprime jamais rien » n’est pas un contrôle : si l’outil de suppression est exposé, il sera un jour appelé. Retirez l’outil plutôt que d’interdire son usage.

Avec quels langages peut-on développer un serveur MCP ?

Avec ceux qui savent lire et écrire des messages structurés sur stdio ou en HTTP, ce qui couvre la quasi-totalité des langages courants. Des bibliothèques officielles évitent de réimplémenter la couche protocole.

Le bon réflexe est de rester dans la technologie du système à exposer, afin de réutiliser ses règles métier et ses contrôles d’accès plutôt que de les réécrire. C’est ce que montrent les implémentations pour MCP et CMS et, plus précisément, pour WordPress.