MCP server for product data: exposing your catalogue to AI agents

TL;DR

• An MCP server for product data lets AI agents query a brand's catalogue directly through the Model Context Protocol, an open specification launched by Anthropic in November 2024 and governed since December 2025 under the Linux Foundation's Agentic AI Foundation.
• MCP gives a server three building blocks: tools the model can call, resources the application can read, and prompts the user can choose. Access control uses OAuth 2.1, and a server can show each caller only what its token allows.
• An MCP server does not replace your GS1 Digital Link resolver, your Digital Product Passport or your schema.org markup. It works best as one more door onto the same source of truth, keyed by the same GTIN.

An MCP server for product data is a service that answers AI agents' questions about your products in a form they are built to use: the specifications for this GTIN, whether this variant is current, where the declaration of conformity is. The Model Context Protocol (MCP) is the open protocol that defines how an AI application connects to such a server. It was on the programme of the W3C/GS1 workshop on e-commerce for humans and AI agents in Zurich, and it is the agent protocol most developers meet first, because it is not specific to commerce.

This guide explains what MCP is and who runs it, its building blocks in plain language, and how a brand or manufacturer could use an MCP server to expose identifiers, specifications, compliance and passport data and availability while keeping restricted data restricted. Everything below is stated as of October 2026.

What is the Model Context Protocol?

MCP is a published open specification. Its current revision describes it as an open protocol for connecting applications built on large language models with external data sources and tools. Messages are exchanged in JSON-RPC 2.0, and the specification is released under the Apache License 2.0.

Anthropic introduced MCP on 25 November 2024 and published the specification and software development kits on GitHub. On 9 December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. The governance model did not change: maintainers make technical decisions, and specification changes go through Specification Enhancement Proposals (SEPs). Maintainer seats belong to individuals, not companies.

MCP versions are named by the date of their last backwards-incompatible change. The 2026-07-28 revision made the protocol stateless: there is no session or opening handshake, and every request carries its own protocol version and client capabilities, so any server instance can answer it. For a product data service behind a load balancer, that is a real simplification. The same revision deprecated three client features (Roots, Sampling and Logging), none of which the pattern in this guide needs.

How does MCP work, in plain language?

The host is the AI application a person uses, such as an assistant or an agent. Inside it, a client connects to one server, the service that offers data and actions. A brand building an MCP server for product data is on the server side; agent platforms are the hosts.

A server offers three kinds of feature, which the specification separates by who is in control:

Each tool has a name, a description written for the model and a JSON Schema for its input. If a tool declares an output schema, the server must return structured results that conform to it. That is the difference between an agent reading "about 2 kg" from prose and receiving a weight with a value and a unit. Resources can be described with URI templates, so a server can publish one pattern per GTIN instead of listing millions of items.

Transports are how messages travel. The specification defines stdio, where the host runs the server as a local process, and Streamable HTTP, where the server is a web service with a single endpoint. A catalogue exposed to agents on the Web uses Streamable HTTP.

Authorisation is optional and applies to the HTTP transport. It follows OAuth 2.1: the MCP server acts as a resource server, a separate or co-hosted authorisation server issues access tokens, and the MCP server must publish Protected Resource Metadata (RFC 9728) so clients can discover where to get a token. Tokens must be issued for that specific server.

Why would a brand run an MCP server for product data?

Because agents act on whatever product data they can find, and the closer it is to the brand, the less they guess. Our piece on product identity for AI agents put it in one line: names describe, identifiers identify. An MCP server lets a brand answer an agent's question directly, keyed by the identifier.

• Live data. Recall status, discontinued variants and document versions change. A tool call returns today's answer; a crawled page returns the answer from the last crawl.
• Structured answers. Output schemas fix units and field names, so every agent gets the same specification in the same shape.
• Graded access. The specification lets a server vary the tools and resources it lists according to the authorisation on each request, so public callers and authenticated partners can use the same server.

There are limits. An agent platform has to connect to your server; MCP does not make a server discoverable by itself. And the MCP specification does not mention GTINs, GS1 Digital Link or Digital Product Passports. How they fit together, in the rest of this guide, is our reading.

Which product data should you expose to agents?

Start from the questions agents need answered to pick the right product, and from data you already maintain and stand behind.

• Identity. GTIN, GS1 Digital Link URI, brand, product name, variant and pack size. Every other answer hangs off it.
• Specifications. Dimensions, weight, materials, compatibility, composition, in fixed units.
• Compliance information. Declarations of conformity, safety information, instructions, certifications. MCP is one more way to serve documents you already provide.
• Passport data. The public part of a Digital Product Passport for everyone, restricted parts for authenticated callers with the right role. The Digital Product Passport data requirements guide sets out what a passport carries.
• Availability. Whether a variant is current, discontinued or recalled, and stock or lead times for trade partners. Retail price and stock usually sit with retailers.

A rule of thumb: if a fact is printed on the pack, on a public product page or in the public part of a passport, it can be public on the MCP server. Confidential business information, and data the law reserves for specific actors, belongs behind authorisation.

A practical architecture

The table is a starting design, illustrating how MCP's building blocks map to product data. It is not a schema defined by MCP or GS1.

Tools for questions, resources for documents. An agent deciding by itself what to look up needs tools, because tools are model-controlled. Documents a host or person attaches as context fit resources. A lookup tool can return structured data plus links to the relevant resources.

