# MCP para fabricantes: guía práctica

> Qué es el Model Context Protocol, qué debe exponer un servidor MCP de piezas, cómo OAuth protege el precio y el stock y qué asistentes pueden alcanzarlo.

**Language:** es  
**Published:** 2026-08-09  
**Category:** Technical · **Tags:** MCP, Model Context Protocol, OAuth, Streamable HTTP, parts data, AI agents  
**Canonical:** https://partsgraph.ai/es/blog/mcp-for-manufacturers

## En resumen

**¿Qué es MCP y qué debe exponer el servidor MCP de un fabricante?**

MCP (el Model Context Protocol) es un estándar abierto que permite a un asistente de IA llamar directamente a sus sistemas en lugar de deducir las respuestas a partir de sus páginas web. El servidor MCP de un fabricante es un endpoint HTTP alojado que expone un conjunto reducido de herramientas tipadas —búsqueda paramétrica, consulta de piezas, alternativas y equivalencias, documentos de conformidad, enlaces a CAD, y stock y precios protegidos con OAuth— que cualquier asistente compatible puede invocar para obtener una respuesta exacta y auditable. Con la especificación vigente 2026-07-28 es un servicio de petición/respuesta sin estado que funciona detrás de un balanceador de carga corriente. El protocolo es la parte fácil; lo difícil es tener detrás un único registro de producto canónico y verificado.

---

## ¿Qué es MCP, en términos sencillos?

El Model Context Protocol es una forma estándar de que un asistente de IA llame al sistema de otra empresa y reciba de vuelta una respuesta tipada y estructurada.

Anthropic lo liberó como código abierto el 25 de noviembre de 2024 y lo describió como "un nuevo estándar para conectar asistentes de IA a los sistemas donde residen los datos". El 9 de diciembre de 2025, Anthropic donó MCP a la Agentic AI Foundation, un fondo dirigido dentro de la Linux Foundation, cofundado con Block y OpenAI y respaldado a nivel platino por AWS, Bloomberg, Cloudflare, Google y Microsoft. Para entonces, MCP había superado los 97 millones de descargas mensuales de SDK y los 10.000 servidores publicados, con soporte de cliente de primer nivel en ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot y VS Code.

> **Figure.** Parsing forty pages versus one typed MCP tool call.

Para quien decide sin ser desarrollador, la distinción que importa es esta. Cuando un asistente lee su sitio web, está *interpretando un documento*: puede leer mal una tabla, pasar por alto una nota al pie o mezclar dos variantes. Cuando un asistente llama a su servidor MCP, está *consultando un sistema*: pide la pieza, recibe los campos y los comunica. El primer modo produce respuestas plausibles. El segundo produce respuestas correctas, siempre que los datos que hay detrás sean correctos, que es donde está la mayor parte del trabajo real.

## ¿Quién ha lanzado ya uno en este sector?

Esto ya no es especulativo, y los ejemplos son variados de un modo muy útil:

- **Microchip Technology** lanzó un servidor MCP público y gratuito el 6 de noviembre de 2025, que expone especificaciones de producto verificadas, fichas técnicas, inventario, precios y plazos de entrega sobre MCP Streamable HTTP, con respuestas codificadas en JSON dirigidas a copilotos, chatbots y agentes corporativos.
- **Siemens** opera un servidor público en `mcp.siemens.com` cuyos plugins documentados —activos, portal de desarrolladores, búsqueda y contenido web— están disponibles sin autenticación.
- **Zoovu** lanzó un servidor MCP el 11 de diciembre de 2025 que da a los agentes acceso gobernado a los datos de producto, posicionado en torno a la exactitud en las preguntas de compatibilidad y aplicación.
- **ECIA** lanzó el Inventory AI Agent Service de TrustedParts.com el 11 de junio de 2026, que pone el inventario autorizado de componentes electrónicos a disposición dentro de Microsoft Copilot, ChatGPT y Claude.
- **Shopify** expone un servidor Storefront MCP en las tiendas, en `https://{shop}.myshopify.com/api/mcp`, con herramientas como `search_catalog`, `lookup_catalog` y `get_product`, y sin autenticación requerida para el nivel de escaparate.

Merece la pena señalar dos patrones. Todos ellos se apoyan en un almacén de datos autorizado ya existente. Y todos ellos trazan una línea entre los datos públicos del catálogo y cualquier cosa comercialmente sensible.

## Herramientas o recursos: ¿qué debe usar un servidor de piezas?

