Skip to main content
Glama

TracePass passports

tracepass_passports

Manage Digital Product Passports — create, read, and run lifecycle actions.

IMPORTANT: create consumes a DPP slot on the account's plan and IS BILLABLE. Creating a passport beyond the included quota incurs a per-passport overage charge; if over quota the tool returns a 402-style message — only re-run with args.confirmOverage=true after the user explicitly agrees to the charge. archive is IRREVERSIBLE (the public QR permanently 404s); prefer suspend when a change might be undone.

Actions (pass via action, with args):

  • list — args: { page?, limit? (≤100), productId?, status?, search? }. status ∈ draft|in_review|approved|published|suspended|expired|archived. Read-only.

  • get — args: { id, format? (summary|full), lang? }. Read-only.

  • get_by_serial — args: { serial, format?, lang?, gtin? }. Read-only. Addresses the passport by your own serial. A serial is unique only WITHIN a GTIN — if the same serial exists under two GTINs in your account the call returns 409 ambiguous_serial; pass gtin (or use the by-id action) to resolve exactly.

  • compliance — args: { id }. Read-only. Returns a three-tier compliance verdict (compliant | compliant_with_warnings | incomplete) with regulation-cited findings — use to gap-check a passport against the rules for its category, fix the cited fields/parties, then re-check.

  • registry_readiness — args: { id }. Read-only. Returns { ready, findings[] } — whether the passport would pass the EU DPP Registry's FORMAL submission gate (mandatory fields present, correct formatting, a resolvable public link, item-level granularity via a serial number, and a well-formed commodity code where the category carries one). This is the registry's mechanical pre-submission check, NOT the substantive compliance verdict; a passport can be registry-ready yet not substantively compliant. Battery passports only.

  • create — args: { productId, gtin, serialNumber, confirmOverage? }. BILLABLE.

  • suspend — args: { id }. Reversible — public QR shows 'suspended'.

  • suspend_by_serial — args: { serial, gtin? }. Same as suspend, addressed by your serial. 409 ambiguous_serial if the serial isn't unique in your account — pass gtin.

  • archive — args: { id }. IRREVERSIBLE — confirm with the user first.

  • archive_by_serial — args: { serial, gtin? }. IRREVERSIBLE, addressed by your serial — confirm first. 409 ambiguous_serial if the serial isn't unique — pass gtin.

  • get_qr — args: { id, format? (svg|png) }. Read-only.

  • get_qr_by_serial — args: { serial, format? (svg|png), gtin? }. Read-only. Same as get_qr, addressed by your own serial. A serial is unique only WITHIN a GTIN — if the same serial exists under two GTINs in your account the call returns 409 ambiguous_serial; pass gtin (or use get_qr by id) to resolve exactly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsNoArguments for the chosen action; required fields depend on `action` (see each action above).
actionYesWhich passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_qr | get_qr_by_serial. Lifecycle: create (BILLABLE) | suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoThe resource's TracePass id, when the response is a single entity.
pageNoCurrent page number (list actions).
errorNoMachine-readable error code, when the API rejected the request.
itemsNoThe page of results, when the action is a list.
limitNoPage size (list actions).
totalNoTotal matching records across all pages (list actions).
resultNoWraps a non-object response body (e.g. a QR code string).
messageNoHuman-readable error or status detail, when present.
totalPagesNoTotal number of pages (list actions).

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the single idempotentHint annotation, the description discloses billable create with overage charges/402 confirmOverage, archive irreversibility (QR 404s), suspend reversibility, and ambiguous_serial 409 behavior. It marks each action as read-only or lifecycle, providing operational expectations the agent cannot infer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Structured as a bullet list with CAPITALIZED warnings, the description front-loads billing/irreversibility and logically groups action args. It is lengthy but each sentence contributes; there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 12 actions, nested args, billing side effects, and two distinct by_serial addressing modes, the description covers every operation, its required args, edge cases, and error conditions. Output schema exists, and the description need not restate return values; it still mentions compliance verdict tiers and registry_readiness shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema covers 100% of parameters, the description adds cross-parameter semantics and action-specific requirements: e.g., limit ≤100, status enum, serial unique only within GTIN, and per-action arg sets. It explains confirmOverage and the ambiguous_serial condition for multi-param interactions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Manage Digital Product Passports — create, read, and run lifecycle actions,' a specific verb+resource purpose. It enumerates all 12 actions, clearly distinguishing this tool from siblings like tracepass_products or tracepass_passport_fields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance includes 'prefer suspend when a change might be undone' vs archive, and the compliance vs registry_readiness distinction ('NOT the substantive compliance verdict'). It also tells when to pass gtin to resolve ambiguous_serial, and when to use the by-id vs by-serial actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool targets a distinct domain: EPCIS events, passport fields, passport parties, passport lifecycle, product catalogue, and regulatory templates. There is no overlap in purpose between tools, and even the related passport_fields and passport_parties are clearly separated by the type of data they manage.

Naming Consistency5/5

All tools follow a consistent 'tracepass_' prefix followed by a plural noun (epcis, passport_fields, passport_parties, passports, products, templates). Actions within each tool use lowercase verbs (e.g., list, get, create, update, export, capture) with consistent _by_serial variants, creating a uniform and predictable naming scheme.

Tool Count5/5

With 6 tools, the server is well-scoped for a Digital Product Passport platform. Each tool covers a necessary slice of the domain without redundancy or excessive granularity, fitting comfortably within the ideal range of 3-15 tools.

Completeness4/5

The tool set covers the full passport lifecycle (create, read, update via fields/parties, suspend, archive), product management, EPCIS event capture/query, and regulatory template discovery. The only notable gap is the lack of a delete action for products, but this is a minor oversight given the strong overall coverage.