Ce que Blender MCP révèle sur la création de serveurs MCP utiles

La plupart des travaux d’ingénierie commencent par une configuration familière : quelqu’un ouvre l’application que vous avez développée.

Vous concevez le tableau de bord, décidez où se trouveront les boutons et essayez de mettre en évidence clairement les actions importantes. L’utilisateur utilise simplement une partie de votre interface pour accomplir sa tâche.

L’utilisateur a-t-il vraiment besoin d’ouvrir votre tableau de bord ?

Parfois, la réponse est encore oui. Remplacer un bouton fonctionnel par trois paragraphes de conversation n’est pas une amélioration. Mais pour de nombreux flux de travail, forcer quelqu’un à utiliser la navigation de votre application ne fait qu’ajouter des obstacles sans apporter de valeur.

C’est la raison fondamentale pour laquelle les serveurs MCP risquent de devenir de plus en plus importants. Blender MCP est une bonne illustration de ce à quoi cela peut ressembler dans la pratique, et il soulève également quelques questions moins reluisantes concernant la manière de développer, de maintenir et d’évaluer ces intégrations au fil du temps.

Ces questions moins reluisantes sont précisément ce qui a motivé le travail sur Pulse.

Qu’est-ce que MCP, et comment fonctionnent les serveurs MCP ?

MCP est l’abréviation de Model Context Protocol, un standard ouvert permettant de relier les applications d’IA à des outils et des sources de données externes. Un serveur conçu selon ce standard peut exposer des outils capables d’effectuer des actions, des ressources fournissant du contexte, ainsi que des prompts pouvant être réutilisés. Cet article se concentre spécifiquement sur les outils.

L’architecture sépare l’application d’intelligence artificielle, appelée hôte, des clients et serveurs MCP avec lesquels elle communique. L’hôte est chargé d’orchestrer ces interactions. Un client découvre quels outils sont disponibles en appelant tools/list, puis déclenche l’outil choisi à l’aide de tools/call. Le serveur exécute la logique correspondante et renvoie un résultat. Les serveurs eux-mêmes peuvent être hébergés localement ou accessibles à distance.

Pour une intégration de produit simple, la séquence peut ressembler à ceci :

User asks for something
 → AI application selects an available tool
 → MCP client sends the call
 → Your MCP server checks access and runs the operation
 → Result returns to the AI application

MCP ne décide ni du fait que le modèle doive utiliser un outil, ni du sens de la demande de l’utilisateur, ni de la qualité de la réponse finale. Le protocole relie les composants entre eux, mais l’application globale doit toujours gérer leur fonctionnement collectif.

L’envoi d’un serveur ne garantit pas non plus que chaque assistant IA le détectera automatiquement. VS Code, par exemple, exige des étapes explicites pour installer, configurer et accorder de la confiance à un serveur MCP. Il existe toujours des limites réelles en matière d’intégration et de permissions à surmonter.

Ce que Blender MCP démontre réellement

Le projet développé par la communauté ahujasid/blender-mcp relie les clients IA à Blender grâce à un serveur MCP basé sur Python associé à une extension Blender. Il permet d’inspecter les scènes, de manipuler des objets et des matériaux, ainsi que d’exécuter du code Python directement à l’intérieur de Blender. Il convient de noter qu’il s’agit d’une intégration tierce, et non d’un élément fourni officiellement par Blender.

Sa architecture ressemble approximativement à ceci :

AI application / MCP client
  ↕ MCP
Python MCP server
  ↕ Project-specific socket connection
Blender add-on
  ↕
Blender scene and operations

Ce séparement est important. MCP gère l’interface entre le client et le serveur. Ce qui se passe entre le serveur et Blender dépend entièrement de l’implémentation. Tout serveur MCP a néanmoins besoin de son propre mécanisme pour faire fonctionner réellement le logiciel sous-jacent.

Imaginez demander à un assistant d’examiner une scène, de déplacer quelques objets et d’ajuster leurs matériaux. Avec une telle intégration, l’assistant peut effectuer des opérations directement sur la scène, au lieu de se contenter de décrire quels menus cliquer. Le fait que le résultat soit vraiment bon est une question complètement distincte.

Ce qui ressort ici, c’est que tout le travail réel a encore lieu à l’intérieur de Blender. L’application, son ensemble de fonctionnalités existantes et votre capacité à examiner ce qui a changé restent au cœur du processus.

