Construire son propre serveur MCP

Construire son propre serveur MCP : exposer ses outils internes à un agent IA, en open source

Un agent IA n’est puissant que par les outils qu’il sait actionner. Le Model Context Protocol (MCP), standard ouvert publié par Anthropic et désormais adopté par la plupart des éditeurs (Claude, Cursor, OpenAI, Google, IDE divers), formalise la façon dont un assistant accède à des données et déclenche des actions sur des systèmes tiers. Côté infrastructure, un serveur MCP devient la pièce maîtresse : c’est lui qui décide ce qu’un agent peut voir, interroger ou modifier dans le SI. Construire son propre serveur, plutôt que de tout déléguer aux SaaS, c’est garder la main sur la frontière entre l’IA et ses données.

Pourquoi un serveur MCP maison plutôt qu’un connecteur SaaS

Beaucoup d’éditeurs poussent des connecteurs propriétaires vers leur catalogue (Slack, Drive, Notion, GitHub, etc.). Ces connecteurs sont rapides à brancher, mais ils enferment trois choses : la logique métier exposée à l’agent, le périmètre des permissions, et le chemin emprunté par les données. Pour un SI public, un cabinet sous secret professionnel ou un éditeur souverain, ces trois points ne se délèguent pas. Un serveur MCP que l’on développe soi-même répond précisément à cette contrainte : il s’exécute dans son propre réseau, parle directement à ses bases internes, et ne montre à l’agent que ce qu’on a explicitement décidé de lui montrer.

Anatomie d’un serveur MCP

Un serveur MCP expose trois primitives, suffisamment générales pour modéliser à peu près n’importe quel SI :

• Tools : des fonctions invocables par l’agent, avec un schéma JSON d’arguments et une réponse typée. Exemples : chercher_demande(numero), creer_ticket(sujet, description), publier_jeu_donnees(id).
• Resources : des contenus lisibles, identifiés par une URI, que l’agent peut décider de charger dans son contexte. Exemples : un document, une fiche projet, un export CSV d’un portail CKAN.
• Prompts : des modèles de prompts pré-écrits que l’utilisateur peut déclencher, ce qui permet à un éditeur de proposer ses propres « raccourcis » sans toucher au modèle.

Le tout circule en JSON-RPC, soit en stdio (mode local, idéal pour un agent qui tourne sur le poste), soit en HTTP avec authentification (mode distant, idéal pour partager le serveur entre plusieurs agents et plusieurs utilisateurs).

Une mise en route concrète, en moins d’une heure

Le SDK Python mcp (officiel, sous licence MIT) permet d’écrire un serveur en quelques dizaines de lignes. Le squelette ressemble à : on déclare un FastMCP, on décore ses fonctions Python avec @mcp.tool(), on les laisse renvoyer ce que renverrait n’importe quelle fonction Python, et le SDK fait le reste : génération du schéma, sérialisation, gestion d’erreur, transport. Une variante en TypeScript existe pour les stacks Node. Côté client, n’importe quel agent compatible MCP peut alors se brancher en pointant sur la commande de lancement (mode stdio) ou sur l’URL du serveur (mode HTTP).

Les usages qui changent la donne, côté Askem

• Portail open data piloté par agent : un serveur MCP qui expose rechercher_dataset, obtenir_metadonnees, generer_extrait_csv permet à un assistant de répondre à un agent territorial en langage naturel, sans donner d’accès direct à l’API CKAN.
• Drupal + IA : exposer la création de contenu, la recherche éditoriale et la modération comme des tools MCP, plutôt que d’embarquer un module générique. La rédaction garde la maîtrise des règles métier.
• Supervision d’infrastructure : exposer etat_service, derniers_logs, redemarrer_si_autorise. Un agent IA devient un copilote ops, mais ne peut faire que ce que le serveur veut bien lui laisser faire.
• Direction de projet : exposer la liste des mandats en cours, leurs livrables, leurs jalons. Les comptes-rendus se génèrent à partir de la source de vérité, pas d’un export figé dans le contexte du modèle.

Sécurité et gouvernance, le vrai sujet

Construire un serveur MCP, c’est avant tout dessiner une frontière. Trois principes simples, à poser dès la première ligne :

• Principe du moindre privilège : chaque tool vise une opération précise. On ne fait pas un tool execute_sql(query), on fait chercher_demande(numero), lister_demandes_par_statut(statut), etc.
• Contexte d’identité : le serveur doit savoir qui parle. Authentification HTTP, jeton OIDC issu de Keycloak, et chaque appel est tracé avec l’utilisateur d’origine, pas seulement avec « l’agent ».
• Journalisation systématique : tout appel d’outil est journalisé, avec ses arguments et son résultat tronqué. C’est ce qui permettra plus tard de répondre aux questions de conformité, de RGPD ou simplement de débogage.

Limites et pièges fréquents

MCP n’est pas magique. Trois écueils reviennent souvent : l’explosion du nombre de tools (un agent qui voit 80 fonctions perd en pertinence, mieux vaut découper en plusieurs serveurs spécialisés), la tentation du tool générique (qui rouvre la porte à toutes les attaques par injection de prompt), et l’oubli des erreurs (un tool qui plante doit renvoyer un message clair, pas une stack trace, sinon l’agent boucle). Un bon serveur MCP se reconnaît à ses messages d’erreur, autant qu’à ses fonctions.

À retenir

Le serveur MCP est en train de devenir, pour les agents IA, ce que l’API REST a été pour les applications web : la brique d’intégration de référence. La construire soi-même, en open source, dans son propre périmètre, c’est se donner les moyens de profiter des assistants du marché sans abandonner la maîtrise de son SI. Pour une organisation qui prend l’IA au sérieux, ce n’est plus optionnel : c’est probablement la première brique d’infrastructure à poser.