MCP pour les fabricants : le guide pratique

Qu'est-ce que MCP, en termes simples ?

Le Model Context Protocol est une manière normalisée, pour un assistant IA, d'appeler le système d'un tiers et d'en recevoir une réponse typée et structurée.

Anthropic l'a publié en open source le 25 novembre 2024, en le décrivant comme « une nouvelle norme pour connecter les assistants IA aux systèmes où résident les données ». Le 9 décembre 2025, Anthropic a fait don de MCP à l'Agentic AI Foundation, un fonds dédié placé sous l'égide de la Linux Foundation, cofondé avec Block et OpenAI et soutenu au niveau platine par AWS, Bloomberg, Cloudflare, Google et Microsoft. À cette date, MCP dépassait 97 millions de téléchargements mensuels de SDK et plus de 10 000 serveurs publiés, avec une prise en charge native côté client dans ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot et VS Code.

Pour un décideur non technique, la distinction qui compte est la suivante. Lorsqu'un assistant lit votre site web, il interprète un document : il peut mal lire un tableau, passer à côté d'une note de bas de page ou confondre deux variantes. Lorsqu'un assistant appelle votre serveur MCP, il interroge un système : il demande la référence, reçoit les champs et les restitue. Le premier mode produit des réponses plausibles. Le second produit des réponses justes — à condition que les données sous-jacentes le soient, et c'est là que se concentre l'essentiel du travail réel.

Qui en a déjà mis un en production dans le secteur ?

Le sujet n'a plus rien de spéculatif, et les exemples sont utilement variés :

• Microchip Technology a lancé un serveur MCP public et gratuit le 6 novembre 2025, exposant des spécifications produit vérifiées, des fiches techniques, les stocks, les prix et les délais d'approvisionnement via le transport MCP Streamable HTTP, avec des réponses encodées en JSON destinées aux copilotes, aux chatbots et aux agents d'entreprise.
• Siemens exploite un serveur public à l'adresse mcp.siemens.com, dont les plugins documentés — ressources, portail développeur, recherche et contenu web — sont accessibles sans authentification.
• Zoovu a lancé un serveur MCP le 11 décembre 2025, donnant aux agents un accès encadré aux données produit, avec un positionnement axé sur l'exactitude des réponses de compatibilité et d'application.
• ECIA a lancé le service Inventory AI Agent de TrustedParts.com le 11 juin 2026, rendant les stocks de composants électroniques issus de la distribution agréée accessibles au sein de Microsoft Copilot, de ChatGPT et de Claude.
• Shopify expose un serveur MCP Storefront sur les boutiques à l'adresse https://{shop}.myshopify.com/api/mcp, avec des outils tels que search_catalog, lookup_catalog et get_product, sans authentification requise pour le niveau storefront.

Deux constantes méritent d'être relevées. Chacun de ces serveurs repose sur un référentiel de données faisant déjà autorité. Et chacun trace une frontière nette entre les données catalogue publiques et tout ce qui relève du commercialement sensible.

Outils ou ressources — que doit utiliser un serveur de pièces ?

La spécification est explicite sur cette différence, et s'y tromper produit un serveur que les modèles exploitent mal.

Les outils sont pilotés par le modèle. La spécification indique que les outils « sont conçus pour être pilotés par le modèle, ce qui signifie que le modèle de langage peut les découvrir et les invoquer automatiquement en fonction de sa compréhension du contexte et des requêtes de l'utilisateur ». La découverte passe par tools/list, l'invocation par tools/call. Chaque outil porte un inputSchema (JSON Schema 2020-12 par défaut), un outputSchema facultatif, et renvoie un structuredContent conforme à ce schéma.

Les ressources sont pilotées par l'application. La spécification indique que les ressources « sont conçues pour être pilotées par l'application, l'application hôte déterminant comment intégrer le contexte selon ses besoins » — en pratique un sélecteur, une liste, ou une inclusion automatique par l'hôte. Chaque ressource est identifiée par une URI, et les gabarits permettent des URI paramétrées.

