Nous savions que FlowHunt avait besoin d’un serveur MCP, et nous pensions que cela ne nous aiderait pas beaucoup. Il s’est avéré que c’est ce qui nous a aidés le plus.
Points clés à retenir
- Nous avons toujours su que FlowHunt avait besoin d’un serveur MCP. Nous l’avons considéré comme une fonctionnalité que les utilisateurs attendent, et nous étions sûrs que cela ne nous aiderait pas du tout en tant que développeurs. Cela s’est avéré faux.
- Un agent connecté à un serveur MCP ne peut pas voir le code. Il ne voit que les outils et leurs réponses, il teste donc l’application comme le ferait un utilisateur. Avant le lancement, lors de nos tests, il a trouvé des exécutions qui rapportaient un coût zéro, des actions en masse qui disaient “succès” pour des identifiants qui n’existaient pas, et un lot de 11 lignes qui rapportait 16 réussies. Nous avons corrigé tous ces éléments avant le lancement du serveur.
- Il nous a aussi montré où notre conception ne correspondait pas à la façon dont un agent réfléchit. Six agents construisant des flux ont tous échoué leur premier appel à cause d’un nom d’argument.
- Le construire avec un agent de codage était assez rapide, car notre API existait déjà. La plupart du travail consistait à décider ce qu’il fallait exposer et à le rendre sûr.
- Les deux serveurs sont en direct : AmICited pour SEO, GEO et AEO, et AI Studio pour l’automatisation, où votre agent construit des flux à partir du savoir-faire de notre bibliothèque Agents. Les étapes de connexion sont à la fin.
Pourquoi créer un serveur MCP si votre application possède déjà une API ?
Un serveur MCP expose votre application aux agents IA via le Model Context Protocol , la norme ouverte qui permet à un client MCP comme Claude, ChatGPT ou Cursor de découvrir vos outils et de les appeler. Si vous découvrez le sujet, notre guide ce qu’est un serveur MCP couvre les bases.
Pendant longtemps, FlowHunt n’avait pas de vrai serveur MCP. Chaque application populaire semblait en lancer une, et nous en avions une ou deux en version bêta çà et là, mais personne n’a pris le temps de la terminer.
Nous savions que nous en avions besoin. Avec AmICited, c’était évident, car les gens voulaient demander à un agent “comment ma marque est citée dans les recherches IA cette semaine” sans ouvrir un tableau de bord. AI Studio, notre constructeur de flux visuel, avait besoin d’un aussi. Nous le voyions juste comme une case à cocher : quelque chose que les utilisateurs attendent, intéressant à avoir, rien de spécial. Et nous étions sûrs qu’il n’avait rien à offrir à nous en tant que développeurs. Ce serait juste une surface API de plus à maintenir.
L’opposé s’est avéré être la vérité. Le serveur MCP est devenu l’une des choses les plus utiles que nous avons construites en 2026, et ce sont ceux qu’il a aidés le plus qui étaient nous.
Prêt à développer votre entreprise?
Commencez votre essai gratuit aujourd'hui et voyez les résultats en quelques jours.
Comment créer un serveur MCP pour une application existante
Si vous avez déjà une application, vous avez déjà la plupart d’un serveur MCP. Les fonctions et les routes API existent. Ce qui reste est principalement des décisions, et un agent de codage les prend rapidement. Pour le code lui-même (installer le SDK, définir un outil, exécuter le serveur), consultez notre guide de développement du serveur MCP .
Transformer vos routes API en outils MCP
- Demandez à votre agent de lister chaque fonction et route API que l’application possède.
- Décidez lesquelles un agent devrait pouvoir utiliser. Pour nous, c’était presque tout ce qu’un utilisateur peut faire dans le tableau de bord.
- Faites en sorte que l’agent enveloppe chacune d’elles comme un outil : un nom, une description écrite avec les mots qu’un utilisateur chercherait, et un appel au point de terminaison existant.
- Faites le travail de sécurité.
- Soumettez le serveur aux répertoires de connecteurs d’Anthropic et d’autres fournisseurs d’IA, afin que les gens puissent le trouver où ils le recherchent.
Nos outils MCP sont des enveloppes minces. Chacun appelle un point de terminaison existant et retourne sa réponse existante, afin que l’agent puisse lister les flux, lire le canvas d’un flux, l’éditer, l’exécuter et lire le résultat. Les permissions et les vérifications de crédits vivent sous cette enveloppe, afin que l’agent obtienne exactement les droits que l’utilisateur a dans le tableau de bord.
Sécuriser le serveur MCP
Le travail de sécurité a demandé le plus de réflexion, et c’était quand même une question de sessions concentrées avec Claude, pas des semaines. Au cours de ces sessions, nous avons :
- déplacé la connexion vers OAuth, avec des subventions que l’utilisateur peut voir et révoquer depuis le tableau de bord
- lié chaque connexion à un espace de travail, donc aucun outil ne prend un identifiant d’espace de travail qu’un agent pourrait modifier
- plafonné les tailles d’importation et la concurrence
- marqué chaque outil qui écrit des données, et signalé les suppressions et tout ce qui dépense de l’argent comme destructeur
Aucun de ceux-ci n’est exotique. C’est la même liste de contrôle que vous exécuteriez sur n’importe quelle API publique. Claude était doué pour trouver les endroits où nous en avions manqué un. Notre liste de contrôle de sécurité MCP et l’article sur l’authentification MCP avec OAuth approfondissent le sujet.
En quoi les tests du serveur MCP diffèrent-ils des tests unitaires ?
C’est la partie que je ne voyais pas venir.
Lorsque des agents écrivent du code pour vous, ils testent surtout le code. Ils exécutent les tests unitaires. Parfois, ils font un passage de vérification, ou cliquent sur l’interface utilisateur Web dans un navigateur. Tout cela vérifie que le code fait ce que le code dit. Aucun d’eux ne vérifie si une personne ou un agent peut réellement accomplir son travail avec le produit.
Un serveur MCP change cela. L’agent connecté à celui-ci ne peut pas voir la source. Il ne voit que les outils, leurs descriptions et les réponses qu’ils retournent. C’est la même position qu’un vrai utilisateur, donc quand l’agent utilise le serveur MCP, il teste l’application.
Ce que les agents ont trouvé avant le lancement
Notre test de boîte noire avant le lancement a fait exactement cela. Nous avons donné aux agents des tâches et les avons laissés utiliser AI Studio via le serveur MCP sur notre environnement de test interne, et ils ont trouvé des problèmes qu’aucun test unitaire n’avait détectés :
- Une exécution terminée a rapporté un coût de zéro, même si elle avait dépensé des crédits.
- Les actions en masse disaient “succès” pour les identifiants qui n’existaient pas.
- Un lot de 11 lignes a rapporté 16 lignes réussies, car les étapes rejouées comptaient les lignes terminées une deuxième fois.
- Une exécution arrêtée ressemblait à celle qui était toujours en cours, et elle le restait pour toujours.
- Modifier la réponse d’une FAQ ne mettait pas à jour ses questions alternatives.
- Les outils acceptaient des paramètres que le produit ne peut pas utiliser, comme un nom de modèle qui ne figure pas dans le catalogue, et les sauvegardaient sans broncher.
Aucun d’eux n’a atteint nos utilisateurs. Les tests internes les ont trouvés, et nous les avons corrigés avant le lancement du serveur. Les tests unitaires avaient laissé passer chacun d’eux, et une personne cliquant sur l’interface utilisateur pourrait facilement les manquer aussi, en actualisant la page ou en haussant les épaules face à un nombre impair. Un agent ne le ferait pas. Il prend la réponse au pied de la lettre et fait la mauvaise chose ensuite, ce qui vous montre exactement où la réponse était fausse.
Rejoignez notre newsletter
Recevez gratuitement les derniers conseils, tendances et offres.
Quelles lacunes de conception des outils les agents ont-ils exposées ?
Le deuxième type de découverte était plus intéressant. Ce n’étaient pas des bugs. C’étaient des lacunes entre la façon dont nous avons conçu un outil et la façon dont un agent a vraiment essayé de l’utiliser.
Les noms d’arguments qu’un agent devine
Dans un test, six agents chacun construisant un flux via le serveur MCP. Les six ont tous échoué leur premier appel pour rechercher un composant, car ils ont deviné que l’argument s’appelait type et nous l’avions nommé component_type. Un agent a passé environ dix appels à chercher une recherche Google, car notre recherche a classé une étape “Recherche Commandes Reçues” d’une intégration ERP au-dessus de “Récupérateur de Recherche Google” quand vous aviez tapé “recherche”.
Vous ne l’attraperiez jamais dans une révision de code, car le code était correct. L’outil faisait ce qu’il disait. Il ne correspondait tout simplement pas à ce que quiconque essayerait raisonnablement en premier. Nous avons donc renommé les arguments avec les noms que les résultats de recherche retournent, et nous avons classé les résultats de recherche selon leur correspondance. Les agents ont arrêté de trébucher.
Les playbooks testés de la même manière
Nous avons également écrit de brefs playbooks, servis via le serveur MCP comme des compétences, qui racontent à un agent comment construire un bon flux : vérifiez d’abord la bibliothèque, testez le brouillon avant de publier, gardez les garde-fous hors de la réponse finale. Puis nous avons testé les playbooks de la même manière. De nouveaux agents ont reconstruit les mêmes tâches avec seulement le playbook à lire, et un modèle distinct a jugé les résultats sans savoir lequel c’était. Avec le playbook final, les constructeurs ont terminé en à peu près un tiers du temps qu’ils ont mis avec le brouillon. Les exécutions ont également exposé des lacunes dans le playbook lui-même, comme le fait que la recherche n’a pas de filtre de date sauf si vous mettez after:YYYY-MM-DD dans la requête. Cela a été réintégré au texte.
C’est une boucle de rétroaction que nous n’avions jamais eue auparavant. L’agent utilise l’application, se bloque quelque part de spécifique, et nous corrigeons ce point.
Comment un serveur MCP change l’examen des demandes d’extraction
L’examen d’une demande d’extraction est différent maintenant. Auparavant, vérifier un changement signifiait lire le diff, exécuter les tests et peut-être cliquer sur l’interface utilisateur. Maintenant, le scénario de test est une phrase : “se connecter au serveur MCP, construire un flux qui fait X, l’exécuter, vérifier le coût.” L’agent pilote l’application réelle, et le résultat est quelque chose que vous pouvez coller dans la demande d’extraction comme preuve.
Les scénarios sont devenus plus clairs car ils sont écrits comme des tâches utilisateur, pas comme des fonctions de test. Ils coûtent également moins de jetons. Piloter une application via les outils MCP est beaucoup moins cher que d’avoir un agent qui lit les captures d’écran et chasse les boutons dans un navigateur. Et ils trouvent les lacunes entre les fonctionnalités, ce qui est l’endroit où la plupart de nos vrais problèmes se cachaient.
Ce qu’un serveur MCP change pour vos utilisateurs
FlowHunt est une grande application. AI Studio seul possède des flux, des agents, des chatbots, des bases de connaissances, des plannings, des lots, des intégrations et plus de mille composants. AmICited a sa propre longue liste de rapports. Beaucoup de gens trouvent difficile de commencer. Même les gens qui commencent manquent des fonctionnalités, ou les trouvent par hasard des mois plus tard.
Avec le serveur MCP, cela compte beaucoup moins. Vous dites à votre agent ce que vous voulez, et l’agent trouve l’outil qui le fait. Il lit la description, sait quelle fonctionnalité convient, et l’utilise. À part copier l’URL de connexion, vous n’avez pas à ouvrir le tableau de bord. Les gens finissent par utiliser plus de ce que le produit peut faire, et je pense qu’ils l’apprécient davantage, car ils voient réellement tout.
Comment connecter les serveurs MCP FlowHunt et AmICited
Les deux serveurs sont en direct, et j’aimerais que tout le monde les essaie : les entreprises, les agences, les équipes marketing, les fondateurs qui font leur propre SEO. Vous connectez l’agent que vous utilisez déjà, vous vous connectez, vous choisissez un espace de travail et vous commencez à poser des questions.
Serveur MCP AmICited pour SEO, GEO et AEO
AmICited suit la façon dont les moteurs de recherche IA citent votre marque, et il connecte Search Console, GA4, les audits de site, les backlinks, les concurrents, les plates-formes publicitaires et les modèles de mix marketing. Via MCP, votre agent peut l’utiliser tout. Le serveur inclut également 29 playbooks que l’agent peut lire, écrits d’après la façon dont nous exécutons nous-mêmes ces analyses : triage des chutes de trafic, audit de visibilité IA, analyse des écarts concurrentiels, nettoyage du cannibalisme, examen des dépenses publicitaires, “notre changement a-t-il fonctionné”, et bien d’autres. Vous posez une question en mots simples et l’agent suit le playbook qui convient :
- “Pourquoi le trafic organique a-t-il baissé la semaine dernière ?”
- “Quels invites citent mes concurrents mais pas nous, et quel contenu corrigerait cela ?”
- “Quelles campagnes publicitaires dépensent de l’argent sans conversion ?”
- “Auditez le site et dites-moi les cinq corrections qui valent la peine d’être faites en premier.”
Vous n’avez pas besoin de savoir quel rapport contient la réponse. L’agent le sait.
Serveur MCP FlowHunt AI Studio pour l’automatisation des flux
C’est la partie qui m’a le plus surpris. La bibliothèque FlowHunt Agents contient 264 flux publiés que nous avons construits et affinés au cours des années, et les clients en embauchent certains chaque jour. Nous avons distillé ce qui rend ces flux efficaces dans un playbook que le serveur MCP remet à votre agent, en mettant l’accent sur les 28 flux que les clients embauchent le plus. Donc, quand vous demandez à votre agent d’automatiser quelque chose, il ne commence pas à partir d’un canvas vierge. Il vérifie la bibliothèque pour trouver un modèle proche, lit comment ce flux est construit (les outils, l’invite, le format de sortie, les garde-fous), applique le modèle à votre tâche, teste un brouillon, et ce n’est qu’alors qu’il le publie.
En pratique, vous décrivez le travail et obtenez un flux de travail qui utilise des années de notre savoir-faire :
- “Chaque matin, résumez l’actualité sur nos concurrents et envoyez-la à Slack.”
- “Lisez les nouveaux tickets de support, répondez à ceux que la base de connaissances couvre et marquez le reste.”
- “Créez un chatbot pour votre page de tarification qui répond à partir de votre documentation.”
Vous pouvez construire des flux complexes de cette façon : des agents qui appellent d’autres agents, des routeurs, des exécutions planifiées, des lots sur une feuille de calcul. Ce type de flux prend du temps à apprendre dans l’éditeur visuel. Votre agent s’y rend en quelques minutes, et vous pouvez quand même ouvrir le canvas après pour voir ce qu’il a construit.
Connectez dans Claude Code, Claude ou ChatGPT
La connexion prend une minute. Ajoutez le serveur à n’importe quel client MCP qui prend en charge les serveurs distants. Dans Claude Code, exécutez :
claude mcp add --transport http flowhunt-aistudio https://api.flowhunt.io/mcp/aistudio
claude mcp add --transport http flowhunt-amicited https://api.flowhunt.io/mcp/amicited
Dans Claude et ChatGPT, ajoutez la même URL comme connecteur personnalisé. Votre client ouvre une page de connexion, vous choisissez l’espace de travail, et l’agent ne voit que cet espace de travail. Vous pouvez voir et révoquer les clients connectés à partir du tableau de bord à tout moment. La documentation de connexion contient les étapes pour chaque client.
Plans et tarification
Vous pouvez connecter un agent sur l’essai de 7 jours et sur les plans Pro, Agency et Enterprise plans . Starter n’inclut pas l’accès MCP. Sur AI Studio, les appels MCP eux-mêmes sont gratuits, jusqu’à un plafond horaire qui dépend de votre plan : 120 appels sur l’essai, 600 sur Pro, 2 000 sur Agency, et pas de plafond sur Enterprise. Tout ce qui dépense des crédits dans le tableau de bord, comme l’exécution d’un flux, dépense les mêmes crédits via MCP. Sur AmICited, chaque requête MCP coûte 0,001 crédit, donc mille requêtes coûtent un crédit.
Prochaines étapes : créer un serveur MCP et essayer le nôtre
Si vous possédez une application, créez le serveur MCP. Faites-le même si vous pensez que c’est seulement une fonctionnalité pour les utilisateurs et ne fera rien pour vos développeurs. Nous pensions pareil, et nous nous trompions. C’est un client de test qui utilise votre produit comme l’aurait fait un étranger, et il rapporte chaque nom d’argument déroutant, chaque mauvais chiffre et chaque “succès” qui n’en était pas un. Si vous avez déjà une API, le créer est rapide, et le travail de sécurité se fait en quelques sessions concentrées, pas un projet.
Si vous travaillez en marketing, SEO ou opérations, connectez votre agent à FlowHunt et AmICited et donnez-lui une vraie tâche de votre semaine. Vous découvrirez des fonctionnalités que vous ne saviez pas que nous avions, et vous n’aurez pas à apprendre le tableau de bord pour les utiliser.
Les serveurs MCP ne sont pas seulement pour vos utilisateurs. Ce sont l’un des meilleurs outils que vos développeurs puissent avoir. Et pour vos utilisateurs, c’est le moyen le plus rapide de tirer le meilleur parti de votre produit.