La especificación es explícita sobre la diferencia, y equivocarse produce un servidor que los modelos utilizan mal.

**Las herramientas están controladas por el modelo.** La especificación afirma que las herramientas "están diseñadas para estar **controladas por el modelo**, lo que significa que el modelo de lenguaje puede descubrirlas e invocarlas automáticamente en función de su comprensión contextual y de las indicaciones del usuario". El descubrimiento es `tools/list`; la invocación es `tools/call`. Cada herramienta lleva un `inputSchema` (JSON Schema 2020-12 por defecto), un `outputSchema` opcional, y devuelve `structuredContent` conforme a ese esquema.

**Los recursos están dirigidos por la aplicación.** La especificación afirma que los recursos "están diseñados para estar **dirigidos por la aplicación**, y son las aplicaciones anfitrionas las que determinan cómo incorporar el contexto en función de sus necesidades": normalmente un selector, una lista o la inclusión automática por parte del anfitrión. Cada recurso se identifica mediante una URI, y las plantillas permiten URI parametrizadas.

Un catálogo es un espacio de consulta, no un conjunto fijo de documentos. Nadie quiere desplazarse por un selector de recursos con 40.000 piezas. Así que el grueso de un servidor de piezas deben ser herramientas, con dos matices: utilice bloques de contenido `resource_link` para apuntar a fichas técnicas y archivos CAD en lugar de incrustar cargas útiles grandes, y reserve los recursos propiamente dichos para un puñado de documentos estables, como un diccionario de clasificación o un registro de cambios.

Dos detalles de la especificación actual merecen atención. Las listas de herramientas **no deben** variar por conexión, pero **pueden** variar según la autorización presentada en la petición. Y los servidores **deberían** devolver las herramientas en un orden determinista, porque un orden estable permite a los clientes cachear la lista y mejora la tasa de aciertos de la caché de prompts.

## ¿Qué cambió en la especificación 2026-07-28?

Esta revisión reconfiguró el transporte, y cualquier diseño escrito sobre material de 2025 será incorrecto en aspectos muy concretos.

| Cambio | Antes | Desde 2026-07-28 |
| --- | --- | --- |
| Sesiones | Cabecera `Mcp-Session-Id`, asignada por el servidor | Eliminada; el estado se pasa como handles explícitos emitidos por el servidor en los argumentos de las herramientas |
| Handshake | `initialize` / `notifications/initialized` | Eliminado; la versión del protocolo y las capacidades del cliente viajan en `_meta` en cada petición |
| Descubrimiento de capacidades | Se conocía en la inicialización | Nuevo RPC `server/discover` que los servidores **deben** implementar |
| Peticiones iniciadas por el servidor | Enviadas por un stream SSE | Peticiones de varias idas y vueltas: el servidor devuelve `resultType: "input_required"` y el cliente reintenta con `inputResponses` |
| Enrutado | Las pasarelas analizaban el cuerpo JSON | Cabeceras `Mcp-Method` y `Mcp-Name` **obligatorias** en los POST |
| Caché | Solo notificaciones `listChanged` | `ttlMs` y `cacheScope` obligatorios en los resultados de listado y lectura |
| Reanudación del stream | Repetición mediante `Last-Event-ID` | Eliminada; un stream roto pierde la petición y el cliente la reemite |

La forma del transporte es ahora agradablemente aburrida. El servidor expone un único endpoint MCP que acepta POST, por ejemplo `https://example.com/mcp`. Cada petición JSON-RPC es su propio POST. Los clientes deben enviar una cabecera `Accept` que enumere tanto `application/json` como `text/event-stream`, además de una cabecera `MCP-Protocol-Version` que debe coincidir con el valor de `_meta` en el cuerpo; si no, el servidor debe rechazar la petición con un 400 y un error `HeaderMismatch`. Los servidores deben validar la cabecera `Origin` y responder 403 si está presente y no es válida.

La consecuencia práctica para los equipos de infraestructura: como no hay sesión a nivel de protocolo, su servidor MCP se despliega detrás de un balanceador de carga round-robin corriente, igual que cualquier otro servicio HTTP sin estado. Roots, Sampling y Logging quedan ahora obsoletos con una ventana mínima de doce meses, y el antiguo transporte HTTP+SSE queda formalmente obsoleto también.

## ¿Cómo se protegen el precio y el stock con OAuth?

