Servidor MCP para datos de producto: tu catálogo, abierto a los agentes de IA

TL;DR

• Un servidor MCP para datos de producto permite que los agentes de IA consulten directamente el catálogo de una marca a través del Model Context Protocol, una especificación abierta que Anthropic lanzó en noviembre de 2024 y que desde diciembre de 2025 se gobierna dentro de la Agentic AI Foundation de la Linux Foundation.
• MCP da a un servidor tres piezas básicas: herramientas que el modelo puede invocar, recursos que la aplicación puede leer y prompts que el usuario puede elegir. El control de acceso usa OAuth 2.1, y un servidor puede mostrar a cada llamante solo lo que su token permite.
• Un servidor MCP no sustituye a tu resolver GS1 Digital Link, a tu Pasaporte Digital de Producto ni a tu marcado schema.org. Funciona mejor como una puerta más hacia la misma fuente de verdad, identificada por el mismo GTIN.

Un servidor MCP para datos de producto es un servicio que responde a las preguntas de los agentes de IA sobre tus productos en una forma pensada para que la usen: las especificaciones de este GTIN, si esta variante sigue vigente, dónde está la declaración de conformidad. El Model Context Protocol (MCP) es el protocolo abierto que define cómo se conecta una aplicación de IA a un servidor así. Estuvo en el programa del taller W3C/GS1 sobre comercio electrónico para personas y agentes de IA en Zúrich, y es el protocolo de agentes con el que la mayoría de los desarrolladores se encuentra primero, porque no es específico del comercio.

Esta guía explica qué es MCP y quién lo gestiona, sus piezas básicas en lenguaje sencillo y cómo una marca o un fabricante podría usar un servidor MCP para exponer identificadores, especificaciones, datos de cumplimiento y de pasaporte y disponibilidad, manteniendo restringidos los datos restringidos. Todo lo que sigue se expone según la situación a octubre de 2026.

¿Qué es el Model Context Protocol?

MCP es una especificación abierta publicada. Su revisión actual lo describe como un protocolo abierto para conectar aplicaciones basadas en grandes modelos de lenguaje con fuentes de datos y herramientas externas. Los mensajes se intercambian en JSON-RPC 2.0, y la especificación se publica bajo la Apache License 2.0.

Anthropic presentó MCP el 25 de noviembre de 2024 y publicó la especificación y los kits de desarrollo de software en GitHub. El 9 de diciembre de 2025 Anthropic donó MCP a la Agentic AI Foundation, un fondo dirigido dentro de la Linux Foundation cofundado por Anthropic, Block y OpenAI. El modelo de gobernanza no cambió: los mantenedores toman las decisiones técnicas, y los cambios en la especificación pasan por Specification Enhancement Proposals (SEP). Los puestos de mantenedor pertenecen a personas, no a empresas.

Las versiones de MCP llevan el nombre de la fecha de su último cambio incompatible con versiones anteriores. La revisión 2026-07-28 hizo el protocolo sin estado: no hay sesión ni saludo inicial, y cada petición lleva su propia versión del protocolo y las capacidades del cliente, de modo que cualquier instancia del servidor puede responderla. Para un servicio de datos de producto detrás de un balanceador de carga, eso es una simplificación real. La misma revisión declaró obsoletas tres funciones del cliente (Roots, Sampling y Logging), y ninguna de ellas hace falta para el patrón de esta guía.

¿Cómo funciona MCP, en lenguaje sencillo?

El host es la aplicación de IA que usa una persona, como un asistente o un agente. Dentro de él, un cliente se conecta a un servidor, el servicio que ofrece datos y acciones. Una marca que construye un servidor MCP para datos de producto está en el lado del servidor; las plataformas de agentes son los hosts.

Un servidor ofrece tres tipos de función, que la especificación separa según quién tiene el control:

Cada herramienta tiene un nombre, una descripción escrita para el modelo y un JSON Schema para su entrada. Si una herramienta declara un esquema de salida, el servidor debe devolver resultados estructurados que se ajusten a él. Esa es la diferencia entre que un agente lea «unos 2 kg» en un texto y que reciba un peso con un valor y una unidad. Los recursos pueden describirse con plantillas de URI, de modo que un servidor puede publicar un patrón por GTIN en lugar de listar millones de artículos.

