Comment nous avons conçu un serveur MCP distant pour la planification des opérations de terrain

Un serveur MCP devient intéressant lorsqu'il dépasse le stade de la démonstration pour prendre en charge un véritable flux de travail. Pour Crisphive, ce flux était la planification des opérations de terrain : le travail quotidien et complexe consistant à examiner les interventions, les intervenants, les lieux, les disponibilités et le contexte de répartition, sans demander à un opérateur de tout copier-coller dans une fenêtre de discussion. Cette note de conception retrace la création de notre serveur MCP distant : pourquoi nous l'avons construit, nos choix d'architecture, le rôle d'OAuth et notre démarche en vue de l'annuaire des connecteurs Claude.

Le contexte

La planification des opérations de terrain n'est pas une action simple et isolée. Un répartiteur peut avoir besoin de vérifier si une intervention est prête, de trouver le bon technicien, de comprendre ce qui a changé depuis le dernier message du client et d'éviter de créer un nouveau conflit d'agenda au passage. C'est précisément le type de tâche où un assistant IA a besoin de plus qu'une simple consigne textuelle. Il lui faut des outils capables de poser des questions précises au système de planification et de renvoyer des réponses tout aussi précises.

Le cahier des charges de notre serveur MCP distant était donc simple : exposer les capacités de planification sous la forme d'une interface d'outils qu'un client IA pourrait utiliser, sans transformer le produit de planification en un simple gadget de discussion. Le protocole Model Context Protocol nous a permis de décrire ces outils, de conserver une structure d'intégration prévisible et de séparer l'expérience de l'assistant du système opérationnel sous-jacent. Pour les lecteurs qui souhaitent consulter la documentation du protocole, le projet est hébergé sur modelcontextprotocol.io.

Cette approche nous a également évité de suivre aveuglément une liste de contrôle générique pour serveur MCP en 2026. La question utile était plus ciblée : quelles tâches de planification deviennent plus sûres ou plus rapides lorsque l'assistant peut interroger directement le système, et quelles tâches doivent rester dans l'interface du produit sous la responsabilité d'un humain ?

Nous devions aussi être honnêtes quant au public visé. Les développeurs et créateurs de solutions d'IA n'ont pas besoin d'un discours commercial sur les logiciels de serveur MCP. Ils ont besoin de savoir où se situe la frontière : ce que l'assistant peut appeler, ce que le système de planification conserve sous son contrôle direct, et ce qui se passe lorsqu'une demande est ambiguë. C'est cette frontière qui a façonné l'ensemble du projet.

Fonctionnement

L'architecture repose dès le départ sur un serveur MCP distant plutôt que sur une simple expérimentation locale. Le serveur s'intercale entre le client IA et les API de planification de Crisphive. Il définit les outils, valide les entrées, appelle le système de planification en arrière-plan et renvoie une réponse utile sans exposer inutilement la structure interne. En d'autres termes, il agit moins comme un raccourci que comme une API d'outils pour agents IA délibérément ciblée.

Le rôle d'OAuth était essentiel car les données de planification sont des données opérationnelles. Un connecteur capable de lire ou d'agir sur le contexte de répartition doit savoir dans quel espace de travail il intervient et quelles autorisations s'appliquent. Le serveur distant nous offre un point unique pour gérer ce parcours d'autorisation, associer le bon contexte de compte et éviter que les appels d'outils ne deviennent du trafic anonyme en arrière-plan.

Nous avons conservé une première série d'outils très proche des besoins du terrain. Cela signifiait penser en termes de fonctions de planification plutôt qu'en opérations CRUD génériques. Un outil utile doit parler le langage du répartiteur : interventions, disponibilités, affectations, créneaux horaires, contexte client et contraintes de répartition. Le meilleur serveur MCP pour cette tâche n'est pas celui qui accumule le plus d'outils, mais celui dont les outils sont suffisamment restreints pour être vérifiés et suffisamment précis pour être utiles.

Le travail côté Claude a influencé le conditionnement de l'ensemble. L'écosystème de connecteurs d'Anthropic, y compris l'espace public Anthropic news où sont annoncées les évolutions du produit, montre clairement qu'un connecteur en production est évalué tout autant sur la confiance qu'il inspire que sur son originalité. Nous avons traité la préparation à l'annuaire comme une exigence produit dès la conception, et non comme une tâche de dernière minute le jour du lancement.

L'expérience utilisateur

L'expérience utilisateur doit paraître plus simple et plus fluide que l'architecture sous-jacente. Un répartiteur ne devrait pas avoir besoin de savoir quel outil a été appelé ni comment le serveur MCP distant a vérifié le contexte du compte. Il doit pouvoir poser une question sur le planning et obtenir une réponse fidèle à la réalité des opérations de terrain qu'il gère déjà.