La autorización es **opcional** en MCP, que es exactamente lo adecuado para un servidor de piezas: el catálogo público no debería necesitar ningún token, y solo las herramientas comercialmente sensibles deberían exigir credenciales.

Cuando sí la implemente, los requisitos son concretos. El servidor MCP actúa como servidor de recursos OAuth 2.1, siguiendo el borrador IETF de OAuth 2.1. **Debe** implementar Protected Resource Metadata (RFC 9728), y los clientes **deben** usar esos metadatos para descubrir el servidor de autorización. Los clientes **deben** implementar Resource Indicators (RFC 8707), enviando un parámetro `resource` que identifique la URI canónica de su servidor tanto en las peticiones de autorización como en las de token, y su servidor **debe** validar que los tokens se emitieron para él como audiencia prevista. Los servidores de autorización **deberían** devolver el parámetro `iss` conforme a la RFC 9207, y los clientes deben validarlo. El Dynamic Client Registration queda ahora obsoleto en favor de los Client ID Metadata Documents, aunque sigue disponible por compatibilidad con versiones anteriores.

El patrón que funciona para un distribuidor o un fabricante:

1. **Nivel no autenticado**: especificaciones, búsqueda paramétrica, alternativas, documentos de conformidad, enlaces a CAD y precios de tarifa allí donde los publique.
2. **Nivel autenticado**: precios de contrato, disponibilidad específica del cliente, creación de ofertas. Responda con un 403 y `error="insufficient_scope"`, indicando los scopes necesarios para que el cliente pueda escalar en una sola ida y vuelta en lugar de en varias.
3. **Nunca** ponga un identificador de cliente en un argumento de herramienta como único control de acceso. Un handle es un nombre, no una capacidad; valide la autorización en cada llamada.

## ¿Qué debe exponer un servidor MCP de piezas?

De seis a ocho herramientas es el orden de magnitud correcto. Por encima de eso, la selección por parte del modelo se degrada.

| Herramienta | Propósito | Autorización |
| --- | --- | --- |
| `search_parts` | Búsqueda paramétrica dentro de una clase, con restricciones tipadas y unidades | Pública |
| `get_part` | Registro canónico completo de una referencia, con procedencia y fecha de última verificación | Pública |
| `find_alternates` | Equivalentes funcionales, segundas fuentes y equivalencias con la competencia, con una base de equivalencia declarada | Pública |
| `get_compliance_documents` | RoHS, REACH, declaraciones de prestaciones, certificados, EPD: como registros con fecha de emisión, no solo enlaces | Pública |
| `get_cad_models` | Enlaces a recursos 2D, 3D y BIM por formato | Pública |
| `get_availability` | Stock en tiempo real por ubicación y plazo de entrega | Restringida |
| `get_price` | Precio de contrato del cliente por cantidad | Restringida |

Una definición de herramienta debería parecer poco llamativa, y esa es justamente la idea:

```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
  }
}
```

Fíjese en lo que hace la descripción: le dice al modelo qué devuelve la herramienta *y* cuándo debe recurrir a una distinta. Ese único hábito hace más por la calidad de las respuestas que cualquier cantidad de pulido de esquemas.

## Un ejemplo práctico

Un ingeniero de diseño de un fabricante por contrato en Texas está sustituyendo una pieza que llega a fin de vida en una placa que también se envía a un fabricante de cuadros eléctricos alemán. El asistente tiene conectado el servidor MCP del fabricante.

> **Ingeniero:** El MOSFET de canal N de 60 V de nuestra etapa reductora llega a fin de vida. Necesito un sustituto directo en el mismo encapsulado, con una R_DS(on) no peor de 12 milliohmios con 10 V de excitación de puerta, y necesito saber si está realmente disponible.

El asistente hace cuatro llamadas.

```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)" } ]
```

El asistente responde entonces: un candidato es un sustituto directo con mejor resistencia en conducción y mayor carga de puerta, que conviene comprobar frente al driver de puerta; el segundo encaja en la huella, pero no cumple el límite de R_DS(on); hay 14.200 unidades en stock en Texas y 3.800 en Baden-Wurtemberg a fecha de esta mañana, con un plazo de entrega de ocho semanas; se adjuntan las declaraciones RoHS y REACH con sus fechas de emisión.

Nada de esto es impresionante como ingeniería. Es impresionante como *actividad comercial*. Se tomaron tres decisiones de aprovisionamiento sin que ninguna persona abriera un navegador, y cada cifra es trazable hasta un registro con marca de tiempo.

