Depuis un an, les serveurs MCP (Model Context Protocol) sont l'un des sujets chauds côté IA. Ils permettent de connecter un produit à n’importe quel agent IA compatible (Claude, ChatGPT, Cursor…) via un standard ouvert.
J’en ai maintenant deux en production sur mes projets :
- Un pour Begonia.pro, mon SaaS de Local SEO.
- Un pour Fude.md, mon lecteur Markdown multi-appareils.
Voilà mon retour d’expérience : pourquoi j’ai choisi de les développer, comment je m’y suis pris, et ce que les agents IA en font.
Le principe : une API pensée pour les IA
Un serveur MCP, c’est un peu comme une API pensée pour les IA.
Là où une API classique expose des endpoints pour des développeurs, un serveur MCP expose surtout des tools que l’IA peut appeler directement dans une conversation. Chaque tool a un nom, une description, des paramètres, et renvoie un résultat. L’agent lit la liste, choisit les bons outils, les appelle si besoin, puis s’en sert pour répondre.
Mais un serveur MCP ne se limite pas aux tools. Il peut aussi exposer des resources en lecture, c’est-à-dire des contenus que l’IA peut consulter, ainsi que des prompts prêts à l’emploi pour guider l’usage.
Pour un SaaS, cela ouvre un nouveau point d’entrée. Un peu comme l’app mobile en a ouvert un en 2012, ou l’API publique en 2018.
Pourquoi j’ai voulu les construire
Loin d'être un exercice technique, chacun de mes projets a eu intérêt à proposer un serveur MCP :
Côté Begonia.pro, de plus en plus d'entrepreneurs locaux et de consultants SEO posent leurs questions à une IA plutôt qu’à Google. "Est-ce que ma fiche Google Business est bien optimisée ?", "Quels mots-clés locaux je rate ?". Sans serveur MCP, ChatGPT répond avec ses données génériques. Avec mon serveur MCP, ils interrogent mon SaaS Begonia.pro directement, qui peut répondre avec des données réelles, issues de mes analyses SEO.
Côté Fude.md, cela fluidifie l'usage. Fude est un lecteur de Markdown : mes utilisateurs y stockent leurs specs produit, notes de réunion, brouillons d’articles. Un agent IA branché via MCP peut analyser leur style d’écriture, résumer des specs, interroger leurs notes en langage naturel. Le serveur MCP devient littéralement une fonctionnalité produit à part entière.
Deux logiques opposées : avec Begonia, j’expose de la donnée qualifiée ; avec Fude, j’expose des documents personnels.
Le vrai sujet : choisir ce qu’on expose
Un serveur MCP n’est pas un dump de l’API interne. Plus on expose de tools, plus l’IA se perd, consomme des tokens inutilement, et hallucine des appels hors contexte. J’ai préféré commencer petit : 3 tools par serveur.
Pour Begonia.pro :
audit_local_business: auditer rapidement une nouvelle entreprise locale.get_business_scan: lire l'audit complet existant, créé par mon SaaS, d'une entreprise.search_local_seo_knowledgebase: interroger ma base de connaissances SEO.
Pour Fude.md :
list_projects: lister les projets de l’utilisateur.search_documents: chercher dans les documents par mots-clés.get_document: lire un document complet.
Dans les deux cas, trois tools qui font chacun une chose claire. Pas de doublons, pas de "au cas où".
Écrire la description des tools, c’est écrire un prompt
La description d’un tool est lue par un LLM. C’est un prompt. Si elle est vague, l’IA ne l’appelle jamais, ou à tort.
Voilà pour le moment ma méthode :
- Nom : un verbe + un objet (
search_documentsplutôt quedocuments). - Description : ce que ça fait, quand l’utiliser, ce que ça retourne. Deux ou trois phrases max.
- Paramètres : typés, avec un exemple si le format n’est pas évident.
- Erreurs : exploitables par le LLM ("Projet introuvable, utilise
list_projectspour voir les noms disponibles") plutôt que des codes HTTP.
L’authentification : le vrai sujet technique
Pour un serveur MCP local (qui tourne sur la machine de l’utilisateur), l’authentification est souvent plus simple, parce que le serveur tourne déjà sur la machine de l’utilisateur. Mais elle ne disparaît pas pour autant : il faut quand même faire attention aux permissions, aux secrets utilisés, et à ce que le serveur peut lire ou faire.
Pour un serveur distant, multi-utilisateurs, le sujet devient beaucoup plus classique : identité, droits, révocation, audit.
Pour Fude, les fichiers Markdown étant synchronisés en local sur la machine, j'ai naturellement choisi de créer un serveur MCP local. Cela évite de transférer des données sensibles hors IA, pour utiliser le MCP, et favorise la vitesse de recherche de documents.
Pour Begonia.pro, j'ai pour le moment choisi d'authentifier avec une clé d'API, unique à chaque utilisateur, facilement révoquable et copiable. Dans le futur je proposerais sans doute une connexion oAuth classique avec authentification à son compte via un navigateur. Mais pour cette première version, l'API key suffit.
Ce que les agents IA font vraiment avec mes serveurs
Il est intéressant de regarder les logs après quelques semaines en production.
Sur Begonia.pro, l’essentiel des appels vient sur audit_local_business. Un utilisateur demande à Claude "audite la fiche Google de Boulangerie X à Lyon" et récupère un rapport avec de vraies données.
Sur Fude.md, les agents sont beaucoup plus méthodiques : ils appellent quasi-systématiquement list_projects d’abord, puis search_documents, et seulement ensuite get_document si le search a matché. Cela montre que les IA savent naviguer une structure MCP bien conçue.
Deux choses que j'ai notées :
- Les agents ne respectent pas forcément l’ordre suggéré dans les descriptions. Il faut que chaque tool soit robuste indépendamment.
- Les agents appellent parfois plusieurs fois le même tool quand ils hésitent ou veulent récupérer plus de données pour statuer.
D'autres retours d'expérience
Quelques points importants à avoir en tête :
- Le versioning. Un serveur MCP distant est consommé par des centaines de clients différents (chaque installation Claude Desktop est un client). Impossible de casser un tool sans casser l’intégration de vos utilisateurs. Mêmes règles que pour une API publique : on deprecate, on ne supprime pas.
- Les tokens consommés côté IA. Chaque tool ajoute des tokens à la fenêtre de contexte de l’IA, même quand il n’est pas appelé. Si un utilisateur connecte 40 serveurs MCP, il atteint vite sa limite. Raison de plus pour se concentrer sur les tools essentiels par serveur.
- La découvrabilité. MCP ne règle pas le problème de l’adoption. L’utilisateur doit savoir que votre serveur existe, puis le configurer dans son client. Aujourd’hui la configuration est encore le maillon faible de l'usage de serveurs MCP, avec souvent l'édition de fichiers de config JSON. Ça va s’améliorer, mais pour l’instant il faut accompagner.
Conclusion
Un serveur MCP est un nouveau point d’entrée pour un SaaS. Aussi important qu’une API, mais avec un utilisateur différent : un LLM qui lit, choisit, et enchaîne vos outils.
Cela change l’usage d'un SaaS. Mes clients ne viennent plus forcément sur le site de Begonia.pro ou dans l’app Fude : ils utilisent leur IA préférée, et mes produits sont là, disponibles, cités. C’est une nouvelle façon de distribuer un SaaS.
Si vous voulez tester, les deux serveurs sont accessibles :
- Begonia.pro MCP : audit de fiches Google, recherche locale, base de connaissances Local SEO. Plus d’infos sur Begonia.pro.
- Fude.md MCP : accès à vos documents Markdown personnels. Fude.md.
Et vous, est-ce que vos produits sont prêts pour l’ère des agents IA ? Avez-vous déjà réfléchi à ce que vous pourriez exposer via MCP ?
📌 Si vous voulez réfléchir à l’intégration de MCP ou plus largement à la place de l’IA dans votre produit, découvrez mes services de Product Engineering pour concevoir et développer les bons outils.