Serveur MCP distant en action : un nouveau point d'entrée pour les produits SaaS à l'ère de l'IA

Les produits SaaS connaissent un problème de longue date : le délai avant d'apporter de la valeur est trop long. Beaucoup d'utilisateurs partent avant d'atteindre le moment « aha ».

Nous avons retravaillé plusieurs fois l'onboarding de Logto. Cela a aidé, mais le goulet d'étranglement ne disparaissait pas. Au final, tu finis toujours par lire la documentation, survoler les tutoriels, installer les SDKs, relier les configurations, écrire du code, puis déboguer les 10 % restants avant que quoi que ce soit ne fonctionne.

Nous avons donc tenté une approche différente : un serveur MCP distant comme plan de contrôle natif à l'IDE de Logto. Au lieu de cliquer dans une console d'administration, tu configures Logto et génères du code d'intégration via une conversation, directement là où tu construis l'application.

Un seul prompt peut t'emmener de zéro à une intégration opérationnelle. L'agent ne fait pas que générer du code, il crée et configure aussi l’application Logto dans ton espace client. Tout ça depuis ton IDE. (Essaye Logto MCP Server)

Dans cet article, je vais partager notre expérience et réflexions autour de la construction du serveur MCP Logto, dont :

• MCP vs Compétences d'Agent : pourquoi nous avons choisi MCP
• Problèmes rencontrés lors du déploiement d’un serveur MCP, et comment nous les avons résolus
• Comment nous concevons les outils MCP et comment tu devrais concevoir les tiens
• Nos attentes pour l’avenir du MCP

MCP vs Compétences d'Agent : pourquoi nous avons choisi MCP#

Avant de décider comment l’IA devait accéder à Logto, nous avons évalué deux options : serveurs MCP et Compétences d’Agent.

Les serveurs MCP existent sous deux formes : local et distant.

Un serveur MCP local fonctionne sur la machine de l’utilisateur. Il demande une installation de service, la configuration d’environnement, des identifiants ou des flux de connexion spécifiques. À l’usage et à la livraison, il ressemble beaucoup aux compétences.

Un serveur MCP distant est hébergé côté serveur. Les utilisateurs s’y connectent via une URL et s’autorisent avec OAuth. Ce modèle se rapproche de l’extension d’un service SaaS.

Structurellement, une Compétence d’Agent combine « logique métier + capacités sous-jacentes ». Ces capacités peuvent être des outils, des CLIs ou des appels API. Les outils MCP peuvent porter cette couche de manière unifiée.

La vraie question n’est donc pas l’implémentation des capacités, mais la manière dont elles sont livrées aux utilisateurs.

• Compétences d’Agent : fournissent une chaîne d’outils complète locale (package de compétence + runtime local + clés API ou identifiants de plateforme + outils CLI + installation, configuration, mise à jour, maintenance).
  Essentiellement, tu fournis la capacité aux utilisateurs pour qu’ils l’exécutent eux-mêmes.

• Serveurs MCP distants : fournissent une entrée de service distante (URL + connexion OAuth).
  Essentiellement, tu offres la capacité sous forme de service.

Ci-dessous, nous comparons selon l’expérience utilisateur, la portée de l’écosystème, et le coût de livraison et maintenance.

Expérience utilisateur#

Les Compétences d’Agent s’appuient généralement sur les API ou CLI de la plateforme. Les utilisateurs doivent d’abord créer des clés API ou installer et se connecter aux CLIs. Ce ne sont pas des étapes complexes, mais elles augmentent la barrière d'entrée.

Les serveurs MCP prennent en charge OAuth. Les utilisateurs se connectent avec leur compte SaaS. C’est comme « Se connecter avec Google ».

Pour les utilisateurs, utiliser un serveur MCP est simple : saisir une URL, se connecter, relier. C’est cette expérience que nous souhaitons offrir.

Portée de l’écosystème#

Sur le site MCP, il existe déjà 104 applications IA qui supportent MCP, dont des outils comme VS Code, Cursor et Windsurf.

Les Compétences d’Agent restent spécifiques à leur plateforme. Même si de nombreuses plateformes commencent à les gérer, quand nous livrons un serveur MCP, les utilisateurs peuvent l'utiliser immédiatement. Si nous livrons une Compétence, seuls les utilisateurs de cette plateforme peuvent l’utiliser.

MCP fait aussi partie de la Agentic AI Foundation (AAIF). C’est un standard de protocole. L’écosystème va continuer de croître. Pour nous, ça justifie un investissement à long terme dans MCP.

Coût de livraison et de maintenance#