Pour une PME, la différence est très concrète. Un technicien a du retard. Un client demande un créneau plus tôt le matin. Un responsable souhaite savoir si la tournée de demain peut intégrer une intervention supplémentaire. L'assistant ne peut apporter son aide que s'il dispose d'un moyen sûr d'examiner le contexte de planification. C'est pourquoi un serveur MCP adapté aux PME doit définir clairement son périmètre. Il ne doit pas tout exposer simplement parce que le système en arrière-plan en est capable.

Nous voulions également que le connecteur rende les incertitudes visibles. Si une demande exige une décision humaine, la réponse de l'outil doit le préciser clairement. Si un changement de planning dépend d'une règle que l'outil ne peut pas vérifier, il doit s'interrompre. C'est l'un des conseils les plus utiles concernant les serveurs MCP que nous avons retenus : concevez le refus responsable de l'outil avec autant de soin que ses appels réussis.

Une bonne documentation fait également partie de cette expérience. Les détails d'implémentation propres à l'intégration avec Claude ont davantage leur place sur docs.claude.com que dans l'interface de travail d'un répartiteur. Séparer clairement ces espaces permet aux développeurs de déboguer sans transformer l'outil de répartition en console d'ingénierie.

Les enseignements tirés

Le premier enseignement est que le protocole Model Context Protocol ne représente que la moitié des choix d'un produit. L'autre moitié concerne la conception des outils. Les exemples de serveur MCP peuvent donner l'impression que le protocole est très simple, mais la planification des opérations de terrain impose des questions plus difficiles : qu'est-ce qui doit être accessible en lecture, qu'est-ce qui doit pouvoir déclencher une action, et quelles actions doivent rester hors de portée de l'assistant tant que le produit ne peut pas les exécuter en toute sécurité ?

Le deuxième enseignement a été de commencer par l'observabilité. Les appels d'outils nécessitent des journaux reliant la demande de l'assistant, l'espace de travail authentifié, l'appel système en arrière-plan et le résultat obtenu. Sans cette chaîne, il devient difficile d'identifier si une mauvaise réponse provient de la consigne, de la description de l'outil, de l'API de planification ou de la formulation de l'utilisateur. Améliorer la qualité d'un serveur MCP passe souvent par des journaux de suivi rigoureux avant de chercher des consignes complexes.

Le troisième enseignement concerne la retenue. Un connecteur peut rapidement devenir impressionnant tout en restant très fragile. Nous avons évité d'ajouter toutes les idées qui semblaient séduisantes à première vue. Nous sommes partis du flux de travail de planification pour nous demander si chaque outil aidait réellement un répartiteur à prendre une meilleure décision. Cela nous a évité de créer une simple couche superficielle recouvrant l'ensemble du système.

Le dernier enseignement est à la fois financier et technique : le coût d'un serveur MCP ne se limite pas à l'hébergement. Il intègre le temps de vérification, la modélisation des autorisations, la maintenance et la charge de support lorsque l'assistant interagit avec des opérations en direct. Intégrer ces éléments dans notre réflexion d'architecture a rendu notre démarche beaucoup plus pragmatique.

Les prochaines étapes

La prochaine étape n'est pas de rendre le connecteur plus complexe, mais plus fiable. Cela signifie étendre la couverture des outils uniquement là où le flux de travail de planification en tire un bénéfice évident, renforcer la validation des demandes ambiguës et améliorer la boucle de retour entre les résultats des outils et les actions de l'opérateur.

Nous prévoyons des améliorations progressives : des descriptions d'outils plus claires, des messages d'erreur plus précis et un contrôle plus strict de ce que chaque outil est autorisé à renvoyer. Ce type de peaufinage apparaît rarement sur une capture d'écran lors d'un lancement, mais c'est ce qui rend un connecteur digne de confiance sur la durée.

Nous souhaitons également disposer de meilleurs exemples au sein de notre processus de développement. Pas des annonces publiques ni des démonstrations mises en scène, mais des exemples internes de serveur MCP montrant comment un répartiteur demande concrètement de l'aide et où l'assistant doit passer la main. C'est grâce à ces exemples qu'un serveur MCP distant passe du statut d'intégration technique à celui d'outil utile au quotidien pour les opérations de terrain.

La trajectoire globale est claire : les créateurs de solutions d'IA vont continuer à connecter des assistants aux systèmes opérationnels. Nous finissons par la conviction que les opérations de terrain méritent des connecteurs conçus avec la même rigueur que les outils de planification eux-mêmes. Des outils ciblés, des autorisations explicites, un suivi rigoureux et le refus de faire croire qu'une interface de discussion remplace le jugement humain. C'est le niveau d'exigence que nous visons à mesure que ce serveur MCP passe du statut de note de conception à celui d'usage quotidien en production.