# MCP pour les fabricants : le guide pratique > Ce qu'est le Model Context Protocol, ce qu'un serveur MCP de pièces doit exposer, comment OAuth protège prix et stocks, et quels assistants y accèdent. **Language:** fr **Published:** 2026-08-09 **Category:** Technical · **Tags:** MCP, Model Context Protocol, OAuth, Streamable HTTP, parts data, AI agents **Canonical:** https://partsgraph.ai/fr/blog/mcp-for-manufacturers ## En bref **Qu'est-ce que MCP, et que doit exposer le serveur MCP d'un fabricant ?** MCP (le Model Context Protocol) est un standard ouvert qui permet à un assistant IA d'appeler directement vos systèmes, au lieu de déduire ses réponses de vos pages web. Le serveur MCP d'un fabricant est un point d'entrée HTTP hébergé, qui expose un petit ensemble d'outils typés — recherche paramétrique, consultation de référence, équivalences et correspondances, documents de conformité, liens CAO, ainsi que stocks et prix protégés par OAuth — que tout assistant compatible peut invoquer pour obtenir une réponse exacte et auditable. Sous la spécification actuelle 2026-07-28, il s'agit d'un service requête/réponse sans état, qui fonctionne derrière un répartiteur de charge ordinaire. Le protocole est la partie facile ; la difficulté consiste à disposer, derrière lui, d'une fiche produit unique, canonique et vérifiée. --- ## 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. > **Figure.** Parsing forty pages versus one typed MCP tool call. 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. | Évolution | Avant | À partir du 2026-07-28 | | --- | --- | --- | | Sessions | En-tête `Mcp-Session-Id`, attribué par le serveur | Supprimées ; l'état transite par des handles explicites émis par le serveur, dans les arguments des outils | | Poignée de main | `initialize` / `notifications/initialized` | Supprimée ; la version du protocole et les capacités du client voyagent dans `_meta` à chaque requête | | Découverte des capacités | Connue à l'initialisation | Nouveau RPC `server/discover` que les serveurs **doivent** implémenter | | Requêtes initiées par le serveur | Émises sur un flux SSE | Multi Round-Trip Requests : le serveur renvoie `resultType: "input_required"`, le client réessaie avec `inputResponses` | | Routage | Les passerelles analysaient le corps JSON | En-têtes `Mcp-Method` et `Mcp-Name` **obligatoires** sur les POST | | Mise en cache | Uniquement les notifications `listChanged` | `ttlMs` et `cacheScope` obligatoires sur les résultats de listage et de lecture | | Reprise de flux | Rejeu via `Last-Event-ID` | Supprimée ; un flux interrompu perd la requête, et le client la réémet | 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. **Niveau non authentifié** — spécifications, recherche paramétrique, équivalences, documents de conformité, liens CAO, et prix catalogue lorsque vous les publiez. 2. **Niveau 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. **Ne 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. | Outil | Objet | Authentification | | --- | --- | --- | | `search_parts` | Recherche paramétrique dans une classe de produits, avec contraintes typées et unités | Public | | `get_part` | Fiche canonique complète d'une référence, provenance et date de dernière vérification incluses | Public | | `find_alternates` | Équivalents fonctionnels, secondes sources et correspondances concurrentes, avec une base d'équivalence explicite | Public | | `get_compliance_documents` | RoHS, REACH, déclarations des performances, certificats, déclarations environnementales produit — sous forme d'enregistrements datés, et non de simples liens | Public | | `get_cad_models` | Liens de ressources vers les fichiers 2D, 3D et BIM, par format | Public | | `get_availability` | Stock en temps réel par site et délai d'approvisionnement | Restreint | | `get_price` | Prix contractuel client selon la quantité | Restreint | Une définition d'outil doit paraître banale, et c'est précisément l'objectif : ```json { "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. ```text → 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. | Client | Peut-il atteindre un serveur MCP personnalisé ? | Conditions | | --- | --- | --- | | Claude | Oui | Connecteurs distants personnalisés sur Free, Pro, Max, Team et Enterprise ; les utilisateurs gratuits sont limités à un seul ; le serveur doit être joignable depuis l'internet public, à partir des plages d'adresses IP d'Anthropic | | ChatGPT | Partiellement | Serveurs MCP personnalisés via le mode développeur ; les connecteurs autorisant l'écriture sont réservés aux offres Business, Enterprise et Edu, Plus et Pro restant en lecture seule. Les apps dans ChatGPT reposent sur MCP et passent par la revue de l'annuaire | | Gemini | Entreprise uniquement | Serveurs MCP personnalisés enregistrés par un administrateur comme source de données dans Gemini Enterprise ; transport Streamable HTTP exclusivement | | Microsoft Copilot | Oui, dans les configurations entreprise | Connecteurs enregistrés par un administrateur | | Agents IDE et CLI | Oui | Le développeur configure directement le point d'entrée — la voie la moins contraignante pour un public d'ingénieurs | | Les agents de vos propres clients | Oui | Les services achats et les bureaux d'études déploient de plus en plus d'agents internes ; c'est en pratique la catégorie d'appelants qui croît le plus vite | 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. **Le 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. **Les 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. **Votre 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. **Consolidez 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. **Retenez six à huit outils** et rédigez des descriptions qui précisent quand *ne pas* utiliser chacun d'eux. 3. **Dé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. **Exposez 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. **Sé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. **Renvoyez les outils dans un ordre déterministe** et gardez des noms d'outils stables, pour que les caches clients fonctionnent. 7. **Journalisez 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. **Contrô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](/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. ## Questions fréquentes ### Avons-nous besoin de MCP si nous disposons déjà d'une API REST ? Votre API REST constitue la bonne fondation, mais un agent ne peut pas l'utiliser sans un travail d'intégration sur mesure réalisé par celui qui exploite l'agent. MCP normalise trois choses qu'une API REST laisse ouvertes : la façon dont un client découvre les opérations disponibles, la façon dont leurs entrées et leurs sorties sont typées à destination d'un modèle, et la façon dont l'autorisation est négociée. En pratique, un serveur MCP de pièces est une projection fine et assumée d'une API existante, dont les schémas et les descriptions sont rédigés pour un modèle plutôt que pour un développeur. ### Faut-il exposer les données pièces sous forme d'outils ou de ressources ? Principalement sous forme d'outils. La spécification décrit les outils comme pilotés par le modèle — le modèle les découvre et les invoque à partir du contexte — tandis que les ressources sont pilotées par l'application, présentées par l'application hôte pour qu'un utilisateur les sélectionne. Un catalogue est un espace de requêtes, et non une liste figée de fichiers : les outils paramétrés sont donc le choix naturel. Les ressources gardent leur utilité pour un petit nombre de documents stables, et les outils peuvent renvoyer des liens de ressources vers les fiches techniques et les fichiers CAO plutôt que d'y incorporer plusieurs mégaoctets. ### La spécification 2026-07-28 casse-t-elle les serveurs MCP existants ? Elle modifie sensiblement la forme du transport. Les sessions au niveau du protocole et l'en-tête Mcp-Session-Id disparaissent, la poignée de main initialize disparaît, le flux GET autonome disparaît, tout comme la reprise SSE via Last-Event-ID. Les serveurs doivent implémenter server/discover et exiger les en-têtes Mcp-Method et Mcp-Name sur les POST. Les clients compatibles avec les deux générations déterminent laquelle un serveur parle en tentant d'abord une requête moderne et en examinant le corps de l'erreur avant de se replier sur l'ancienne. ### Comment empêcher un agent de voir les prix d'un autre client ? Utilisez la couche d'autorisation plutôt que l'obscurité. Le serveur MCP agit comme un serveur de ressources OAuth 2.1, doit implémenter les Protected Resource Metadata (RFC 9728) et doit vérifier que les jetons d'accès ont bien été émis à son intention, en tant qu'audience visée, conformément à la RFC 8707. Point essentiel : la spécification autorise les ensembles d'outils et de ressources visibles à varier selon l'autorisation présentée avec la requête, si bien qu'un appelant non authentifié peut ne se voir présenter que les outils du catalogue public. ### Comment un agent trouve-t-il notre serveur MCP au départ ? Il n'existe aucun mécanisme de découverte au niveau DNS, et prétendre le contraire est l'erreur la plus répandue dans la littérature consacrée à MCP. La découverte passe par le registre MCP officiel, à l'adresse registry.modelcontextprotocol.io, soutenu par Anthropic, GitHub, Microsoft et PulseMCP et encore en préversion avant sa disponibilité générale ; par les annuaires côté client, tels que l'annuaire des connecteurs de Claude et l'annuaire d'apps de ChatGPT ; et, le plus souvent aujourd'hui, parce que vous avez publié l'URL dans votre documentation développeur et qu'un client l'y a copiée. ### Quelle est la principale erreur de conception d'un premier serveur MCP de pièces ? Exposer trop d'outils avec des descriptions vagues. Un modèle choisit ses outils d'après leurs noms, leurs descriptions et leurs schémas : vingt points d'entrée de recherche qui se recouvrent produisent donc un comportement pire que six outils bien nommés. Renvoyez du contenu structuré conforme à un schéma de sortie déclaré, gardez des noms d'outils déterministes et stables, et faites figurer dans la charge utile les unités, les tolérances et un horodatage de dernière vérification, afin que la réponse puisse être auditée par la suite. ### Un serveur MCP améliore-t-il la visibilité IA sur le web ouvert ? Pas directement. Les crawlers de recherche et de récupération n'appellent pas les serveurs MCP : ils récupèrent du HTML. MCP touche les utilisateurs qui ont connecté votre serveur, c'est-à-dire aujourd'hui les ingénieurs qui configurent un connecteur et les acheteurs grands comptes dont l'administrateur l'enregistre. C'est un canal de profondeur, pas un canal de portée, et il donne le meilleur de lui-même en complément de pages produit structurées et rendues côté serveur. ## Sources 1. [Anthropic, Introducing the Model Context Protocol (25 November 2024)](https://www.anthropic.com/news/model-context-protocol) 2. [Model Context Protocol, MCP joins the Agentic AI Foundation (9 December 2025)](https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/) 3. [Linux Foundation, Formation of the Agentic AI Foundation (9 December 2025)](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation) 4. [Model Context Protocol, 2026-07-28 specification changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog) 5. [Model Context Protocol, Streamable HTTP transport (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http) 6. [Model Context Protocol, Authorization (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) 7. [Model Context Protocol, Tools (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) 8. [Model Context Protocol, Resources (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/server/resources) 9. [Model Context Protocol, The MCP Registry](https://modelcontextprotocol.io/registry/about) 10. [Microchip Technology, Microchip unveils Model Context Protocol (MCP) Server (6 November 2025)](https://ir.microchip.com/news-events/press-releases/detail/1344/microchip-technology-unveils-model-context-protocol-mcp-server-to-power-ai-driven-product-data-access) 11. [Siemens MCP Server documentation](https://mcp.siemens.com/docs) 12. [Zoovu, Zoovu launches MCP Server (11 December 2025)](https://zoovu.com/news/zoovu-launches-mcp-server) 13. [ECIA, TrustedParts.com launches Inventory AI Agent Service (11 June 2026)](https://www.ecianow.org/2026/06/11/trustedparts-com-launches-inventory-ai-agent-service/) 14. [Shopify, Storefront MCP server documentation](https://shopify.dev/docs/apps/build/storefront-mcp/servers/storefront) 15. [Anthropic, Get started with custom connectors using remote MCP](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp) 16. [OpenAI Help Center, Developer mode and MCP apps in ChatGPT](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt) 17. [Google Cloud, Set up your custom MCP server data store (Gemini Enterprise)](https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/set-up-custom-mcp-server) ## Other languages - English: https://partsgraph.ai/blog/mcp-for-manufacturers/md - Deutsch: https://partsgraph.ai/de/blog/mcp-for-manufacturers/md - Español: https://partsgraph.ai/es/blog/mcp-for-manufacturers/md - Italiano: https://partsgraph.ai/it/blog/mcp-for-manufacturers/md - Nederlands: https://partsgraph.ai/nl/blog/mcp-for-manufacturers/md - Polski: https://partsgraph.ai/pl/blog/mcp-for-manufacturers/md - Português: https://partsgraph.ai/pt/blog/mcp-for-manufacturers/md - Svenska: https://partsgraph.ai/sv/blog/mcp-for-manufacturers/md - Türkçe: https://partsgraph.ai/tr/blog/mcp-for-manufacturers/md - 日本語: https://partsgraph.ai/ja/blog/mcp-for-manufacturers/md - 한국어: https://partsgraph.ai/ko/blog/mcp-for-manufacturers/md - 简体中文: https://partsgraph.ai/zh/blog/mcp-for-manufacturers/md --- Partsgraph — the agent-ready parts data layer. Free AI-visibility grader: https://partsgraph.ai/fr/audit