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 seven tools:
- verify_product: authenticity status of a product (authentic, revoked, expired, found without an active certificate, 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 reference on Base with its basescan.org link, a Merkle batch root when the product's batch was anchored and otherwise the product's own mint transaction, which proves the token exists and says nothing about the passport's content, the separate anchor of this passport version's content hash once the sweep has written it, credential status, and the count of successful physical tag verifications, a proof that does not exist being omitted rather than returned empty;
- get_certificate: the public certificate of authenticity;
- resolve_gs1: resolution of a GS1 Digital Link to a passport, the item's with a serial, the model's without one, which is what goods sold by the metre, the box or the pallet need;
- verify_credential: verification of the passport's SD-JWT-VC against the brand's
did:websigning key; - get_product_history: the item's timeline, verifications and ownership transfers, oldest first.
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, and the full guide, scope, setup, choosing the identifier and the seven tools one by one, is in our technical documentation.
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 pull the proof bundle, which reports only the proofs that actually hold for that unit: the seal that says whether the stored passport still matches what was published, and, when they exist, the immutable IPFS copy and the on-chain reference on Base. 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, accredited repairers and recyclers, upstream actors, market surveillance authorities, stay behind authentication, as our own access model provides. 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: eur-lex.europa.eu
- The Commission Joint Research Centre's DPP methodology (JRC145830, Annex 8), a scientific report with no legal force, from which our access tiers are drawn. The regulation itself sets none.