Un catalogue est un espace de requêtes, pas un ensemble figé de documents. Personne n'a envie de faire défiler un sélecteur de ressources contenant 40 000 références. L'essentiel d'un serveur de pièces doit donc reposer sur des outils, avec deux nuances : utilisez des blocs de contenu resource_link pour pointer vers les fiches techniques et les fichiers CAO plutôt que d'incorporer des charges utiles volumineuses, et réservez les véritables ressources à une poignée de documents stables, tels qu'un dictionnaire de classification ou un journal des modifications.

Deux détails de la spécification actuelle méritent l'attention. Les listes d'outils ne doivent pas varier d'une connexion à l'autre, mais peuvent varier selon l'autorisation présentée avec la requête. Et les serveurs devraient renvoyer les outils dans un ordre déterministe, car un ordre stable permet aux clients de mettre la liste en cache et améliore le taux de succès du cache de prompt.

Qu'est-ce qui a changé dans la spécification 2026-07-28 ?

Cette révision a remodelé le transport, et toute conception fondée sur la documentation de 2025 se révélera fausse sur des points précis.

La forme du transport est désormais d'une banalité réjouissante. Le serveur expose un unique point d'entrée MCP acceptant les POST — par exemple https://example.com/mcp. Chaque requête JSON-RPC constitue son propre POST. Les clients doivent envoyer un en-tête Accept mentionnant à la fois application/json et text/event-stream, ainsi qu'un en-tête MCP-Protocol-Version qui doit correspondre à la valeur présente dans le _meta du corps, faute de quoi le serveur doit rejeter la requête avec un 400 et une erreur HeaderMismatch. Les serveurs doivent valider l'en-tête Origin et répondre 403 s'il est présent et invalide.

La conséquence pratique pour les équipes d'infrastructure : puisqu'il n'existe plus de session au niveau du protocole, votre serveur MCP se déploie derrière un simple répartiteur de charge en round-robin, comme n'importe quel autre service HTTP sans état. Roots, Sampling et Logging sont désormais dépréciés, avec une fenêtre minimale de douze mois, et l'ancien transport HTTP+SSE est lui aussi formellement déprécié.

Comment protéger les prix et les stocks avec OAuth ?

L'autorisation est facultative dans MCP, ce qui convient parfaitement à un serveur de pièces : le catalogue public ne devrait exiger aucun jeton, et seuls les outils commercialement sensibles devraient déclencher une demande d'authentification.

Lorsque vous la mettez en œuvre, les exigences sont précises. Le serveur MCP agit comme un serveur de ressources OAuth 2.1, conformément au projet IETF OAuth 2.1. Il doit implémenter les Protected Resource Metadata (RFC 9728), et les clients doivent s'appuyer sur ces métadonnées pour découvrir le serveur d'autorisation. Les clients doivent implémenter les Resource Indicators (RFC 8707), en transmettant un paramètre resource qui identifie l'URI canonique de votre serveur, aussi bien dans les requêtes d'autorisation que dans les requêtes de jeton, et votre serveur doit vérifier que les jetons ont bien été émis à son intention. Les serveurs d'autorisation devraient renvoyer le paramètre iss conformément à la RFC 9207, et les clients doivent le valider. L'enregistrement dynamique des clients est désormais déprécié au profit des Client ID Metadata Documents, même s'il reste disponible pour des raisons de rétrocompatibilité.

Le schéma qui fonctionne pour un distributeur ou un fabricant :

1. 01Niveau non authentifié — spécifications, recherche paramétrique, équivalences, documents de conformité, liens CAO, et prix catalogue lorsque vous les publiez.
2. 02Niveau authentifié — prix contractuels, disponibilité propre au client, création de devis. Répondez par un 403 et error="insufficient_scope", en nommant les scopes nécessaires pour que le client puisse élever ses droits en un seul aller-retour plutôt qu'en plusieurs.
3. 03Ne placez jamais un identifiant client dans un argument d'outil comme unique contrôle d'accès. Un handle est un nom, pas une capacité ; validez l'autorisation à chaque appel.

