A growing share of product questions are no longer typed into a search engine, they are asked to an assistant. "Is this bag authentic?" "What is in this battery?" "Does this item have a Digital Product Passport?" When the person asking holds the product, the assistant needs more than a web page to answer: it needs a way to query the proof itself.
That is what we are releasing today. @sealtrust-io/mcp-server exposes SealTrust's public verification API as a Model Context Protocol (MCP) server, so any MCP-capable agent (Claude Desktop, Claude Code and others) can verify a product and read its passport on its own. It is read-only, works on public data only, and requires no account and no API key.
AI agents are becoming consumers of product proof
Until now, the audiences of a product passport were people and institutions: the consumer scanning a tag, the repairer looking up a part, the market surveillance authority checking compliance. A fourth audience is arriving fast, software agents acting on someone's behalf. An assistant helping with a second-hand purchase, a procurement tool screening suppliers, an internal bot preparing a compliance file.
These agents have a specific need: structured, verifiable answers. A marketing page is of little use to them; a signed credential, a content hash, or an on-chain anchor is something they can actually check. A proof that an agent cannot fetch and verify programmatically might as well not exist for this audience. The infrastructure we built for the ESPR (public endpoints, JSON-LD exports, verifiable credentials, GS1 Digital Link) turns out to be exactly what agents need. The MCP server is the missing connector.
What MCP is
The Model Context Protocol is an open standard for connecting AI assistants to external tools and data sources. A server declares a set of tools with typed inputs; the agent decides when to call them and reasons over the results. It has been adopted well beyond its origins, and most serious agent platforms speak it today.
For a brand, the practical consequence is simple: publishing an MCP server is how you make your data usable by this new audience, the same way publishing a REST API made it usable by developers.
What the SealTrust server exposes
The server is a thin, read-only layer over the public endpoints we already document on our developers page. It ships six tools:
- verify_product: authenticity status of a product (authentic, revoked, expired or unknown) with its public information and certificate summary;
- get_passport: the published Digital Product Passport, public access tier only, as JSON or JSON-LD;
- get_passport_proof: the proof bundle: SHA-256 hash of the passport data, IPFS copy, on-chain anchor on Base with its basescan.org link, credential status;
- get_certificate: the public certificate of authenticity;
- resolve_gs1: resolution of a GS1 Digital Link (GTIN + serial) to the item's passport;
- verify_credential: verification of the passport's SD-JWT-VC against the brand's
did:websigning key.
Installation is one command, npx @sealtrust-io/mcp-server, or a few lines in an MCP client's configuration. The exact snippets are on the developers page.
Three situations where this changes the answer
Authenticity in a conversation. Someone pastes a certificate number or a product identifier into a chat and asks whether the item is genuine. The agent calls verify_product and answers from the registry, including the uncomfortable cases: a revoked certificate is flagged as such, and an identifier with no record comes back as "unknown" rather than a guess.
Second-hand purchases. Before buying a used item, a buyer's assistant can read the passport, check that the certificate is active, and confirm that the passport's content hash is anchored on-chain. The seller's story and the product's record can finally be compared in the time it takes to ask.
Assisted compliance work. Teams preparing ESPR files can let an agent pull passports as JSON-LD, verify credentials, and resolve GS1 Digital Links across a product range, the repetitive lookups of an audit, done by the tool that is already drafting the document.
What it deliberately does not do
The server can only read. It issues GET requests against public endpoints, nothing it does can mint, transfer or modify a product. It only sees the public access tier of a passport: the restricted tiers (value chain, authority) stay behind authentication, exactly as the ESPR intends. And it handles no personal data, it looks up products, not people.
That narrowness is the point. An integration you can hand to any agent without a security review of write paths is an integration that actually gets deployed.
Proof that machines can check
The reason this works is not the connector itself, it is what sits underneath. Every SealTrust passport carries a SHA-256 hash of its content, can be pinned to IPFS, is anchored on Base L2, and can be issued as a signed verifiable credential. Those properties were designed so that every claim can be verified independently. Agents are simply the first audience that checks systematically.
Want your products to be readable and verifiable by AI agents? Talk to us.
Sources
- Model Context Protocol, specification and documentation: modelcontextprotocol.io
- Regulation (EU) 2024/1781 (ESPR), Digital Product Passport & access tiers: eur-lex.europa.eu