## ¿Quién puede llegar realmente a su servidor hoy?

Sea sincero con su consejo de administración en este punto, porque la respuesta es más estrecha de lo que da a entender la mayor parte del material de los proveedores.

| Cliente | ¿Puede llegar a un servidor MCP propio? | Condiciones |
| --- | --- | --- |
| Claude | Sí | Conectores remotos personalizados en Free, Pro, Max, Team y Enterprise; los usuarios gratuitos están limitados a uno; el servidor debe ser accesible por internet público desde los rangos de IP de Anthropic |
| ChatGPT | En parte | Servidores MCP propios mediante el modo de desarrollador; los conectores con capacidad de escritura se limitan a Business, Enterprise y Edu, con Plus y Pro en solo lectura. Las apps en ChatGPT se construyen sobre MCP y pasan por una revisión de directorio |
| Gemini | Solo empresa | Servidores MCP propios registrados por un administrador como almacén de datos en Gemini Enterprise; solo transporte Streamable HTTP |
| Microsoft Copilot | Sí, en configuraciones empresariales | Conectores registrados por el administrador |
| Agentes de IDE y de CLI | Sí | El desarrollador configura el endpoint directamente: la vía de menor fricción para públicos de ingeniería |
| Los agentes propios de sus clientes | Sí | Los equipos de compras e ingeniería operan cada vez más agentes internos; en la práctica, este es el llamante que más rápido crece |

Así que MCP llega a los ingenieros que se configuran un asistente y a los compradores corporativos cuyo departamento de TI registra su servidor. Es una población pequeña para los estándares de la web y muy grande para los estándares de un pipeline comercial.

## ¿Cómo descubren los agentes su servidor?

No hay descubrimiento a nivel de DNS. Existen tres mecanismos:

1. **El registro oficial de MCP** en `registry.modelcontextprotocol.io`, el repositorio centralizado de metadatos de los servidores accesibles públicamente, respaldado por Anthropic, GitHub, Microsoft y PulseMCP. Es de código abierto, admite subregistros y sigue en preview antes de su disponibilidad general, así que cabe esperar cambios.
2. **Los directorios del lado del cliente**, como el directorio de conectores de Claude y el directorio de apps de ChatGPT, cada uno con su propio proceso de revisión.
3. **Su propia documentación.** Hoy es así como se produce la mayoría de las conexiones: una página para desarrolladores indica la URL del endpoint, la lista de herramientas y los scopes de autorización, y un cliente la pega en su cliente.

Publique su documento `.well-known/oauth-protected-resource` aunque la mayoría de las herramientas sean públicas, y versione la ruta del endpoint. Cambiará su superficie de herramientas, y le conviene que eso sea una migración deliberada y no una ruptura silenciosa.

## Una lista de comprobación para la implementación

1. **Resuelva a un único registro canónico por pieza**, con atributos tipados, unidades, procedencia y una marca de tiempo de última verificación. No empiece por el protocolo.
2. **Elija de seis a ocho herramientas** y escriba descripciones que digan cuándo *no* usar cada una.
3. **Declare esquemas de salida** y devuelva `structuredContent`. Incluya unidades y fechas de verificación en cada carga útil.
4. **Sirva un único endpoint POST** con las cabeceras `Mcp-Method` y `Mcp-Name` respetadas, con `Origin` validado y con `ttlMs` y `cacheScope` fijados en los resultados de listado.
5. **Separe las herramientas públicas de las restringidas**, implemente los metadatos de la RFC 9728, valide la audiencia del token conforme a la RFC 8707 y utilice desafíos de scope para escalar en una sola ida y vuelta.
6. **Devuelva un orden determinista de herramientas** y nombres de herramienta estables para que funcionen las cachés de los clientes.
7. **Registre cada llamada**: herramienta, argumentos, latencia y si la consulta se resolvió. Un servidor MCP sin analítica es un canal que no puede gestionar.
8. **Vigile la exactitud frente a la verdad de referencia**, de forma continua. Una herramienta que devuelve con aplomo un valor nominal obsoleto es peor que no tener herramienta.

Partsgraph lo ofrece como capa gestionada: resolvemos su catálogo existente en un único Parts Graph verificado, alojamos el endpoint MCP con OAuth en los niveles restringidos e informamos de qué agentes llamaron a qué y dónde se equivocaron las respuestas.