Les Compétences d’Agent dépendent des API ou CLI de la plateforme, ce qui pose rapidement des problèmes :

• Que faire si l’API évolue ?
• Que faire si la CLI casse la compatibilité ?
• Comment mettre à jour et redistribuer la Compétence ?

Il faut aussi distribuer des CLIs, gérer des identifiants dispersés, adapter à plusieurs plateformes, guider les utilisateurs pour les mises à jour. Le retour sur investissement est très faible.

Les serveurs MCP sont beaucoup plus simples. Les utilisateurs se connectent à une URL. Elle pointe toujours vers la dernière version. Quand on met à jour le serveur MCP, les utilisateurs en profitent lors de leur prochaine connexion. Aucune mise à jour nécessaire. Si l’API change, on l’adapte à l’intérieur du serveur MCP.

La plupart des produits SaaS ont déjà une solide infrastructure : bonnes API, systèmes d’authentification matures. Un serveur MCP s’intègre naturellement comme « interface IA » de l’API, comme une console d’admin est une interface au-dessus des mêmes APIs.

Pour Logto, choisir un serveur MCP correspond à notre architecture et s’appuie sur nos forces.

Cela centralise aussi toutes les requêtes dans un seul point d’entrée. Journaux et audits sont facilités. Les permissions sont claires : l’IA ne peut faire que ce que l’utilisateur autorise. Ce modèle est structurellement plus sain pour l’entreprise et la conformité.

Problèmes rencontrés lors du déploiement d’un serveur MCP, et comment nous les avons résolus#

MCP n’est pas parfait. La plupart des soucis sont ceux d’un écosystème immature. Ils s’amélioreront avec le temps. En attendant, nous avons mis en place des contournements pour répondre aux besoins réels.

Prise en charge fragmentée des fonctionnalités MCP#

La spécification MCP définit de nombreuses fonctionnalités, mais le support côté client varie :

• Outils : largement pris en charge
• OAuth : bien géré par VS Code ; des outils comme Cursor nécessitent mcp-remote comme pont
• Autres fonctionnalités (Ressources, Prompts, Instructions) : support incohérent

Pour l’instant, les outils sont le socle fiable commun (voir la MCP Community Page pour connaître les fonctionnalités de chaque client).

Notre stratégie est donc simple : se concentrer sur les outils.

Le LLM ne sait pas utiliser tes outils#

C’est un problème métier.

Avec les Compétences d’Agent, logique métier et contexte sont emballés ensemble. Le LLM sait les utiliser. MCP ne fournit que des outils. Après connexion, le LLM ne sait pas :

• Les scénarios d’usage
• L’ordre d’appel
• Les contraintes métier

MCP inclut la notion d’Instructions, mais tous les clients ne la supportent pas. Les Instructions injectent tout leur contenu dans le contexte à la connexion, ce qui gaspille des tokens.

Autre idée : placer les consignes dans la description des outils. Cela pose 2 problèmes :

• Les descriptions deviennent complexes. Les workflows sur plusieurs outils génèrent des logiques emmêlées, difficile à maintenir.
• Quand le nombre d’outils augmente, ces descriptions remplissent le contexte de la fenêtre.

Notre contournement : fournir un outil getInstructions

L’idée est simple : si les Instructions ne sont pas bien supportées, alors faisons-en un outil.

Le LLM peut appeler getInstructions à la demande.
Pour la tâche A, il appelle getTaskAInstructions. Le serveur MCP retourne un prompt expliquant comment accomplir la tâche A et combiner les autres outils.

La logique métier complexe reste derrière les outils d’Instructions. Les autres outils restent simples. Leurs descriptions expliquent uniquement leur propre fonctionnalité.

C’est semblable aux Compétences d’Agent : les prompts sont appelés à la demande. C’est aussi plus efficace que les Instructions globales, car cela évite d’injecter tout dans le contexte.

Le LLM peut divulguer tes secrets#

Pour de nombreux produits SaaS, certains secrets ne doivent jamais être exposés (par exemple, secrets clients, clés API, clés de signature de webhook). S’ils fuitent, d’autres peuvent t’usurper ou accéder directement à des ressources.

Le risque avec les LLMs est qu’un chat n’est pas un canal sécurisé. Les conversations peuvent être enregistrées, copiées, transférées, ou finissent dans les journaux de débogage. Tu ne peux pas supposer « seul moi et le modèle y avons accès ». Confier un secret longue durée à un LLM, ou lui demander de l’afficher pour que l’utilisateur le copie, est risqué.

C’est fréquent dans les intégrations web traditionnelles : les développeurs ont besoin d’un secret, le placent dans les variables d’environnement serveur ou fichiers de config, puis finalisent l’intégration (ex : initialisation du SDK).