Los transportes son la forma en que viajan los mensajes. La especificación define stdio, en el que el host ejecuta el servidor como un proceso local, y Streamable HTTP, en el que el servidor es un servicio web con un único endpoint. Un catálogo expuesto a agentes en la Web usa Streamable HTTP.

La autorización es opcional y se aplica al transporte HTTP. Sigue OAuth 2.1: el servidor MCP actúa como servidor de recursos, un servidor de autorización independiente o alojado junto a él emite los tokens de acceso, y el servidor MCP debe publicar Protected Resource Metadata (RFC 9728) para que los clientes puedan descubrir dónde obtener un token. Los tokens deben emitirse para ese servidor concreto.

¿Por qué una marca tendría un servidor MCP para datos de producto?

Porque los agentes actúan con los datos de producto que encuentren, y cuanto más cerca estén de la marca, menos adivinan. Nuestro artículo sobre la identidad de producto para agentes de IA lo resumía en una línea: los nombres describen, los identificadores identifican. Un servidor MCP permite a una marca responder directamente a la pregunta de un agente, a partir del identificador.

• Datos en vivo. El estado de retirada, las variantes descatalogadas y las versiones de los documentos cambian. Una llamada a una herramienta devuelve la respuesta de hoy; una página rastreada devuelve la respuesta del último rastreo.
• Respuestas estructuradas. Los esquemas de salida fijan unidades y nombres de campo, de modo que todos los agentes reciben la misma especificación con la misma forma.
• Acceso escalonado. La especificación permite que un servidor varíe las herramientas y los recursos que lista según la autorización de cada petición, de modo que llamantes públicos y socios autenticados pueden usar el mismo servidor.

Hay límites. Una plataforma de agentes tiene que conectarse a tu servidor; MCP no hace que un servidor sea descubrible por sí solo. Y la especificación de MCP no menciona los GTIN, GS1 Digital Link ni los Pasaportes Digitales de Producto. Cómo encajan entre sí, en el resto de esta guía, es nuestra interpretación.

¿Qué datos de producto deberías exponer a los agentes?

Empieza por las preguntas que los agentes necesitan resolver para elegir el producto correcto, y por los datos que ya mantienes y respaldas.

• Identidad. GTIN, URI de GS1 Digital Link, marca, nombre del producto, variante y tamaño del envase. Todas las demás respuestas dependen de ella.
• Especificaciones. Dimensiones, peso, materiales, compatibilidad, composición, en unidades fijas.
• Información de cumplimiento. Declaraciones de conformidad, información de seguridad, instrucciones, certificaciones. MCP es una vía más para servir documentos que ya facilitas.
• Datos del pasaporte. La parte pública de un Pasaporte Digital de Producto para todo el mundo, y las partes restringidas para llamantes autenticados con el rol adecuado. La guía de requisitos de datos del Pasaporte Digital de Producto explica qué contiene un pasaporte.
• Disponibilidad. Si una variante está vigente, descatalogada o retirada, y el stock o los plazos de entrega para los socios comerciales. El precio de venta al público y el stock suelen estar en manos de los minoristas.

Una regla práctica: si un dato está impreso en el envase, en una página de producto pública o en la parte pública de un pasaporte, puede ser público en el servidor MCP. La información comercial confidencial, y los datos que la ley reserva a agentes concretos, van detrás de la autorización.

Una arquitectura práctica

La tabla es un diseño de partida que ilustra cómo se corresponden las piezas básicas de MCP con los datos de producto. No es un esquema definido por MCP ni por GS1.

Herramientas para preguntas, recursos para documentos. Un agente que decide por sí mismo qué consultar necesita herramientas, porque las herramientas las controla el modelo. Los documentos que un host o una persona adjunta como contexto encajan como recursos. Una herramienta de búsqueda puede devolver datos estructurados más enlaces a los recursos pertinentes.