Si quiere saber en qué punto está antes de escribir una sola línea de código, pase su dominio por el grader gratuito en [/audit](/audit): comprueba a qué pueden llegar hoy las máquinas en su catálogo, y si un endpoint MCP tendría algo fiable que servir.

## Preguntas frecuentes

### ¿Necesitamos MCP si ya tenemos una API REST?

Su API REST es la base adecuada, pero un agente no puede utilizarla sin un trabajo de integración a medida por parte de quien opere ese agente. MCP estandariza tres cosas que una API REST deja abiertas: cómo descubre un cliente qué operaciones existen, cómo se tipan sus entradas y salidas para un modelo, y cómo se negocia la autorización. En la práctica, un servidor MCP de piezas es una proyección fina y deliberada de una API existente, con esquemas y descripciones escritos para un modelo y no para un desarrollador.

### ¿Los datos de piezas deben exponerse como herramientas o como recursos?

Sobre todo como herramientas. La especificación describe las herramientas como controladas por el modelo —el modelo las descubre e invoca a partir del contexto—, mientras que los recursos están dirigidos por la aplicación: los presenta la aplicación anfitriona para que un usuario los seleccione. Un catálogo es un espacio de consulta, no una lista fija de archivos, así que lo natural son herramientas que aceptan parámetros. Los recursos se justifican para un número reducido de documentos estables, y las herramientas pueden devolver enlaces a recursos para fichas técnicas y archivos CAD en lugar de incrustar megabytes.

### ¿La especificación 2026-07-28 rompe los servidores MCP existentes?

Cambia la forma del transporte de manera considerable. Desaparecen las sesiones a nivel de protocolo y la cabecera Mcp-Session-Id, desaparece el handshake de initialize, desaparece el stream GET independiente y desaparece la reanudación de SSE mediante Last-Event-ID. Los servidores deben implementar server/discover y exigir las cabeceras Mcp-Method y Mcp-Name en los POST. Los clientes que soportan ambas etapas detectan cuál habla un servidor intentando primero una petición moderna e inspeccionando el cuerpo del error antes de recurrir al modo anterior.

### ¿Cómo evitamos que un agente vea los precios de otro cliente?

Utilice la capa de autorización, no la ocultación. El servidor MCP actúa como servidor de recursos OAuth 2.1, debe implementar Protected Resource Metadata (RFC 9728) y debe validar que los tokens de acceso se emitieron específicamente para él como audiencia prevista, conforme a la RFC 8707. Y algo fundamental: la especificación permite que el conjunto visible de herramientas y recursos varíe según la autorización presentada en la petición, de modo que a un llamante no autenticado se le pueden mostrar únicamente las herramientas del catálogo público.

### ¿Cómo encuentra un agente nuestro servidor MCP, para empezar?

No existe ningún mecanismo de descubrimiento a nivel de DNS, y fingir lo contrario es el error más habitual en lo que se escribe sobre MCP. El descubrimiento se produce a través del registro oficial de MCP en registry.modelcontextprotocol.io, respaldado por Anthropic, GitHub, Microsoft y PulseMCP y todavía en preview antes de su disponibilidad general; a través de directorios del lado del cliente, como el directorio de conectores de Claude y el directorio de aplicaciones de ChatGPT; y, lo más frecuente hoy, porque usted publicó la URL en su documentación para desarrolladores y un cliente la pegó en el suyo.

### ¿Cuál es el mayor error de diseño en un primer servidor MCP de piezas?

Exponer demasiadas herramientas con descripciones vagas. Un modelo elige las herramientas por su nombre, su descripción y sus esquemas, así que veinte endpoints de búsqueda solapados producen peor comportamiento que seis bien nombrados. Devuelva contenido estructurado conforme a un esquema de salida declarado, mantenga nombres de herramienta deterministas y estables, e incluya unidades, tolerancias y una marca de tiempo de última verificación en la carga útil para que la respuesta pueda auditarse más adelante.

### ¿Ayuda un servidor MCP a la visibilidad en IA en la web abierta?

No directamente. Los rastreadores de búsqueda y recuperación no llaman a servidores MCP: descargan HTML. MCP llega a los usuarios que han conectado su servidor, lo que hoy significa ingenieros que configuran un conector y compradores corporativos cuyo administrador lo registra. Es un canal de profundidad, no de alcance, y funciona mejor junto a páginas de producto estructuradas y renderizadas en el servidor.

## Fuentes

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
- Français: https://partsgraph.ai/fr/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/es/audit