Que doit exposer un serveur MCP de pièces ?

Six à huit outils : c'est le bon ordre de grandeur. Au-delà, la sélection par le modèle se dégrade.

Une définition d'outil doit paraître banale, et c'est précisément l'objectif :

{
  "name": "search_parts",
  "title": "Parametric part search",
  "description": "Search the catalog by product class and typed parameter constraints. Returns matching parts with their key parametrics, units and last-verified date. Use get_part for the full record.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "product_class": { "type": "string", "description": "ETIM class code or class name" },
      "constraints": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "parameter": { "type": "string" },
            "operator": { "type": "string", "enum": ["eq", "gte", "lte", "between", "in"] },
            "value": {},
            "unit": { "type": "string" }
          },
          "required": ["parameter", "operator", "value"]
        }
      },
      "limit": { "type": "integer", "default": 20 }
    },
    "required": ["product_class"],
    "additionalProperties": false
  }
}

Notez ce que fait la description : elle indique au modèle ce que l'outil renvoie et à quel moment recourir à un autre outil. Cette seule habitude fait davantage pour la qualité des réponses que tous les raffinements de schéma.

Un exemple concret

Un ingénieur de conception, chez un sous-traitant électronique au Texas, remplace un composant en fin de vie sur une carte qui est également livrée à un fabricant d'armoires électriques allemand. L'assistant dispose d'une connexion au serveur MCP du fabricant.

Ingénieur : Le MOSFET canal N 60 V de notre étage abaisseur passe en fin de vie. Il me faut un remplaçant direct dans le même boîtier, avec un R_DS(on) ne dépassant pas 12 milliohms sous une commande de grille de 10 V, et je dois savoir s'il est réellement disponible.

L'assistant effectue quatre appels.

→ tools/call  get_part
   { "part_number": "XYZ-60N12-D2PAK" }
← structuredContent
   { "package": "D2PAK", "vds_v": 60, "rds_on_mohm": 11.5,
     "vgs_meas_v": 10, "lifecycle": "EOL", "last_verified": "2026-08-04" }

→ tools/call  find_alternates
   { "part_number": "XYZ-60N12-D2PAK", "basis": "form_fit_function" }
← structuredContent
   [ { "part_number": "XYZ-60N10-D2PAK", "equivalence": "drop-in",
       "rds_on_mohm": 9.8, "differences": ["lower R_DS(on)", "higher Qg"] },
     { "part_number": "XYZ-60N14-D2PAK", "equivalence": "footprint",
       "rds_on_mohm": 13.5, "differences": ["exceeds R_DS(on) limit"] } ]

→ tools/call  get_availability
   { "part_numbers": ["XYZ-60N10-D2PAK"] }
← 403 Forbidden
   WWW-Authenticate: Bearer error="insufficient_scope",
     scope="stock:read", resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

   [client performs step-up authorisation, then retries]

← structuredContent
   { "part_number": "XYZ-60N10-D2PAK",
     "stock": [ { "location": "US-TX", "qty": 14200 },
                { "location": "DE-BW", "qty": 3800 } ],
     "lead_time_weeks": 8, "as_of": "2026-08-09T06:12:00Z" }

→ tools/call  get_compliance_documents
   { "part_number": "XYZ-60N10-D2PAK", "types": ["rohs", "reach"] }
← content: [ { "type": "resource_link", "uri": "https://…/rohs-2026-03.pdf",
               "name": "RoHS declaration (issued 2026-03-11)" } ]

L'assistant répond alors : le premier candidat est un remplaçant direct, avec une résistance à l'état passant plus faible et une charge de grille plus élevée, à vérifier avec le driver de grille ; le second respecte l'empreinte mais dépasse la limite de R_DS(on) ; le stock s'établit à 14 200 unités au Texas et 3 800 en Bade-Wurtemberg ce matin, pour un délai de huit semaines ; les déclarations RoHS et REACH sont jointes, avec leurs dates d'émission.

