Les serveurs MCP deviennent des plateformes fonctionnelles, et non des simples enveloppes d’outils.
Les serveurs MCP deviennent des plateformes fonctionnelles : transformation d’outils, recherche, espaces de noms, proxys, compétences, tâches et gestion des versions, ainsi que indications sur les moments où il convient de différer.
Sources: Stop Building AI Apps for Every Idea. Start Building MCP Servers — Part #7
Tout ceux qui ont mis un serveur MCP en production connaissent désormais la liste de contrôles à respecter : des contrats d’outil explicites, des entrées et sorties structurées, une sémantique d’erreurs cohérente, une authentification, une capacité d’observation, une séparation claire entre ce que le modèle contrôle et ce que le système d’exécution fournit (l’ID utilisateur, le locataire, les rôles et les scopes), une autorisation au moment de l’exécution, ainsi qu’un modèle de déploiement capable de s’adapter. La prochaine évolution ne concerne ni un nouveau protocole de transport ni un autre framework d’agent, et ce n’est pas une raison de réécrire toute l’infrastructure. Il s’agit plutôt du fait qu’un serveur MCP ressemble de plus en plus à une véritable plateforme d’applications pour des fonctionnalités avancées, et non à un simple point d’entrée auquel quelques outils ont été ajoutés de manière superficielle.
La différence devient importante lorsque l’on dispose de dizaines d’outils, de plusieurs serveurs MCP, de multiples équipes, d’utilisateurs ayant des permissions différentes, de clients variés, de workflows longs, de compétences réutilisables, de versions ainsi que d’une quantité croissante de contexte. À ce stade, la question n’est plus de savoir comment exposer une fonction Python en tant qu’outil ; elle devient bien plus large :
Comment donner forme, découvrir, composer, gérer, exécuter, observer, tester et faire évoluer toute une surface de capacités sans tout charger sur le modèle ?
C’est la direction vers laquelle MCP évolue, et le reste de cet article l’explique en détail.
Le premier serveur MCP et les serveurs MCP d’aujourd’hui sont complètement différents
Les premiers exemples de MCP étaient délibérément simples : un seul serveur contenait un petit nombre d’outils :
MCP server
├── search_documents
├── create_ticket
└── get_customer
Le client a énuméré les outils, le modèle a lu les schémas et en a sélectionné un, puis le serveur l’a exécuté. Pour une petite installation, ce modèle mental reste valable. Avec cinq outils bien définis, un backend, une équipe et un cas d’usage, rien de plus complexe n’est nécessaire.
Maintenant, appliquez le même concept à une véritable entreprise :
Salesforce MCP 60 capabilities
GitHub MCP 40 capabilities
Jira MCP 35 capabilities
Google Drive MCP 25 capabilities
Knowledge Base MCP 20 capabilities
Internal Platform MCP 70 capabilities
Reporting MCP 15 capabilities
Admin MCP 30 capabilities
Ce n’est plus un serveur d’outils. C’est un écosystème de capacités. Si l’on concatène simplement chaque schéma et que l’on envoie le tout au modèle, trois problèmes apparaissent en même temps : le contexte est détruit avant même que la tâche ne commence, le choix des outils devient plus difficile, et le modèle prend en compte des capacités qui peuvent être irrelevantes, risquées ou confuses pour cet utilisateur et ce flux de travail.
La pression est familière, issue des discussions sur la sécurité et la découverte, mais elle a une conséquence plus large qui est facile à négliger : le catalogue d’outils est lui-même un artefact d’ingénierie. On peut le rechercher, le transformer, le filtrer et lui attribuer des noms de domaine. Il peut être construit à partir des offres d’autres serveurs, et il peut contenir des compétences et des ressources réutilisables. Certaines opérations peuvent être suspendues pour poser une question à l’utilisateur, les tâches longues peuvent être exécutées en arrière-plan, les contrats peuvent être versionnés, et toute l’interface peut être testée comme n’importe quelle API de production.
C’est cette évolution que couvrent les sections suivantes.
FastMCP est une bonne mise en œuvre de cette idée, mais pas l’idée elle-même
FastMCP apparaît dans tous les exemples car son architecture actuelle rend ces schémas exceptionnellement visibles. Les fournisseurs fournissent des composants. Les transformations modifient l’apparence des composants avant que le client ne les voie. La recherche peut remplacer un catalogue immense par une interface de découverte très simple. Les proxies peuvent fusionner d’autres serveurs MCP. Les compétences peuvent devenir des ressources. Les opérations lentes peuvent être transformées en tâches en arrière-plan. Les versions peuvent coexister. Et l’interface MCP résultante peut être testée à l’aide d’un client réel, plutôt que par l’appel direct des fonctions de mise en œuvre.
C’est utile, mais la leçon n’est pas que « tout le monde devrait adopter FastMCP ». Il s’agit plutôt de modèles architecturaux réutilisables pour les systèmes MCP. Les mêmes idées peuvent être mises en œuvre en Python, TypeScript, Go, C#, Java, Rust ou sur une plateforme interne, avec un autre framework, avec des composants développés manuellement ou avec un gateway géré. Ce qui compte, c’est de remarquer où l’abstraction s’éloigne de ses fondements. Le protocole standardise la manière dont les clients communiquent avec les capacités, tandis que l’architecture de votre serveur détermine l’apparence de cette interface, qui peut désormais être bien plus intelligente qu’une liste statique de fonctions décorées.
1. Transformation des outils : une API backend ne devrait pas devenir automatiquement l’API de l’agent
L’une des idées les plus pratiques ici est également parmi les plus simples. Un outil fourni par un service externe peut être techniquement correct et pourtant inadapté à un LLM.
Imaginez une intégration interne Salesforce qui permet cette opération :
salesforce_account_query_v2_internal(
q_string,
include_deleted_flag,
tenant_uuid,
raw_fields,
)
Dans le service qui en est propriétaire, cette signature peut être acceptable. Le modèle doit-il voir exactement ce contrat ? Probablement pas. La version destinée au modèle se lirait mieux comme ceci :
find_customer_account(
company_name,
include_archived=False,
)
La opération sous-jacente reste inchangée. Ce qui change, c’est l’interface présentée au modèle, et c’est là que réside la transformation des outils.
FastMCP la met à disposition grâce à une couche de transformation dédiée : renommer un outil, réécrire sa description, renommer les arguments, modifier les valeurs par défaut, cacher les arguments non nécessaires, ajuster les étiquettes et annotations, et envelopper l’exécution dans une logique personnalisée. En résumé, le flux est le suivant :
Backend capability
↓
Raw MCP tool
↓
Transformation layer
↓
Agent-facing contract
Plusieurs raisons font que cela en vaut la peine.
Un modèle n’a pas besoin de détails d’infrastructure. Des champs tels que tenant_uuid, internal_region, api_version ou include_deleted_internal_records relèvent de la responsabilité du backend. Lorsque le modèle ne doit pas déterminer une valeur, il convient de l’exclure complètement de son schéma. Cela correspond à la règle du contexte de exécution : les valeurs fiables restent en dehors des limites des capacités du modèle et ne figurent jamais dans les arguments générés par celui-ci.
Deuxièmement, quel que soit le nom utilisé par le système source, il peut rester invisible pour l’agent. Un fournisseur ou un service hérité peut publier des opérations conçues pour des développeurs humains, ce qui ne convient pas bien à un LLM chargé de choisir parmi 80 outils. Le gateway peut proposer un vocabulaire plus ordonné sans avoir à demander à l’équipe source de renommer leur API.
Troisièmement, le contrat de l’agent peut rester stable tandis que le backend évolue. Cela est plus important qu’il n’y paraît au premier abord. Même si le backend passe à une nouvelle version de l’API Salesforce, renomme un paramètre interne ou transforme une opération en une paire d’opérations, l’outil que voit le modèle n’a pas besoin de changer du tout. La couche de transformation agit comme une couche de protection entre celui qui consomme la fonctionnalité et celui qui la met en œuvre. Il s’agit d’une architecture logicielle ordinaire, simplement appliquée ici aux interfaces destinées aux agents.
Le contrat du backend sert le système qui possède la fonctionnalité. Ce que la couche MCP présente doit servir l’agent qui va l’appeler.
2. Recherche d’outils : le catalogue devient un contexte recherchable
Ce point devient important dès que l’écosystème se développe. Une première implémentation typique se fait comme suit :
connect to server
↓
list all tools
↓
put every schema into the model context
↓
ask model to choose
Cela fonctionne tant que la liste est courte, mais devient de plus en plus gourmand en ressources à chaque outil ajouté. L’approche plus mature se présente comme suit :
small discovery interface
↓
search relevant capabilities
↓
load only matching schemas
↓
execute
La fonction de recherche d’outils de FastMCP rend cette idée concrète. Au lieu de renvoyer le catalogue complet, le serveur expose des outils de découverte synthétiques tels que search_tools et call_tool. Les stratégies intégrées actuellement sont la correspondance régulière et le classement BM25. BM25 est un système de classement lexical, et non une recherche vectorielle sémantique, mais l’architecture n’est pas dépendante de BM25. Sur votre propre plateforme, le classement peut provenir de mots-clés, d’embeddings, d’un récupérateur hybride avec réclassement, de filtres de métadonnées, de statistiques d’utilisation, d’une évaluation tenant compte des politiques, ou d’un index conçu spécifiquement pour les capacités de votre domaine.
Le point clé est que les outils deviennent des objets pouvant être récupérés. Au lieu d’insérer 300 définitions d’outils dans le contexte, le modèle peut appeler search_tools("find customer opportunities and open deals") et obtenir trois ou quatre résultats, par exemple salesforce_find_account, salesforce_list_opportunities et salesforce_get_pipeline_summary. Seuls ces schémas passent à l’étape suivante.
Cela représente bien plus qu’une simple économie de ressources. Cela améliore les choix auxquels le modèle est confronté. « Choisir une fonctionnalité parmi 300 schémas » et « rechercher des fonctionnalités liées à cette tâche, puis choisir parmi les quatre résultats pertinents » constituent des problèmes de raisonnement très différents.
La découverte progressive est également au cœur des approches d’exécution de code, mais la recherche d’outils est utile même si vous ne lancez jamais de code écrit par un modèle, et elle fonctionne avec des appels d’outils tout à fait ordinaires. Une règle de sécurité doit être reprise du travail d’autorisation : il faut rechercher dans le catalogue que l’utilisateur a le droit de découvrir, et non dans le catalogue complet de la plateforme. Si la recherche affiche les noms et les schémas des outils administratifs interdits, des détails sur les capacités ont fuité, même si l’exécution est refusée par la suite. Le véritable pipeline nécessite donc un filtre d’autorisation avant la recherche.
Considérez cela comme un ingénierie de contexte appliquée aux capacités.
3. Espace de noms : la composition crée d’abord un problème d’identité avant un problème d’échelle
Dès que l’on commence à combiner des serveurs MCP, un problème extrêmement ennuyeux apparaît immédiatement : chaque serveur dispose de noms génériques tels que search, get_user, list_files ou create_note. Lorsqu’on fusionne un serveur Salesforce, un serveur Google Drive, un serveur de base de connaissances et un serveur GitHub, dont trois exposent la fonction search, les questions s’accumulent. Quel search est appelé par le modèle ? Lequel apparaît dans les journaux ? Lequel est couvert par une règle de politique ? Lequel a changé lorsqu’un empreinte de schéma a été modifiée ?
C’est pourquoi les noms d’espace sont importants une fois que MCP cesse d’être un serveur isolé. FastMCP propose une transformation des noms d’espace qui ajoute un préfixe aux composants lors de leur composition, de sorte que search devient salesforce_search, gdrive_search, knowledge_base_search et github_search. Les URI des ressources peuvent également être dotés de noms d’espace dans leur chemin.
Éviter les collisions est l’avantage évident. La traçabilité des origines en est un autre plus subtil : un préfixe enregistre l’origine d’une capacité, et cette origine alimente les règles de politique, les journaux d’audit, le suivi, les limites de vitesse, la propriété, les migrations, le débogage ainsi que les descriptions lues par le modèle.
N’allez pas trop loin cependant. Un nom tel que enterprise_internal_platform_team_alpha_salesforce_v2_search_customer n’est pas forcément meilleur simplement parce qu’il est unique au niveau mondial. Un espace de noms permet d’établir une identité, et des transformations peuvent encore rendre l’interface finale agréable pour le modèle. Il s’agit de deux problèmes liés mais distincts :
Source identity
→ Namespace
Agent usability
→ Transformation
4. Visibilité : l’ingénierie de contexte ne concerne pas seulement le texte
Lorsqu’on parle d’ingénierie de contexte, la plupart des gens pensent aux prompts système, aux documents récupérés, à la mémoire, à l’historique des conversations et éventuellement aux descriptions des outils. Pourtant, toutes les capacités que le modèle peut percevoir font également partie de son contexte.
Prenons un flux de travail de recherche client. Que ferait le modèle avec des outils tels que rotate_api_key, terminate_employee, rebuild_search_index, publish_release et admin_delete_tenant, même si l’utilisateur dispose des droits sur certains d’entre eux ? Rien de tout cela ne sert à l’objectif. Une interface plus ordonnée pourrait être :
Customer Research
├── salesforce_find_account
├── salesforce_list_opportunities
├── knowledge_search
├── web_research
└── generate_customer_report
La visibilité en temps de exécution gère cela. La visibilité des composants de FastMCP vous permet d’activer ou de désactiver des composants par nom, clé ou étiquette ; un composant désactivé disparaît des listes et ne peut pas être résolu via l’interface serveur habituelle. Les ensembles de fonctionnalités spécifiques aux workflows, les flags de fonctionnalité, les différences d’environnement, les outils bêta, les fenêtres de maintenance, les produits spécifiques aux utilisateurs, les profils d’agent, ou tout simplement un espace d’action plus restreint pour le modèle utilisent tous le même mécanisme :
workflow = customer_research
include:
salesforce.*
knowledge_base.*
reports.*
exclude:
admin.*
deployment.*
hr.*
La distinction par rapport au travail de sécurité reste valable : la visibilité ne remplace pas l’autorisation. La visibilité permet de déterminer si une capacité fait partie de l’ensemble actuel. L’autorisation permet de savoir si le principal authentifié a réellement le droit de l’utiliser. Une bonne plateforme MCP d’entreprise souhaite généralement disposer des deux, en réduisant d’abord l’ensemble des capacités disponibles et en appliquant ensuite les règles d’autorisation.
5. Proxy MCP : un serveur en tant que passerelle vers d’autres
Le design devient alors vraiment intéressant. Un serveur n’a pas besoin de posséder toutes les capacités qu’il propose ; il peut se placer en avant d’autres serveurs MCP. Le fournisseur de proxy de FastMCP récupère des outils, des ressources et des prompts depuis un serveur MCP distant et les republie depuis le serveur actuel.
Ainsi, on obtient une chaîne simple comme celle-ci :
AI client
↓
Salesforce MCP
il peut évoluer pour devenir une passerelle gérant plusieurs serveurs en amont, et cette passerelle n’a pas besoin de copier leur logique métier. Elle agit comme un proxy pour leurs fonctionnalités et ajoute une couche de plateforme autour d’elles : authentification, politiques, nommage, visibilité, observabilité.
Cela représente un changement majeur dans la conception des systèmes : les serveurs MCP cessent d’être des entités isolées et peuvent former un réseau. Une équipe peut être chargée de l’intégration avec Salesforce, une autre des connaissances liées au projet, et une autre encore des opérations d’infrastructure, tandis que la passerelle d’entreprise assemble tout cela en une seule interface sans obliger les équipes à utiliser un répertoire ou un cycle de publication commun.
Les proxies présentent également des avantages moins spectaculaires : ils relient les différents transports, fournissent une adresse finale stable face à des serveurs en constante évolution, centralisent l’authentification, améliorent la capacité d’observation, appliquent des politiques uniformes, organisent les noms et protègent la topologie interne des clients.
Rien de tout cela ne signifie que chaque entreprise a besoin d’un unique gateway central géant. Vous pouvez en mettre en place plusieurs, classées par domaine : ingénierie, ventes, recherche, opérations de plateforme. MCP fournit les limites protocolaires qui vous permettent de les combiner de manière propre.
Dès que les serveurs MCP peuvent consommer et transformer les données les uns des autres, l’unité naturelle de conception n’est plus un seul serveur, mais plutôt un graphe de capacités gérées.
6. Les compétences en tant que ressources MCP : un serveur peut distribuer des connaissances, pas seulement des actions
Les outils répondent à la question de ce que le système peut faire. Les ressources répondent à la question des informations que le client peut obtenir. Les compétences introduisent une troisième question : comment un agent doit-il exécuter un type de tâche donné ?
Une compétence se trouve généralement dans un répertoire contenant des instructions ainsi que du matériel de soutien tel que des exemples, des schémas, des scripts, des listes de contrôle, des références ou des directives sectorielles. Ces répertoires se trouvaient traditionnellement à l’intérieur de l’environnement d’un client, dans des emplacements tels que ~/.claude/skills/, ~/.cursor/skills/ ou ~/.gemini/skills/. Le fournisseur de compétences de FastMCP les publie plutôt en tant que ressources MCP, de sorte qu’une compétence dispose d’adresses de type skill://customer-research/..., couvrant son fichier SKILL.md principal, un manifeste, un fichier d’exemples et un schéma JSON.
Cela est plus important qu’il n’y paraît, car le serveur peut désormais distribuer des connaissances procédurales en même temps que des capacités exécutables. Imaginez une plateforme interne de recherche client dont l’interface MCP propose des outils tels que search_salesforce, search_knowledge_base et generate_report, ainsi que des compétences décrivant la manière dont l’équipe définit une opportunité qualifiée, la méthodologie de recherche, le format attendu du rapport, les exigences en matière de preuves et des exemples de rapports de qualité.
Le outil indique à l’agent ce qu’il peut exécuter. La compétence lui précise comment votre organisation attend que le travail soit accompli. La séparation est utile : vous n’avez pas besoin d’intégrer chaque procédure opérationnelle dans un seul prompt système géant, et vous n’avez pas non plus à copier manuellement la même compétence dans chaque client IA. Un client qui comprend les ressources MCP peut découvrir et récupérer la compétence via le même protocole, tandis qu’un client limité aux outils peut encore accéder aux ressources grâce à une couche d’adaptation qui les encapsule sous des appels d’outils.
Un serveur MCP peut regrouper les capacités, le contexte et les connaissances opérationnelles en une seule entité réutilisable.
7. Élicitation : permettre à une capacité de poser une question à l’utilisateur
La interaction la plus simple avec les outils est unidirectionnelle : le modèle appelle un outil et celui-ci renvoie un résultat. Les workflows réels sont bien plus complexes. Supposons que l’utilisateur demande la création d’un nouvel environnement cloud pour le projet d’analyse, et que l’outil trouve trois régions valides ainsi que deux profils de déploiement. Ou bien il s’avère que l’environnement demandé coûtera environ 420 dollars par mois. Ou encore deux comptes Salesforce aux noms presque identiques apparaissent. La prochaine étape appropriée n’est pas toujours de deviner ; parfois, c’est l’outil lui-même qui doit poser des questions.
C’est l’idée à l’origine de l’élucidation via MCP. FastMCP dispose d’une API pratique pour demander des entrées structurées à l’utilisateur, mais ce modèle fait partie de MCP et non d’un framework Python en particulier.
La spécification MCP du 2026-07-28 a réorganisé cet échange autour des demandes multi-allers-retours (MRTR), afin qu’il corresponde au nouveau modèle de protocole sans état, plutôt que de dépendre d’une session restée ouverte dans les deux sens. Ce qui a changé, c’est le mécanisme utilisé pour la transmission des données. La capacité elle-même a survécu : une opération serveur peut toujours être suspendue en attendant une entrée de l’utilisateur au milieu d’un flux de travail. Les utilisations typiques incluent la résolution d’entités ambiguës, le complément de paramètres manquants, la confirmation d’opérations coûteuses, la révision du contenu généré avant sa publication, le choix d’un environnement cible, ainsi que la collecte progressive d’informations structurées.
Une précaution de sécurité s’impose ici : demander l’avis de l’utilisateur ne constitue pas une autorisation. Lorsque la suppression nécessite une approbation, le système backend doit lui-même stocker et appliquer cet état d’approbation. Une question polie du type « Êtes-vous sûr ? » en langue naturelle ne suffit pas. Pour les opérations sensibles, l’intervention humaine doit entraîner un véritable changement d’état.
8. Journalisation : utile pour le client, mais l’observabilité en production va plus loin
La journalisation se divise en deux concepts distincts. Le premier concerne les informations destinées au client concernant l’exécution : « Recherche dans Salesforce… 18 opportunités correspondantes trouvées… Génération du rapport… Rapport créé. » Le second concerne l’observabilité en production : identifiants du suivi, de la demande, du principal et du locataire, ainsi que le nom de l’outil, du fournisseur, la latence, les tentatives de réessai, le verdict de la politique, tout ID de tâche et le code d’erreur. Traitez-les comme des tâches différentes.
FastMCP continue de prévoir un mécanisme d’journalisation côté client, permettant à un serveur d’envoyer des messages de débogage, d’information, d’avertissement ou d’erreur à un client MCP qui les prend en charge. Cela facilite le développement et donne au client une idée de ce que fait une fonctionnalité donnée. Cependant, un changement important du protocole est prévu pour 2026 : la fonctionnalité d’journalisation propre au protocole a été dépréciée pour les nouvelles implémentations dans MCP à partir de 2026-07-28. Par conséquent, une nouvelle architecture d’observabilité en production ne devrait pas dépendre des messages d’journalisation MCP. Privilégiez plutôt une observabilité standard de l’application : journaux structurés, traces OpenTelemetry, métriques, Datadog, Grafana et Tempo, CloudWatch, ELK, ou tout autre outil déjà utilisé par votre organisation.
Une façon de le comprendre : les messages d’état permettent à l’utilisateur ou à l’hôte de suivre ce qui se passe, tandis que la télémétrie côté serveur aide les équipes d’ingénierie, de sécurité et d’opérations à comprendre le système. Dans un déploiement d’entreprise, ce second type est indispensable. Une requête utilisateur peut voyager depuis un hôte IA via un gateway MCP, jusqu’à un serveur proxy, puis vers une API SaaS, et enfin à un travailleur en arrière-plan ; une seule trace doit permettre d’expliquer l’ensemble de ce parcours. Plus il est facile de proxyer et de composer MCP, plus cette vision distribuée devient importante.
9. Tâches en arrière-plan : une capacité peut avoir un cycle de vie d’exécution
La séquence classique d’appel consiste en une demande, une exécution, puis un résultat, et suppose que le travail tient dans une seule demande. De nombreuses fonctionnalités d’entreprise précieuses ne correspondent pas à ce modèle : un rapport client de 60 pages, l’indexation de 20 000 documents, une analyse de gros volumes de données, une exportation complète des opportunités Salesforce, la création d’une présentation avec des documents d’appui, un contrôle de conformité, ou encore un grand lot de records. De tels travaux peuvent durer des minutes, nécessiter des tentatives répétées, survivre à une interruption de connexion du client, indiquer leur progression, ou s’exécuter sur un travailleur différent de l’endpoint MCP.
L’extension MCP Tasks offre un cycle de vie propre au protocole pour les exécutions de longue durée. Les tâches en arrière-plan de FastMCP le montrent clairement : un composant est marqué comme capable d’exécuter des tâches, le client reçoit un identifiant de tâche, et l’exécution est transférée à un travailleur en arrière-plan géré par un système de tâches, au lieu de maintenir l’appel initial ouvert.
Cela diffère de l’écriture de asyncio.create_task(...). La concurrence en Python conserve le travail à l’intérieur de son processus, tandis qu’une tâche au niveau du protocole établit un contrat entre le serveur et le client pour des tâches à long terme, ce qui confère à cette capacité un cycle de vie compris par le client. Un autre indice indiquant qu’un serveur MCP devient une véritable interface d’application et non simplement un émulateur RPC : sa fonction n’est pas seulement d’appeler une fonction et de retourner du JSON. Il peut également devoir lancer des tâches, gérer l’état, afficher l’avancement, respecter les demandes de suppression, se remettre de défaillances et restituer le résultat ultérieurement.
10. Versionning : lorsque les agents dépendent de vos outils, le schéma constitue une API
Toute plateforme interne réussie arrive à un moment où quelqu’un modifie le schéma et endommage un consommateur dont personne ne connaissait l’existence. MCP n’est pas magiquement immunisé contre cela.
Supposons que la version 1 d’une capacité soit calculate_risk(project_id), et que la version 2 devienne calculate_risk(project_id, methodology="v2", include_history=True). Si vous déployez le nouveau contrat simultanément auprès de tous les agents et clients, vous introduisez un changement API qui brise la compatibilité.
La versionnement des composants de FastMCP permet à plusieurs implémentations d’un outil, d’une ressource ou d’une instruction d’exister sous un même identifiant logique. Par défaut, c’est la version la plus récente qui est fournie, et les filtres de version permettent de créer des interfaces distinctes pour des clients spécifiques ou des périodes de migration particulières.
L’architecture globale est plus importante que l’API spécifique. Une fois que MCP devient une infrastructure partagée, son évolution doit faire l’objet de la même réflexion que celle de tout contrat de service public. Quelles modifications causent des problèmes ? Quels clients dépendent encore de la version v1 ? Les versions v1 et v2 peuvent-elles fonctionner côte à côte, et combien de temps doit durer la fenêtre de migration ? Quelle version a été approuvée pour le déploiement en production, qui a accès à quelle version, et à quel moment l’ancienne version sera-elle retirée ? Un registre d’entreprise utile pourrait éventuellement enregistrer le nom de l’outil, le fournisseur, la version, l’empreinte du schéma, le propriétaire, la classe de risque, la date d’approbation ainsi que le responsable de l’approbation, et la date de dépréciation.
Cela peut sembler excessif pour un serveur disposant de cinq outils. Ce n’est pas le cas pour une plateforme qui sert 20 équipes.
Dès qu’un autre système dépend de votre schéma MCP, il s’agit d’une API, qu’elle soit nommée ou non.
11. Tests : vérifier l’ensemble de MCP, et pas seulement la fonction Python
Le testage est l’aspect le moins spectaculaire ici, mais il est très probablement le plus important. Imaginez que cette fonction fonctionne sans aucun défaut :
async def find_customer(company_name: str):
...
Même ainsi, le serveur MCP peut être défectueux, avec la panne située n’importe où dans cette fonction : un schéma généré incorrectement, une description trompeuse, une transformation qui cache le mauvais argument, un espace de noms qui renomme discrètement l’outil, une visibilité qui expose des capacités administratives, un filtrage d’autorisation destiné au mauvais utilisateur, un proxy qui ne transmet pas les identifiants, une couche de recherche incapable de localiser l’outil, un filtre de version qui sert la version v1 alors que v2 était prévu, une sortie qui ne correspond pas à sa structure, ou un job en arrière-plan qui n’atteint jamais d’état final.
C’est pourquoi il est préférable de tester l’interface MCP réelle. Les directives de test de FastMCP font fonctionner un client réel contre le serveur en interne, ce qui permet de tester le comportement du protocole sans déployer de service distinct. Au lieu de ne tester que l’implémentation :
result = await find_customer("Acme")
assert result
Testez également ce que le consommateur MCP voit réellement :
async with Client(mcp) as client:
tools = await client.list_tools()
assert "salesforce_find_customer" in {
tool.name for tool in tools
}
result = await client.call_tool(
"salesforce_find_customer",
{"company_name": "Acme"},
)
Pour une plateforme de capacités de production, au moins quatre couches méritent d’être testées.
Les tests de contrat vérifient que le nom de l’outil, sa description, ses schémas d’entrée et de sortie, ses annotations ainsi que sa version correspondent aux attentes.
Les tests de découverte permettent de déterminer quels outils un utilisateur et un flux de travail donnés peuvent voir et lesquels restent cachés, si la recherche trouve bien la capacité souhaitée, et si elle ne met pas par erreur en évidence des capacités interdites.
Les tests d’exécution vérifient si l’appel réussit, si les erreurs sont correctement structurées, si les tentatives de réexécution sont sûres, si les proxies transmettent correctement l’identité, et si l’autorisation est vérifiée à nouveau au moment de l’exécution.
Les tests de cycle de vie s’assurent que les tâches en arrière-plan se terminent ou échouent proprement, qu’elles peuvent être annulées, que la migration de version permet aux anciens clients de continuer à fonctionner, et ce qui se passe lorsque le serveur MCP en amont est indisponible.
Rien de tout cela ne vise à tester le framework. Il s’agit plutôt de tester le contrat de votre produit. Une fois que MCP devient la couche de fonctionnalités pour plusieurs clients et agents, ce contrat mérite la même rigueur que celle appliquée aux interfaces REST, gRPC ou basées sur des événements.
En assemblant les éléments, le serveur prend une tout autre apparence
En combinant toutes ces idées, on obtient un système capable de gérer la découverte, le routage, l’adaptation des interfaces, le contrôle du contexte, les politiques, les workflows interactifs, l’exécution asynchrone, les connaissances opérationnelles réutilisables, la compatibilité ainsi que tout le cycle de vie technique. Il ne s’agit plus depuis longtemps d’un simple serveur équipé de quelques outils ; c’est plutôt une interface de produit. De plus, rien dans tout cela ne nécessite que le fournisseur du modèle possède la logique métier, car la même plateforme peut être utilisée derrière n’importe quel hôte compatible MCP choisi par l’organisation. C’est là l’aspect stratégiquement important.
Une partie des meilleures optimisations a lieu avant même que le modèle ne voie quoi que ce soit
De nombreux débats sur les performances des IA portent sur le modèle lui-même : lequel choisir, combien de paramètres, quelle taille pour la fenêtre de contexte, quelle est sa capacité de raisonnement. Tout cela est important, mais en environnement de production, l’architecture entourant le modèle peut éliminer une quantité énorme de tâches inutiles.
Disons que la plateforme dispose de 300 outils. Une conception naïve insère tous ces 300 schémas dans le contexte du LLM en espérant qu’il fera un bon choix. Une conception réfléchie réduit progressivement ce nombre. Les politiques de filtrage ramènent 300 à 85 outils autorisés. La visibilité des workflows en élimine 24 qui ne sont pas pertinents. La recherche ne laisse que 4 candidats, et ce sont uniquement ces 4 schémas qui sont chargés pour le choix final du modèle.
Le modèle n’est pas devenu plus intelligent. Le système, si. C’est en grande partie pour cette raison que ces schémas sont importants en environnement de production : le contexte se réduit, la précision du choix s’améliore, les actions irrelevantes disparaissent, l’autorisation devient plus claire, les contrats backend restent à l’écart du modèle, et les équipes indépendantes peuvent collaborer sans fusionner de code, tout cela avant même que l’LLM ne soit invité à réfléchir à sa prochaine action.
Une excellente architecture d’agent ne se limite pas à améliorer la capacité de raisonnement du modèle. Elle façonne également le matériel sur lequel le modèle doit raisonner.
De un serveur MCP à un réseau de serveurs MCP
Pour les systèmes d’entreprise, c’est là que l’évolution devient vraiment intéressante. L’unité originale ressemblait à ceci :
AI client
↓
MCP server
↓
API
La prochaine unité ressemble davantage à une passerelle au centre, avec des serveurs de domaine et des travailleurs derrière elle. Chaque serveur MCP reste concentré sur sa tâche, chaque équipe gère son propre domaine, et chaque service est déployé selon son propre calendrier. La passerelle crée l’interface appropriée pour chaque utilisateur, le modèle ne découvre que ce dont il a besoin, un long flux de travail est transformé en tâche, et une compétence enseigne à l’agent la manière dont l’entreprise souhaite que le flux de travail se déroule, tout en restant accessible à travers les limites de MCP.
Cela ressemble beaucoup plus à une plateforme d’applications distribuées qu’à un ensemble de wrappers de fonctions, c’est pourquoi qualifier les serveurs MCP de « simples outils pour les LLM » sous-estime de plus en plus ce qu’ils deviennent réellement.
Ne construisez pas de plateforme avant qu’un problème de plateforme ne se pose
Le danger est évident. Après avoir lu tout cela, on pourrait en conclure que votre serveur interne doté de cinq outils nécessite trois passerelles, un registre des capacités, une fonction de recherche intégrée aux schémas des outils, quelques noms d’espace, une négociation de version en temps de exécution, une file d’attente distribuée pour les tâches, un marché pour les compétences et une douzaine de transformations imbriquées.
S’il vous plaît, ne le faites pas.
Un serveur avec six outils stables que tous les utilisateurs devraient voir ? Envoyez simplement ces six outils. Si le schéma backend est déjà propre, n’ajoutez pas de transformation juste parce qu’un framework la prend en charge. Avec un seul serveur, il n’y a pas besoin d’une topologie de proxy. Si une opération se termine en deux secondes, elle n’a probablement pas besoin d’une tâche. Si personne ne consomme plus la version v1, il n’y a aucune raison de garder deux versions actives indéfiniment.
L’architecture doit naître en réponse à un problème, et non l’inverse. L’objectif n’est pas de maximiser le nombre de fonctionnalités du framework dans votre répertoire. Il s’agit plutôt de faire en sorte que, lorsque le problème se présente, MCP ne vous oblige plus à créer une plateforme d’IA entièrement personnalisée autour de lui. L’écosystème fournit désormais des blocs de construction réutilisables pour les mêmes problèmes que rencontre toute plateforme d’application mature, et c’est là un progrès.
Le framework peut être remplacé ; c’est l’architecture qui compte
FastMCP mérite d’être reconnu pour avoir rassemblé de nombreuses de ces idées en un seul endroit. Ses documents expliquent en détail les fournisseurs, les transformations, la recherche, l’espacement des noms, la visibilité, le proxying, les compétences, l’élucidation, les tâches, les versions et les tests, ce qui permet de comprendre facilement comment les différentes composantes d’un serveur MCP sont liées. Plusieurs de ces modèles sont utilisés en production car ils résolvent des problèmes concrets : réduire le contexte des outils, séparer les contrats destinés aux modèles de ceux destinés au backend, limiter les fonctionnalités exposées, intégrer des solutions ensemble et rendre l’ensemble plus facile à gérer.
Néanmoins, les équipes devraient s’inspirer de cette idée et non de l’API de la bibliothèque. Se demander : avons-nous besoin d’une découverte d’outils à la demande ? D’une couche de transformation orientée vers les modèles ? D’un guichet d’accès aux fonctionnalités ? D’une visibilité spécifique aux workflows ? De compétences distribuées via des ressources MCP ? D’un cycle de vie fiable pour les opérations longues ? De contrats de fonctionnalités versionnés ? Testons-nous bien ce que voit réellement le client ? Ensuite, construisez les solutions avec le stack qui convient le mieux à votre organisation.
Le protocole assure l’interopérabilité. Le framework apporte la commodité. L’architecture reste entre vos mains.
Qu’est-ce qui a changé
Le changement le plus important dans MCP ne réside pas dans une liste de fonctionnalités plus longue. Il s’agit plutôt de l’élargissement progressif des capacités attendues d’un serveur MCP. Au début, le principe était simple : publier un outil, le modèle l’appelait et un résultat était retourné. Le modèle qui prend maintenant forme implique l’obtention de capacités provenant de plusieurs systèmes, la normalisation de leurs contrats, l’organisation des identités selon des noms spécifiques, le filtrage en fonction de la pertinence, l’autorisation de ce qui est permis, la recherche dans de grands catalogues sur demande, la distribution de compétences et de contextes réutilisables, la pose de questions à l’utilisateur lorsqu’un choix est nécessaire, le transfert des tâches lentes vers une exécution fiable, l’observation de l’ensemble du processus, la versionning des contrats et le test du produit en tant que tel.
C’est un travail complètement différent. MCP reste délibérément un protocole et non un framework d’application, mais l’écosystème qui l’entoure en fait des serveurs MCP une véritable frontière d’application, où des couches de routage, de gouvernance, de cycle de vie, de compatibilité et de composition peuvent être développées comme dans des backends matures.
Un serveur MCP bien conçu n’est plus simplement un moyen d’ajouter une fonction supplémentaire à un LLM. Il peut devenir un produit de capacités réutilisables qui sert à la fois des agents, des modèles, des équipes et des applications clientes. Un serveur isolé peut rester de petite taille, tandis qu’un réseau de tels serveurs peut évoluer pour devenir une plateforme d’entreprise. Le modèle reste flexible, la couche de capacités reste gérée, et le client en surface peut être remplacé sans devoir reconstruire la capacité métier qui se trouve en dessous.
Lectures complémentaires
- MCP 2026-07-28 : Comment la spécification sans état modifie la conception des serveurs distants — Comment la version 2026-07-28 sans état de MCP élimine les sessions et la procédure de connexion, ajoute MRTR, des tâches et des indications de cache, et quelles en sont les conséquences pour la migration.
- Navigateur Cloud : Une plateforme de navigateur distant sécurisée pour tout agent IA — Une conception de référence pour un service de navigateur distant neutre par rapport aux modèles : passerelle, travailleurs, vue en direct via WebRTC, validations, protections contre SSRF, fonction de réexécution, ainsi que chaque paramètre de configuration.