Cette approche semble susceptible de se manifester dans d’autres types de logiciels également : quelqu’un demande un changement spécifique, vérifie le résultat à l’aide de l’interface familière, puis revient au travail manuel lorsque c’est plus rapide.

Cela semble bien plus réaliste que d’attendre des gens qu’ils abandonnent leurs outils existants pour tout faire via une fenêtre de chat.

MCP vs APIs : qu’est-ce qui change réellement ?

Ce qui change réellement, c’est l’existence désormais d’une interface commune permettant de mettre en œuvre des fonctionnalités auprès de tout client compatible. Les outils sont décrits à l’aide de définitions qui énumèrent les actions disponibles ainsi que leurs paramètres d’entrée, de sorte que chaque intégration client n’a plus besoin d’inventer ses propres conventions de découverte et d’appel.

Il est utile de considérer cela comme un troisième point d’accès au produit, situé à côté de l’interface utilisateur existante et de l’API existante.

Prenons un système d’inventaire comme exemple. La logique métier connaît déjà comment rechercher un produit, vérifier s’il est en stock et réserver des unités de celui-ci. Réutiliser cette logique est bien plus judicieux que d’écrire une implémentation parallèle uniquement pour alimenter un assistant IA.

Cela dit, le cas d’usage de MCP n’est pas inconditionnel. Si vous travaillez avec un seul script interne qui communique avec une API connue, l’appel direct reste probablement la solution la plus simple. MCP devient utile lorsque vous avez réellement besoin de compatibilité entre plusieurs clients d’IA, ou lorsque une interface d’outil réutilisable résout un problème concret que vous rencontrez. Ajouter un autre protocole simplement parce qu’il est populaire en ce moment signifie encore un protocole de plus à maintenir.

Créer des outils MCP, c’est aussi concevoir une interface

C’est l’étape pour laquelle il vaut la peine de ralentir.

Pour une application de catalogue hypothétique, une définition de départ raisonnable pourrait ressembler à ceci :

{
  "name": "search_catalog",
  "description": "Find products in the authorized catalog by name or SKU. Returns product IDs, names, and availability. Read-only; does not reserve stock.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "minLength": 1 },
      "limit": { "type": "integer", "minimum": 1, "maximum": 20 }
    },
    "required": ["query", "limit"],
    "additionalProperties": false
  }
}

Ceci est donné à titre d’illustration de la définition d’une outil, et non comme une implémentation complète serveur ou un véritable outil MCP de Blender. Le nom, la description ainsi que le contrat d’entrée JSON Schema présentés ici suivent le format spécifié par MCP.

La description précise ce que l’outil peut rechercher, ce qu’il renvoie et ce qu’il ne fait délibérément pas. Ses entrées ont une portée restreinte. La réservation de stock est conservée en tant qu’action distincte intentionnellement, car elle entraîne des conséquences différentes d’une simple recherche.

Néanmoins, qualifier quelque chose de « autorisé » dans une description ne le rend pas réellement tel. L’application effective des contrôles d’accès et de la validation des entrées doit avoir lieu dans l’implémentation. Toute action ayant des conséquences réelles nécessite également une étape de confirmation appropriée. Les directives de sécurité de MCP pour les outils abordent directement ces responsabilités.

Blender MCP illustre clairement ce compromis : son outil d’exécution en Python est véritablement puissant, et le projet lui-même met en garde explicitement contre les dangers liés à la possibilité pour un assistant d’exécuter du code arbitraire.

Pour vos propres outils de production, il est judicieux de partir du plus petit ensemble d’autorisations réellement utile, en l’élargissant uniquement lorsqu’il y a une raison concrète de le faire. Il est également utile de tester les outils avec des requêtes réelles. Une description qui vous semble claire n’est pas une preuve que l’agent la interprétera et l’utilisera correctement.

Comment savoir si un serveur MCP est utile ?

Elle ne vous dit rien sur le fait que les utilisateurs continuent d’utiliser l’outil, quelles fonctionnalités spécifiques ils exploitent, ou ce qui échoue lorsque des demandes réelles sortent du scénario que vous avez programmé.