Rien de tout cela n'est impressionnant sur le plan technique. C'est impressionnant sur le plan commercial. Trois décisions d'approvisionnement ont été prises sans qu'aucun humain n'ouvre un navigateur, et chaque chiffre est traçable jusqu'à un enregistrement horodaté.

Qui peut réellement atteindre votre serveur aujourd'hui ?

Soyez honnête sur ce point avec votre comité de direction, car la réponse est plus étroite que ne le laisse entendre la plupart de la documentation éditeur.

MCP touche donc les ingénieurs qui configurent eux-mêmes leur assistant et les acheteurs grands comptes dont la DSI enregistre votre serveur. C'est une population réduite à l'échelle du web, et très importante à l'échelle d'un pipeline commercial.

Comment les agents découvrent-ils votre serveur ?

Il n'existe aucune découverte au niveau DNS. Trois mécanismes existent :

1. 01Le registre MCP officiel, à l'adresse registry.modelcontextprotocol.io, référentiel centralisé de métadonnées pour les serveurs accessibles publiquement, soutenu par Anthropic, GitHub, Microsoft et PulseMCP. Il est open source, prend en charge les sous-registres et reste en préversion avant sa disponibilité générale — attendez-vous donc à des évolutions.
2. 02Les annuaires côté client, comme l'annuaire des connecteurs de Claude et l'annuaire d'apps de ChatGPT, chacun avec son propre processus de validation.
3. 03Votre propre documentation. C'est ainsi que se nouent aujourd'hui la plupart des connexions : une page développeur indique l'URL du point d'entrée, la liste des outils et les scopes d'autorisation, et un client la colle dans son assistant.

Publiez votre document .well-known/oauth-protected-resource même si la plupart de vos outils sont publics, et versionnez le chemin du point d'entrée. Vous ferez évoluer votre surface d'outils, et mieux vaut que ce soit une migration délibérée plutôt qu'une rupture silencieuse.

Une check-list de mise en œuvre

1. 01Consolidez une fiche canonique unique par référence, avec attributs typés, unités, provenance et horodatage de dernière vérification. Ne commencez pas par le protocole.
2. 02Retenez six à huit outils et rédigez des descriptions qui précisent quand ne pas utiliser chacun d'eux.
3. 03Déclarez des schémas de sortie et renvoyez du structuredContent. Incluez les unités et les dates de vérification dans chaque charge utile.
4. 04Exposez un point d'entrée POST unique, en respectant les en-têtes Mcp-Method et Mcp-Name, en validant Origin, et en renseignant ttlMs et cacheScope sur les résultats de listage.
5. 05Séparez les outils publics des outils restreints, implémentez les métadonnées de la RFC 9728, validez l'audience des jetons conformément à la RFC 8707, et utilisez les demandes de scope pour élever les droits en un seul aller-retour.
6. 06Renvoyez les outils dans un ordre déterministe et gardez des noms d'outils stables, pour que les caches clients fonctionnent.
7. 07Journalisez chaque appel — outil, arguments, latence, et succès ou non de la recherche. Un serveur MCP sans analytique est un canal que vous ne pouvez pas piloter.
8. 08Contrôlez l'exactitude par rapport à une vérité terrain, en continu. Un outil qui renvoie avec aplomb une valeur nominale périmée est pire que pas d'outil du tout.

Partsgraph fournit cette couche en mode managé : nous consolidons votre catalogue existant en un Parts Graph vérifié, hébergeons le point d'entrée MCP avec OAuth sur les niveaux restreints, et vous indiquons quels agents ont appelé quoi, et où les réponses étaient fausses.

Si vous voulez savoir où vous en êtes avant d'écrire la moindre ligne de code, passez votre domaine dans l'outil d'évaluation gratuit sur /audit — il vérifie ce que les machines peuvent atteindre aujourd'hui dans votre catalogue, et si un point d'entrée MCP aurait quoi que ce soit de fiable à servir.