Pour garder l’onboarding simple sans affaiblir la sécurité des secrets, nous faisons trois choses :

• Utiliser des secrets temporaires lors de l’intégration

  Pendant la configuration via chat, le serveur MCP ne retourne que des secrets temporaires de courte durée (par exemple, valables 1 heure). Suffisants pour faire fonctionner l’intégration, et souvent expirés avant la mise en ligne. Avant la mise en prod, les développeurs créent et remplacent par des secrets de production longue durée hors du chat.

• Rendre explicite la frontière de sécurité

  Nous avertissons très clairement les utilisateurs : ne crée pas, ne colle pas et ne stocke pas de secrets de production dans le chat. Nous rappelons aussi que même les variables d’environnement ou fichiers de configuration peuvent fuiter si un agent/LLM peut y accéder via des outils ou indirectement. Utilise des secrets de production uniquement dans des environnements sans intégration assistée par IA.

• Ne pas manipuler de secrets de production dans le chat ; orienter vers la console

  Les secrets longue durée ne sont ni générés ni transmis dans le chat. Ils sont créés et gérés dans la page d'identifiants de la console. Dans le chat, nous fournissons seulement un lien direct pour effectuer la configuration production côté console.

Comment nous concevons les outils MCP#

Notre parcours#

Logto possède une API de gestion complète. Notre première idée était simple : exposer chaque endpoint API comme outil MCP.

Cela a échoué rapidement.

Premièrement, explosion du contexte. Logto possède de nombreuses APIs. Les exposer une à une noie la fenêtre de contexte. Chaque description d’outil consomme des tokens.

Deuxièmement, perte de sens. Les APIs sont des briques atomiques pour développeurs. Mais les utilisateurs du serveur MCP Logto ne construisent pas des systèmes. Ils veulent juste accomplir des tâches. Ils se fichent du nombre d’APIs existantes.

Exemple : Logto a une API sign-in-experience pour le branding, les méthodes de connexion, d’inscription et les politiques de sécurité.
Au début nous pensions exposer tous les paramètres à l’IA, lui apprendre à combiner les appels.

Mais c’était la mauvaise approche. Les utilisateurs n’appellent pas des APIs. Ils veulent changer le branding ou configurer les méthodes de connexion.

Les outils devraient donc être updateBranding, updateSignInMethod, updateSignUpMethod. Le serveur MCP gère la composition d’API en interne.

Le serveur MCP Logto doit être vu comme un produit, pas comme un simple wrapper d’API. C’est « une autre console d’admin ».

Comment concevoir des outils MCP#

La règle devient claire :

• Si les utilisateurs exploitent ton service directement (comme une console), vise des outils métiers.
• Si tu fournis des capacités de base à d’autres pour s’appuyer dessus, les outils doivent rester atomiques et simples. Exemple : un serveur MCP de filesystem avec read_file, write_file, ensuite les agents assembleurs les combinent.

Autres principes :

• Simplifie la logique des outils et leurs descriptions pour économiser du contexte.
• Pour des workflows complexes, utilise des outils getInstructions pour charger les consignes à la demande. Simplifie également leurs descriptions.

Nos attentes pour l’avenir du MCP#

Pendant la construction du serveur MCP, nous avons aussi réfléchi à ce qui pourrait améliorer l'écosystème.

Livraison des capacités niveau « compétence »#

Parfois, les serveurs MCP doivent offrir non seulement des outils, mais aussi des consignes sur la manière de les combiner, comme les Compétences d’Agent.

C’est fréquent dans le SaaS. Par exemple, pour le serveur MCP GitHub, Logto ou des plateformes d’analytics. Les utilisateurs veulent des workflows, pas des appels atomiques.

L’outil getInstructions est un contournement. Un support standard de protocole serait préférable.

Activation MCP au niveau session#

Les clients se connectent à plusieurs serveurs MCP, mais toute session n’a pas besoin de tous. Une activation/désactivation par session pourrait limiter la place utilisée dans le contexte.

Isolation du contexte pour les appels d’outils MCP#

Les appels d’outils MCP consomment beaucoup de contexte. Si les interactions MCP sont gérées par des sous-agents, la conversation principale n’aurait que des résultats condensés.

Conclusion#

Voilà notre expérience sur la création d’un serveur MCP distant.

Si tu explores cette direction, essaie le Logto MCP Server ou rejoins notre Discord pour échanger sur les cas réels avec la communauté.

Nous partagerons aussi des détails sur la conception de l’architecture et sur le flux OAuth dans de futurs articles.