Use the Digital Link URI as the public address. The specification says servers should use the https:// scheme for a resource only when the client can fetch it directly from the Web without the MCP server. A GS1 Digital Link URI is exactly that. For public information, the server can return the Digital Link URI and let the agent resolve it; for restricted data, it can use its own URI scheme and serve the content after checking the token:

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

Scope access to roles you already have. OAuth scopes can mirror your access tiers: public, trade partner, repairer or recycler, authority. The specification's security guidance recommends a minimal initial set of scopes, with more requested only when a privileged operation is attempted. Under the ESPR, which actors see which passport data is set by the delegated act for each product group, and the MCP server only enforces that decision. Our guide to Digital Product Passport access rights covers those tiers.

Results that list or read data also carry a cache scope and lifetime in the current revision. Public product data can be marked public; anything returned to an authenticated caller should be marked private so shared intermediaries do not cache it.

How does an MCP server fit with the resolver, the passport and schema.org?

The risk with any new channel is a new copy of the data that drifts. Treat the MCP server as one more interface on the same product record, keyed by the same GTIN.

The GS1 Digital Link resolver already answers machines. Under the GS1-Conformant Resolver Standard, a client that requests the linkset with the application/linkset+json media type receives every link registered for that product as JSON, typed with the GS1 Web vocabulary, such as gs1:pip for the product information page. The GS1 Digital Link resolver guide explains resolution. The resolver stays the public, brand-controlled address; the MCP server adds structured lookups and authenticated access on top.

The Digital Product Passport has its own rules on access, data carriers and back-up copies, and none of them refer to MCP. An MCP server can serve passport data to agents, but it does not replace the data carrier on the product. In our reading, it should read from the same passport record, so an agent and a person scanning the pack see the same values.

Schema.org markup and feeds still matter. Schema.org's Product type has properties for gtin, offers, countryOfOrigin and hasCertification, and markup on product pages is read by crawlers without anyone configuring a connection. Feeds reach platforms that will never call your server.

The QR code helps with identity. The GS1 Digital Link QR code on the pack encodes the same URI the MCP server returns, so a shopper scanning and an agent querying land on the same product. It does not help the agent conversation itself: agents do not scan packs to call your server.

What does the specification say about security?

The specification states that MCP cannot enforce security at the protocol level, and asks implementers to build consent, authorisation and access controls into their applications. For a product data server, these points matter most:

• Validate, control, limit, sanitise. Servers must validate all tool inputs, implement proper access controls, rate limit tool invocations and sanitise tool outputs. Resource URIs must be validated, and sensitive resources should have access controls.
• Protect the endpoint. On Streamable HTTP, servers must validate the Origin header to prevent DNS rebinding attacks and should authenticate all connections.
• Accept only your own tokens. A server must not accept tokens issued for other services or pass a client's token through to downstream systems. When it calls your PIM or ERP, it uses its own credentials.
• Keep scopes small. Avoid catch-all scopes; grant what each operation needs.

On the host side, the specification expects a human in the loop who can refuse tool calls, and tells clients to treat tool annotations as untrusted unless they come from a trusted server. That is a good reason to write tool descriptions that are accurate and modest.

What to do now

1. Fix identity first. Every product you want agents to handle needs a GTIN and a working GS1 Digital Link URI on a GS1-conformant resolver.
2. Pick one source of truth. Plan the MCP server as a reader of your authoritative product record, not a new database.
3. List the questions. Write down the ten questions agents most need answered, and turn them into a few well-described tools with output schemas.
4. Split public from restricted. Classify each field as public, partner-only or role-restricted, using passport access tiers where they apply.
5. Design scopes before code. Map those classes to a minimal set of OAuth scopes and choose the authorisation server.
6. Build to revision 2026-07-28 with Streamable HTTP, leaving out deprecated features.
7. Keep the other channels. Maintain schema.org markup and feeds alongside the server.

Digital Link is a GS1 solution partner, and our platform gives every product a GS1 Digital Link URI and QR code with a conformant resolver behind it, a structured product record, and public and restricted passport data kept separate. That record is the single source an MCP server should read from, so agents, shoppers and search engines see the same product. If you want to work out what your catalogue should expose to AI agents and what should stay restricted, get in touch and our team will look at your case.

Frequently asked questions

Who owns the Model Context Protocol?

Anthropic created MCP and launched it in November 2024. Since December 2025 it has sat within the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. Technical decisions are made by the project's maintainers through a public proposal process.

What is the current version of the MCP specification?

As of October 2026, revision 2026-07-28, released on 28 July 2026. It made the protocol stateless by removing the opening handshake and protocol-level sessions, and deprecated the Roots, Sampling and Logging features.

Is an MCP server the same as an API?

It is an API with a standard shape for AI applications. Any MCP-capable host can list your tools and resources, read their descriptions and schemas, and call them the same way, instead of learning bespoke endpoints. Many teams build it as a thin layer over an existing product API.

Do AI agents need GS1 Digital Link to use an MCP server?

No. The MCP specification does not refer to GS1 identifiers. In our reading, keying every channel on the GTIN and its GS1 Digital Link URI gives agents one unambiguous identity, which stops them confusing similar products.

Can an MCP server keep some product data private?

Yes. Authorisation follows OAuth 2.1, and a server may vary which tools and resources it lists according to the token on each request. The server has to enforce those checks on every call.

Does an MCP server make my Digital Product Passport compliant?

No. The passport's content, data carrier and access rights are set by the ESPR and the delegated act for each product group, and none of them mention MCP. An MCP server can be an extra way to serve passport data, read from the same record.