MCP para fabricantes: guía práctica

¿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.

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.

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. 01Nivel no autenticado: especificaciones, búsqueda paramétrica, alternativas, documentos de conformidad, enlaces a CAD y precios de tarifa allí donde los publique.
2. 02Nivel 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. 03Nunca 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.

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

{
  "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.

→ 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.

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. 01El 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. 02Los 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. 03Su 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. 01Resuelva 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. 02Elija de seis a ocho herramientas y escriba descripciones que digan cuándo no usar cada una.
3. 03Declare esquemas de salida y devuelva structuredContent. Incluya unidades y fechas de verificación en cada carga útil.
4. 04Sirva 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. 05Separe 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. 06Devuelva un orden determinista de herramientas y nombres de herramienta estables para que funcionen las cachés de los clientes.
7. 07Registre 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. 08Vigile 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: comprueba a qué pueden llegar hoy las máquinas en su catálogo, y si un endpoint MCP tendría algo fiable que servir.