Usa el URI de Digital Link como dirección pública. La especificación dice que los servidores deberían usar el esquema https:// para un recurso solo cuando el cliente pueda obtenerlo directamente de la Web sin pasar por el servidor MCP. Un URI de GS1 Digital Link es exactamente eso. Para la información pública, el servidor puede devolver el URI de Digital Link y dejar que el agente lo resuelva; para los datos restringidos, puede usar su propio esquema de URI y servir el contenido tras comprobar el token:

tool:      lookup_product(gtin)  → identity, specs, links
public:    https://id.example.com/01/09506000134352
template:  dpp-restricted://{gtin}/{lot}

Ajusta el acceso a los roles que ya tienes. Los scopes de OAuth pueden reflejar tus niveles de acceso: público, socio comercial, reparador o reciclador, autoridad. Las indicaciones de seguridad de la especificación recomiendan un conjunto inicial mínimo de scopes, y pedir más solo cuando se intente una operación privilegiada. Con el ESPR, qué agentes ven qué datos del pasaporte lo fija el acto delegado de cada grupo de productos, y el servidor MCP solo aplica esa decisión. Nuestra guía sobre los derechos de acceso al Pasaporte Digital de Producto cubre esos niveles.

En la revisión actual, los resultados que listan o leen datos también llevan un ámbito y una duración de caché. Los datos de producto públicos pueden marcarse como públicos; todo lo que se devuelva a un llamante autenticado debería marcarse como privado para que los intermediarios compartidos no lo almacenen en caché.

¿Cómo encaja un servidor MCP con el resolver, el pasaporte y schema.org?

El riesgo de cualquier canal nuevo es una nueva copia de los datos que se desvía. Trata el servidor MCP como una interfaz más sobre el mismo registro de producto, identificado por el mismo GTIN.

El resolver GS1 Digital Link ya responde a las máquinas. Según el GS1-Conformant Resolver Standard, un cliente que pide el linkset con el tipo de medio application/linkset+json recibe en JSON todos los enlaces registrados para ese producto, tipados con el vocabulario GS1 Web, como gs1:pip para la página de información del producto. La guía sobre el resolver GS1 Digital Link explica la resolución. El resolver sigue siendo la dirección pública controlada por la marca; el servidor MCP añade encima consultas estructuradas y acceso autenticado.

El Pasaporte Digital de Producto tiene sus propias normas sobre acceso, portadores de datos y copias de seguridad, y ninguna de ellas menciona MCP. Un servidor MCP puede servir datos del pasaporte a los agentes, pero no sustituye al portador de datos del producto. En nuestra interpretación, debería leer del mismo registro del pasaporte, para que un agente y una persona que escanea el envase vean los mismos valores.

El marcado schema.org y los feeds siguen importando. El tipo Product de schema.org tiene propiedades para gtin, offers, countryOfOrigin y hasCertification, y los rastreadores leen el marcado de las páginas de producto sin que nadie configure una conexión. Los feeds llegan a plataformas que nunca llamarán a tu servidor.

El código QR ayuda con la identidad. El código QR GS1 Digital Link del envase codifica el mismo URI que devuelve el servidor MCP, de modo que un comprador que escanea y un agente que consulta llegan al mismo producto. No ayuda en la conversación del agente en sí: los agentes no escanean envases para llamar a tu servidor.

¿Qué dice la especificación sobre seguridad?

La especificación afirma que MCP no puede imponer la seguridad a nivel de protocolo, y pide a quienes lo implementan que incorporen consentimiento, autorización y controles de acceso en sus aplicaciones. Para un servidor de datos de producto, estos son los puntos que más importan:

• Validar, controlar, limitar, sanear. Los servidores deben validar todas las entradas de las herramientas, implementar controles de acceso adecuados, limitar la frecuencia de invocación de las herramientas y sanear sus salidas. Los URI de los recursos deben validarse, y los recursos sensibles deberían tener controles de acceso.
• Proteger el endpoint. En Streamable HTTP, los servidores deben validar la cabecera Origin para evitar ataques de DNS rebinding y deberían autenticar todas las conexiones.
• Aceptar solo tus propios tokens. Un servidor no debe aceptar tokens emitidos para otros servicios ni reenviar el token de un cliente a los sistemas posteriores. Cuando llama a tu PIM o ERP, usa sus propias credenciales.
• Mantener los scopes pequeños. Evita los scopes que lo abarcan todo; concede lo que necesita cada operación.