Prenons un serveur de catalogue comme exemple. Vous souhaitez savoir si la fonction search_catalog est réellement appelée, si le déploiement d’une nouvelle version ralentit son traitement, et si les pannes se concentrent autour d’une opération particulière plutôt que de se répartir uniformément.

L’interprétation exige également de la prudence ici. Une augmentation du nombre d’appels aux outils peut refléter un travail véritablement utile. Ou bien elle peut indiquer qu’un agent tente à nouveau quelque chose qui aurait dû fonctionner dès la première tentative. Le simple comptage des appels ne permet pas de distinguer ces deux situations très différentes.

En ce qui concerne le suivi, il s’agit de problématiques distinctes qui doivent être suivies séparément. Les métriques opérationnelles couvrent des éléments tels que la latence et les taux d’erreur. L’analyse des produits révèle les schémas d’utilisation ainsi que, lorsque le contexte d’identité est approprié, les interactions répétées. L’évaluation au niveau des tâches vous indique si le flux de travail global a réellement fourni ce dont l’utilisateur avait besoin.

Cette distinction est importante car un gestionnaire qui renvoie avec succès n’est pas équivalent à une tâche utilisateur terminée. Une appel à un gestionnaire peut réussir sur le plan technique, mais être suivi d’une erreur lors de la validation des données ou au niveau du transport. Même un résultat techniquement valide peut s’avérer inutile pour la personne qui l’a demandé.

Rien de tout cela ne devrait se résumer à un seul indicateur d’état vert qui masquerait cette différence.

Pourquoi je développe Pulse pour les analyses MCP

Ces questions ont motivé la création de Pulse, un SDK open source associé à un service Cloud optionnel hébergé séparément.

Celui-ci est distribué sous la licence MIT. La bibliothèque surveille les terminations des gestionnaires d’outils MCP et peut envoyer ces métadonnées vers une destination locale, vers un collecteur que vous contrôlez, ou via un exportateur OpenTelemetry optionnel. Son utilisation ne nécessite pas de s’inscrire sur Pulse Cloud, et aucun point de terminaison Cloud par défaut n’est intégré discrètement dans l’intégration.

Une configuration locale minimale ressemble à peu près à ceci :

import { McpServer } from '@modelcontextprotocol/server';
import { createPulse } from '@reviseflow/pulse';
import { createJsonlExporter } from '@reviseflow/pulse-core/jsonl';

const analytics = createPulse({
  environment: 'development',
  exporter: createJsonlExporter({
    path: './catalog-events.jsonl',
  }),
});

const server = analytics.wrapServer(
  new McpServer({ name: 'catalog-server', version: '1.0.0' }),
);

// Register tools on `server`, then connect your existing MCP transport.

Cet extrait a pour but d’illustrer l’instrumentation, et non de servir d’implémentation complète de serveur. Il a été écrit pour Pulse 0.2.1 et la version 2.0.0 de @modelcontextprotocol/server, avec Node.js 24.20.0 parmi les environnements de exécution pris en charge. La simple inscription d’un outil ne génère pas de événements d’analyse par elle-même ; seules les invocations réelles des gestionnaires le font. Lors de la fermeture propre, une fois que les gestionnaires en cours d’exécution ont terminé, on appelle await analytics.shutdown({ timeoutMs: 2_000 }).

Cet exemple concerne un serveur MCP basé sur TypeScript. Il n’existe actuellement aucun adaptateur Python dans le SDK capable de gérer des systèmes comme Blender MCP.

Pulse Cloud fournit la couche de stockage gérée ainsi que le tableau de bord basés sur ces métadonnées : les modes d’utilisation des outils, la durée de traitement, le statut du résultat, et la possibilité de filtrer par environnement ou version. Il fonctionne avec son propre flux de telemétrie, de sorte que le trafic réel des outils ne passe jamais par lui.

L’envoi de données vers Cloud est facultatif et explicite, effectué via l’exportateur HTTP en utilisant une URL de collecte ainsi qu’une clé d’écriture côté serveur. Le produit Cloud lui-même est à source fermée, tandis que la couche d’instrumentation sous-jacente reste entièrement ouverte et utilisable indépendamment.

Il est important de maintenir cette distinction claire. Un développeur qui préfère écrire dans des fichiers JSONL locaux, ou qui dispose déjà d’une stack d’observabilité, a toutes les raisons d’adopter la couche open source sans avoir besoin de devenir d’abord client de Cloud.

