Trois serveurs MCP officiels maintenus par Stripe, HubSpot et Sentry, chacun avec son propre cycle de version, sa propre authentification et son propre format d’erreur, contre un seul serveur maison qui agrège les trois API derrière une interface commune : c’est le choix auquel se sont retrouvés confrontés plusieurs projets WordPress qui voulaient donner à un agent la capacité de consulter les paiements, les tickets CRM et les erreurs applicatives dans une même conversation.
Le Model Context Protocol, apparu fin 2024, a rapidement donné lieu à des serveurs officiels publiés par les éditeurs eux-mêmes. Stripe, HubSpot et Sentry proposent chacun le leur, avec l’avantage évident d’être maintenus par l’équipe qui connaît le mieux l’API sous-jacente. Face à cela, l’option d’un serveur maison unique, construit sur mesure pour agréger ces trois services, reste tentante pour qui veut une expérience homogène côté agent.
Ce que les serveurs officiels apportent
Utiliser le serveur MCP officiel de Stripe, par exemple, garantit que les nouveaux champs d’API, les nouveaux types d’objets ou les évolutions de sécurité sont pris en compte sans effort de maintenance côté projet. Idem pour HubSpot et Sentry : chaque éditeur documente ses outils exposés, gère ses propres correctifs, et publie généralement plus vite que ne le ferait une équipe interne qui doit suivre trois API à la fois.
Ce que le serveur maison résout
Le principal reproche fait aux serveurs officiels, une fois qu’on en installe plusieurs côte à côte, concerne la fragmentation : trois authentifications différentes à gérer, trois formats d’erreurs à interpréter, et surtout trois surfaces d’outils exposées séparément à l’agent, qui doit alors deviner lequel appeler selon le sujet de la conversation. Un serveur maison unique permet de centraliser l’authentification (un seul jeton, des scopes uniformes) et de présenter à l’agent un jeu d’outils cohérent, avec une nomenclature commune.
Tableau comparatif
| Critère | Serveurs officiels séparés | Serveur maison unique |
|---|---|---|
| Maintenance des API sous-jacentes | À la charge de l’éditeur | À la charge de l’équipe interne |
| Authentification | Une par service | Unifiée, un seul point à sécuriser |
| Cohérence des outils exposés à l’agent | Variable selon l’éditeur | Homogène, nommage maîtrisé |
| Rapidité de mise à jour après changement d’API | Généralement rapide | Dépend de la disponibilité de l’équipe |
| Risque en cas de service compromis | Isolé au service concerné | Potentiellement partagé entre services |
Le facteur décisif : le nombre d’agents et leur autonomie
L’expérience sur plusieurs projets montre que le choix dépend surtout d’un facteur rarement mis en avant : combien d’agents différents vont consommer ces intégrations, et à quel point ils agissent de façon autonome. Un unique agent de support interne, qui a besoin ponctuellement de consulter Stripe et Sentry, tire peu de bénéfice d’un serveur maison complexe à maintenir. À l’inverse, une flotte de plusieurs agents (support, facturation, monitoring) qui partagent les mêmes trois services justifie largement l’investissement dans une couche d’agrégation.
Un risque à ne pas sous-estimer avec le serveur maison
Agréger plusieurs services sensibles derrière un seul serveur MCP crée aussi un point de défaillance unique : si ce serveur est compromis, l’attaquant obtient potentiellement accès aux trois services d’un coup, plutôt qu’à un seul. Ce point mérite un traitement à part entière tant il pèse sur la décision, mais il ne suffit pas à lui seul à disqualifier l’approche si elle est correctement cloisonnée en interne.
Trois serveurs officiels bien à jour valent mieux qu’un serveur maison mal maintenu ; mais un serveur maison bien pensé vaut mieux que trois intégrations que personne ne relie entre elles.
Notre verdict
Pour un projet qui démarre avec un seul agent et un besoin ponctuel sur chacun des trois services, les serveurs officiels restent le choix le plus raisonnable : ils demandent moins d’efforts et bénéficient directement des mises à jour des éditeurs. Le serveur maison unique ne devient pertinent qu’à partir du moment où plusieurs agents partagent réellement les mêmes intégrations et où la cohérence de l’expérience compte plus que la simplicité de maintenance individuelle de chaque connecteur.