En el lado del host, la especificación espera que haya una persona en el circuito que pueda rechazar las llamadas a herramientas, y pide a los clientes que traten las anotaciones de las herramientas como no fiables salvo que procedan de un servidor de confianza. Es un buen motivo para escribir descripciones de herramientas precisas y modestas.

Qué hacer ahora

1. Resuelve primero la identidad. Cada producto que quieras que gestionen los agentes necesita un GTIN y un URI de GS1 Digital Link que funcione en un resolver conforme con GS1.
2. Elige una única fuente de verdad. Planifica el servidor MCP como un lector de tu registro de producto de referencia, no como una base de datos nueva.
3. Haz la lista de preguntas. Anota las diez preguntas que más necesitan resolver los agentes y conviértelas en unas pocas herramientas bien descritas con esquemas de salida.
4. Separa lo público de lo restringido. Clasifica cada campo como público, solo para socios o restringido por rol, usando los niveles de acceso del pasaporte cuando se apliquen.
5. Diseña los scopes antes que el código. Asigna esas clases a un conjunto mínimo de scopes de OAuth y elige el servidor de autorización.
6. Desarrolla según la revisión 2026-07-28 con Streamable HTTP, dejando fuera las funciones obsoletas.
7. Mantén los demás canales. Conserva el marcado schema.org y los feeds junto al servidor.

Digital Link es partner de soluciones de GS1, y nuestra plataforma da a cada producto un URI y un código QR de GS1 Digital Link con un resolver conforme detrás, un registro de producto estructurado y los datos públicos y restringidos del pasaporte separados. Ese registro es la fuente única de la que debería leer un servidor MCP, para que agentes, compradores y buscadores vean el mismo producto. Si quieres decidir qué debería exponer tu catálogo a los agentes de IA y qué debería quedar restringido, ponte en contacto con nosotros y nuestro equipo estudiará tu caso.

Preguntas frecuentes

¿De quién es el Model Context Protocol?

Anthropic creó MCP y lo lanzó en noviembre de 2024. Desde diciembre de 2025 forma parte de la Agentic AI Foundation, un fondo dirigido dentro de la Linux Foundation cofundado por Anthropic, Block y OpenAI. Las decisiones técnicas las toman los mantenedores del proyecto mediante un proceso público de propuestas.

¿Cuál es la versión actual de la especificación MCP?

A octubre de 2026, la revisión 2026-07-28, publicada el 28 de julio de 2026. Hizo el protocolo sin estado al eliminar el saludo inicial y las sesiones a nivel de protocolo, y declaró obsoletas las funciones Roots, Sampling y Logging.

¿Un servidor MCP es lo mismo que una API?

Es una API con una forma estándar para aplicaciones de IA. Cualquier host compatible con MCP puede listar tus herramientas y recursos, leer sus descripciones y esquemas e invocarlos de la misma manera, en lugar de aprender endpoints a medida. Muchos equipos lo construyen como una capa fina sobre una API de producto existente.

¿Necesitan los agentes de IA GS1 Digital Link para usar un servidor MCP?

No. La especificación de MCP no hace referencia a los identificadores GS1. En nuestra interpretación, basar todos los canales en el GTIN y su URI de GS1 Digital Link da a los agentes una identidad inequívoca, lo que evita que confundan productos parecidos.

¿Puede un servidor MCP mantener privados algunos datos de producto?

Sí. La autorización sigue OAuth 2.1, y un servidor puede variar qué herramientas y recursos lista según el token de cada petición. El servidor tiene que aplicar esas comprobaciones en cada llamada.

¿Un servidor MCP hace que mi Pasaporte Digital de Producto cumpla la normativa?

No. El contenido del pasaporte, su portador de datos y los derechos de acceso los fijan el ESPR y el acto delegado de cada grupo de productos, y ninguno menciona MCP. Un servidor MCP puede ser una vía adicional para servir datos del pasaporte, leídos del mismo registro.