Une analyse honnête nécessite des limites claires

La télémétrie de Pulse exclut délibérément les commandes brutes, les arguments des outils, leurs résultats, le texte d’erreur, les traces d’exécution et les en-têtes de requête. Même quelque chose d’aussi simple qu’un nom d’outil ou une étiquette technique mérite un examen attentif, car les métadonnées elles-mêmes peuvent divulguer des informations sensibles. Tous les identifiants de compte facultatifs sont conçus pour être pseudonymes, ce qui ne constitue pas une garantie d’anonymat total.

Le point où s’arrêtent les mesures est tout aussi important que ce qu’elles collectent. Pulse peut constater qu’un gestionnaire a été exécuté et combien de temps cela a duré, mais il n’a aucune visibilité sur les raisons pour lesquelles le modèle a choisi cet outil en particulier, sur ce que l’utilisateur essayait réellement d’accomplir, ou sur le fait que le résultat obtenu soit satisfaisant. De plus, il ne peut pas enregistrer une appel qui a été bloqué avant même d’atteindre le gestionnaire.

La livraison des données de télémétrie s’effectue selon les meilleures capacités disponibles : les files d’attente sont limitées et des tentatives de réexpédition ont lieu, mais rien ne garantit que chaque événement arrivera. Un événement de télémétrie manquant n’affecte jamais le résultat réel obtenu par l’utilisateur, mais cela signifie que les données peuvent présenter des lacunes. Ce système est conçu pour l’analyse, et non pour servir de trace d’audit inviolable.

Compte tenu de cela, il semble plus honnête d’énoncer directement ces limites plutôt que d’apposer le terme « observabilité » sur cette fonctionnalité tout en laissant les gens se demander ce qui est réellement suivi et ce qui ne l’est pas.

À l’avenir

Il semble probable qu’une intégration MCP véritablement utile devienne un autre critère utilisé par les gens pour évaluer un produit, en plus des critères habituels.

Un assistant peut-il vraiment offrir les fonctionnalités dont un utilisateur a besoin ? Ses actions sont-elles faciles à suivre et à comprendre ? Une personne peut-elle intervenir pour examiner tout élément important avant qu’il ne se produise ? Et l’intégration continue-t-elle de fonctionner une fois la nouveauté initiale passée ?

Blender MCP se distingue car il présente un exemple concret d’un assistant qui utilise un logiciel réel et existant, plutôt que de se contenter d’en parler. Cette approche semble plus prometteuse qu’un autre chatbot dont la principale fonction est de décrire les étapes que l’utilisateur pourrait effectuer lui-même ailleurs.

Tout cela ne signifie pas pour autant que chaque produit ait besoin d’un serveur MCP dès maintenant, ni que les interfaces graphiques traditionnelles deviennent obsolètes. Cela suggère simplement que certains flux de travail pourraient commencer dans un assistant avant de se poursuivre directement dans l’application elle-même, éliminant ainsi une partie des échanges manuels entre les deux.

Pulse pourrait constituer un premier investissement, mais il n’est pas clair à quelle vitesse ce modèle deviendra une pratique standard. Néanmoins, les problèmes d’ingénierie sous-jacents semblent mériter d’être abordés dès maintenant : concevoir des outils véritablement utiles, définir des limites de permissions raisonnables, assurer une exécution fiable, et être honnête quant à la manière dont ces outils sont utilisés en pratique.

Il ne suffira pas de simplement déployer un serveur MCP. Ce sont les serveurs qui méritent d’être développés ceux auxquels les utilisateurs continueront de revenir une fois la curiosité initiale passée.

Si vous en développez un vous-même, comment décidez-vous quels outils valent vraiment la peine d’être conservés ?

Lectures complémentaires

• MCP pour les agents IA : standardiser l’intégration des outils dans LangGraph — Cet article explique ce que MCP standardise réellement dans les systèmes d’IA agente, en comparant les intégrations d’outils ad hoc à celles basées sur MCP au sein d’un orchestrateur LangGraph.
• Leçons tirées de la livraison d’un SaaS Next.js et de la création d’un CLI de scaffolding — Il décrit les décisions fondamentales — choix du stack, authentification, multi-tenancy, facturation et gestion de l’état — ainsi que la création d’un CLI qui simplifie la configuration des projets Next.js.