TracePass

by eu.tracepass

Overview Discussions Admin

Server Details

Manage products, EU Digital Product Passports, operator parties, and GS1 EPCIS supply-chain events.

Ownership verified

Status: Healthy
Uptime: 100.0% over 71 days
Last Tested: 2026-10-27 05:55
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: malinoto/tracepass-mcp-server
GitHub Stars: 1
Server Listing: tracepass-mcp-server

TDQS

A4.4/5.0

Scored 2026-10-28 20:50 across 7 tools

Disambiguation4/5

The seven tools mostly map to clearly separate domains: EPCIS events, passport fields, passport parties, passports, products, legal scope, and templates. The closest potential confusion is between tracepass_passports and its subresource tools (fields, parties), plus scope versus templates, but the descriptions and action lists make the boundaries reasonably clear.

Naming Consistency5/5

Every tool follows the same tracepass_<domain> snake_case pattern, and all expose their operations through a consistent `action` plus `args` interface. Although names are domain nouns rather than verb_noun pairs, the convention is highly predictable across the set.

Tool Count5/5

Seven tools is well-scoped for a DPP management server, with each tool covering a distinct domain and using action dispatch to avoid an explosion of top-level tools. Each tool clearly earns its place.

Completeness5/5

The surface covers the full passport lifecycle and supporting operations: products, passport creation/read/suspend/archive, fields, parties, measurements, condition flags, snapshots, QR generation, EPCIS events, legal scope checks, and template schemas. Publishing is intentionally dashboard-only, and archival rather than hard deletion is consistent with the domain.

Available Tools

7 tools

tracepass_epcisTracePass EPCIS 2.0AInspect

GS1 EPCIS 2.0 supply-chain events. export, capture, capture_job and query are on every plan, Free included. Captured events count against the plan's event allowance (10 a month on Free); over it, capture returns an overage or hard-block message.

Actions (pass via action, with args):

export — args: { id }. Export a passport's events as an EPCIS 2.0 JSON-LD document. Read-only.
export_by_serial — args: { serial, gtin? }. Same as export, addressed by your own serial. A serial is unique only WITHIN a GTIN — if it isn't unique in your account the call returns 409 ambiguous_serial; pass gtin (or use export by id). Read-only.
capture — args: { events }. events is an EPCISDocument, a single event, or an array of events (JSON-LD). Returns a 202 with a captureJobId.
capture_job — args: { jobId }. Poll an async capture job. Read-only.
query — args: { params? }. params is a key/value map of standard EPCIS query parameters (EQ_bizStep, GE_eventTime, MATCH_epc, …). Read-only.

Name	Required	Description	Default
`args`	No	Arguments for the chosen action; required fields depend on `action`.
`action`	Yes	EPCIS 2.0: export a passport's events (export \| export_by_serial), capture new events, poll a capture job, or query events.

Output Schema

Name	Required	Description
`id`	No	The resource's TracePass id, when the response is a single entity.
`page`	No	Current page number (list actions).
`error`	No	Machine-readable error code, when the API rejected the request.
`items`	No	The page of results, when the action is a list.
`limit`	No	Page size (list actions).
`total`	No	Total matching records across all pages (list actions).
`result`	No	Wraps a non-object response body (e.g. a QR code string).
`message`	No	Human-readable error or status detail, when present.
`totalPages`	No	Total number of pages (list actions).

TDQS

A4.7/5.0

Behavior5/5

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

Annotations are sparse (tool-level readOnlyHint=false, destructiveHint=false), so the description carries the burden and delivers: per-action read-only flags, the plan/quota model (10 events/month on Free, plan event allowance), the overage/hard-block message on capture, the async 202 + captureJobId + capture_job polling pattern, and the 409 ambiguous_serial condition. The per-action read-only notes clarify rather than contradict the conservative tool-level readOnlyHint=false, since capture writes.

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?

Front-loaded with what the tool is, then the plan/allowance caveat, then a tight bulleted action list. Every sentence earns its place—no repetition of schema content beyond the necessary arg mapping.

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?

With an output schema present, return values need not be explained, and the description still covers the async capture lifecycle, quota/overage behavior, ambiguity error handling, and per-action read-only status. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value by mapping each arg to its action (id→export, serial/gtin→export_by_serial, events→capture, jobId→capture_job, params→query) and by naming example query keys (EQ_bizStep, GE_eventTime, MATCH_epc) that the schema leaves generic.

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 identifies the resource (GS1 EPCIS 2.0 supply-chain events) and enumerates five distinct actions with a one-line purpose for each, including the subtle export vs export_by_serial distinction. An agent can distinguish this event-oriented tool from the sibling product/passport/template tools without opening the schema.

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

Usage Guidelines4/5

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

It gives clear per-action selection guidance, notably the export vs export_by_serial decision rule (serial is unique only within a GTIN; pass gtin or use id to avoid 409). It does not, however, state when to reach for this tool over the sibling tools. No explicit exclusions.

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

tracepass_passport_fieldsTracePass passport fieldsA

DestructiveIdempotent

Inspect

Update field values on a Digital Product Passport. Every change is recorded in the passport's audit trail with the credential that made it (API key or connected app) and this MCP channel.

source (optional) says where the value came from. Omit it, or pass "manual", when the user gave you the value or it comes from their own records: it is written with the user's rights (approved for an API key or an admin; sent to review for a connected app acting for an editor). Pass "ai_suggested" when you found or inferred the value yourself (web research, reading a document): it lands in the dashboard review queue for a human to approve, and it is refused on fields only the economic operator may state or that must be measured (e.g. battery stateOfHealth).

Actions (pass via action, with args):

update — args: { id, fieldKey, value, source? }. value type matches the field's dataType (string, number, boolean, array, object).
update_by_serial — args: { serial, fieldKey, value, gtin?, source? }. Same as update, addressed by your own serial. A serial is unique only WITHIN a GTIN — if it isn't unique in your account the call returns 409 ambiguous_serial; pass gtin (or use update by id) to resolve exactly.

Name	Required	Description	Default
`args`	No	Arguments for the chosen action; required fields depend on `action`.
`action`	Yes	Update one passport field, addressed by passport id (update) or by your serial (update_by_serial).

Output Schema

Name	Required	Description
`id`	No	The resource's TracePass id, when the response is a single entity.
`page`	No	Current page number (list actions).
`error`	No	Machine-readable error code, when the API rejected the request.
`items`	No	The page of results, when the action is a list.
`limit`	No	Page size (list actions).
`total`	No	Total matching records across all pages (list actions).
`result`	No	Wraps a non-object response body (e.g. a QR code string).
`message`	No	Human-readable error or status detail, when present.
`totalPages`	No	Total number of pages (list actions).

TDQS

A4/5.0

Behavior4/5

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

Adds real behavioral context beyond the annotations: audit-trail recording with the credential and MCP channel, review-queue routing for ai_suggested, rights-based write approval, and the 409 ambiguous_serial response. It does not, however, address that an update overwrites the prior field value even though destructiveHint=true is set, nor any reversibility/undo path.

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

Conciseness4/5

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

Front-loads the core action and then presents the two actions as a scannable list with arg shapes. Both paragraphs carry substantive content, though the source/rights sentence is dense and could be split for faster parsing.

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

Completeness4/5

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

An output schema exists so return values need no explanation, and the description covers mutation semantics, side effects (audit trail, review queue), source provenance, and the serial/GTIN 409 case. For a 2-action nested-args tool with a known output schema, only the overwrite/reversibility aspect is left unaddressed.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3, but the description still adds meaning: the semantics of `source` values, the GTIN-uniqueness rule that makes `serial` ambiguous ('unique only WITHIN a GTIN'), and that `value` must match the field's dataType. This goes beyond the schema's own field descriptions.

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

Purpose4/5

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

States a specific verb and resource ('Update field values on a Digital Product Passport') and names the two addressing modes (update / update_by_serial). It is clear at the field granularity, but it never explicitly contrasts itself with siblings such as tracepass_passports or tracepass_passport_parties, so differentiation is only implicit from the name and resource scope.

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

Usage Guidelines4/5

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

Gives concrete when-to-use rules for `source` (omit/"manual" when the user supplied the value, "ai_suggested" when the agent inferred it) and states the exclusions ('refused on fields only the economic operator may state or that must be measured'). It also explains when to choose update_by_serial plus `gtin` versus update by id, but contains no guidance relative to other sibling tools.

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

tracepass_passport_partiesTracePass passport partiesA

DestructiveIdempotent

Inspect

Manage the economic-operator parties on a passport — manufacturer, importer, authorisedRepresentative, distributor, recycler, producerResponsibilityOrg. Each party carries a legal name and at least one identifier.

Identifier rules (EN 18219 §6.2–6.5): a party needs at least one of gln, legacyOperatorId, or operatorIdentifier. If both gln and operatorIdentifier (scheme gln) are provided they must agree — a mismatch returns 400. An operatorIdentifier of scheme gln also fills the top-level gln field; facilityIdentifier never does. Typed identifiers (operatorIdentifier / facilityIdentifier) are not set by AI extraction or CSV import.

operatorIdentifier schemes: • iso6523 — { scheme:"iso6523", icd:"<4 digits>", value } — ICD 0199 = LEI (ISO 17442), 0088 = GLN, 0060 = DUNS. • gln — { scheme:"gln", gln:"<13 digits>" } — also fills top-level gln. • did — { scheme:"did", did:"did::" } — syntax-checked only (EN 18219 §6.4.2(b)). • doi — { scheme:"doi", doi:"10./" } — doi:/https://doi.org/ prefix accepted and stripped.

facilityIdentifier schemes: same four; the gln variant also accepts optional extension (GS1 SGLN sub-location).

Actions (pass via action, with args):

set — args: { id, role, legalName, gln?, country?, url?, tradeName?, postalAddress?, email?, legacyOperatorId?, operatorIdentifier?, facilityIdentifier? }. Sets or updates one role. tradeName, postalAddress and email are shown on the public passport; for a battery importer they are its Battery Regulation Art. 41(3) details.
remove — args: { id, role }. Clears one role.

Name	Required	Description	Default
`args`	No	Arguments for the chosen action; required fields depend on `action`.
`action`	Yes	Set (add/replace) or remove an economic-operator party on a passport by its role.

Output Schema

Name	Required	Description
`id`	No	The resource's TracePass id, when the response is a single entity.
`page`	No	Current page number (list actions).
`error`	No	Machine-readable error code, when the API rejected the request.
`items`	No	The page of results, when the action is a list.
`limit`	No	Page size (list actions).
`total`	No	Total matching records across all pages (list actions).
`result`	No	Wraps a non-object response body (e.g. a QR code string).
`message`	No	Human-readable error or status detail, when present.
`totalPages`	No	Total number of pages (list actions).

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behavior: `set` updates one role, `remove` clears one role, mismatched GLN/operatorIdentifier returns 400, identifier values fill or do not fill the top-level `gln`, and some fields are public. These details substantially improve invocation safety for a destructive, idempotent mutation tool.

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

Conciseness4/5

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

The description is long but structured and front-loaded: purpose first, then identifier rules, scheme bullets, and actions. It is appropriately detailed for a nested-schema mutation tool, though some action-argument details duplicate the input schema.

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 the nested input schema, existing output schema, and annotations, the description is complete enough for an agent to call the tool correctly. It covers role semantics, identifier validation, public-field implications, action-specific arguments, and important caveats about AI extraction and CSV imports.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents parameters well, but the description adds useful cross-field semantics: identifier-scheme rules, ICD mappings such as 0199=LEI and 0088=GLN, prefix stripping for DOI, and agreement constraints between GLN and operatorIdentifier. Some of this duplicates schema text, but the added scheme-specific meaning is meaningful.

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

Purpose4/5

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

The description states a specific verb and resource: managing economic-operator parties on a passport, with enumerated roles. It is clear what the tool operates on, but it does not explicitly distinguish itself from sibling tools such as 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 Guidelines3/5

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

The description explains the two actions (`set`, `remove`) and the identifier rules needed to invoke them, which implies when each action applies. However, it does not say when to use this tool instead of sibling tools or name any alternatives.

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

tracepass_passportsTracePass passportsA

Destructive

Inspect

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

IMPORTANT: create makes a DRAFT passport. A draft takes no plan DPP slot and is never billed; the slot, and any per-DPP overage past the plan cap, is taken when the passport is published, which happens in the TracePass dashboard, not through this tool. Each create counts against the daily write budget. archive is IRREVERSIBLE (the public QR permanently 404s); prefer suspend when a change might be undone.

IDENTIFIER SCHEMES (EN 18219): passports are identified by one of five schemes. Battery passports (Battery Regulation Art. 77(3)) accept ONLY gs1 and iso15459. • gs1 — { scheme:"gs1", gtin, serialNumber } — GS1 GTIN + serial; gtin is 8/12/13/14 digits, stored as GTIN-14. • iso15459 — { scheme:"iso15459", issuingAgencyCode, primaryId, serial? } — ISO/IEC 15459; the server derives raw (IAC + primaryId + serial). • iec61406 — { scheme:"iec61406", uri } — IEC 61406 Identification Link (https URI). Not valid for batteries. • did — { scheme:"did", did, method } — W3C DID Core. Not valid for batteries. • doi — { scheme:"doi", doi, granularity:"model"|"batch"|"item" } — ISO 26324 DOI, stored as bare 10./ (any https://doi.org/ or doi: prefix stripped on input; resolves as https://doi.org/); granularity REQUIRED per EN 18219 §5.6.2(b). Not valid for batteries. The legacy top-level gtin + serialNumber pair is still accepted as a deprecated alias for scheme:"gs1".

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. Response includes identifier, identifierKey, and (for GS1 passports) gs1.
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. Also returns byRegulation[]: the same findings grouped per regulation, worst first, so you can tell WHICH regime is failing instead of reading one incomplete as everything being wrong. A regulation absent from that array raised no finding — that is not the same as it having passed.
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, identifier?, gtin?, serialNumber?, lineage? }. Creates a draft (not billed). Provide identifier (preferred) or legacy gtin + serialNumber. Battery passports accept only gs1 and iso15459 schemes — other schemes return 400. A duplicate identifier returns 409. lineage (battery only) — a repurposed, remanufactured or reused battery needs a NEW passport linked to the original(s) (Battery Regulation Art. 77(7)): { predecessors: [ { internalPassportId? | identifier?, trigger: preparation_for_reuse|preparation_for_repurposing|repurposing|remanufacturing } ] (≤10), noPredecessorReason? (only with an empty list, e.g. placed on the market before 18 Feb 2027) }. The server derives batteryStatus from the triggers and links your own predecessor passports back. Immutable after create. Rule violations return 422 with the rule code (duplicate_predecessor, predecessor_not_found, status_trigger_mismatch, …).
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, reason? (recycled|never_placed|duplicate_or_error) }. IRREVERSIBLE and destructive — confirm with the user first. reason is REQUIRED for battery passports (400 reason_required / invalid_reason without a valid one): recycled, never_placed (never placed on the market or put into service), or duplicate_or_error (a duplicate or erroneous record); for other categories it is optional. A passport marked for deletion cannot be archived (409).
archive_by_serial — args: { serial, gtin?, reason? }. IRREVERSIBLE and destructive, addressed by your serial — confirm first. Same reason rule as archive. 409 ambiguous_serial if the serial isn't unique — pass gtin.
get_qr — args: { id, format? (svg|png), symbology? (qr|datamatrix) }. Read-only. symbology=datamatrix renders an ISO/IEC 16022 Data Matrix instead of a QR (EN 18220 permits both; same passport URL).
get_qr_by_serial — args: { serial, format? (svg|png), symbology? (qr|datamatrix), 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.
list_snapshots — args: { id, page?, limit? (≤100), at? (ISO 8601) }. Read-only. Returns a paginated list of snapshots for the passport (newest first). A snapshot is written on publish and after every change to a non-draft passport (EN 18221 change archive); each carries id, version, reason (e.g. published|field_edit|status_change|baseline), actor (who caused it, when known), snapshotAt, contentHash, hashValid (re-verified on every read), restorable, fieldCount. With at, returns instead the single snapshot valid at that instant (full record plus validFrom/validUntil) — answers "what did this passport say on date D"; 404 before the first snapshot. Counts 1 against the daily read budget.
get_snapshot — args: { id, snapshotId }. Read-only. Returns the full archival record of one snapshot: the complete JSON-LD the passport asserted at that time, plus hash and hashValid. Counts 1 against the daily read budget.
get_condition_flags — args: { id }. Read-only. Returns the resolved condition profile Record<flagKey,{value,status,source}>. Condition flags are reviewer-approved yes/no facts gating conditional legal duties. Battery flags: hasBMS, rechargeable, externalStorageOnly, isStationaryBess. An approved flag makes specific fields required — a missing gated field is a hard publish block (conditional_missing). Counts 1 against the daily read budget.
get_condition_flags_by_serial — args: { serial, gtin? }. Read-only. Same as get_condition_flags, addressed by your own serial. 409 ambiguous_serial if serial not unique — pass gtin.
set_condition_flags — args: { id, flags: Record<flagKey, boolean|null> }. WRITE. Set or clear condition flags (null clears). Keys must be registered for the passport category (battery: hasBMS, rechargeable, externalStorageOnly, isStationaryBess). WARNING: approving a flag can make fields required and block publishing if those fields are empty — fix any gated fields before or immediately after setting the flag. Writes are approved + audited. Idempotency-Key supported. Counts 1 write.
set_condition_flags_by_serial — args: { serial, gtin?, flags }. WRITE. Same as set_condition_flags, addressed by your own serial. 409 ambiguous_serial if serial not unique — pass gtin.
capture_measurements — args: { id, measurements: [ { fieldKey, value, measuredAt (ISO 8601), externalId?, unit? } ] (≤500) }. WRITE, battery passports only, published only. Pushes over-life measurements from the customer's own equipment (e.g. a BMS reporting stateOfHealth, numberOfFullEquivalentChargingCycles; the Annex XIII point 4 use-data keys). Every measurement is stored; the newest per field becomes the passport's current value and sets dynamicDataAsOf. externalId makes a measurement idempotent. A value may be at most 16 KB serialised. batteryStatus is NOT a measurement (400 invalid_field_key). A key the Regulation keeps off this battery category returns 422 field_not_applicable (e.g. stateOfCertifiedEnergy on an LMT battery). Metered against the plan's monthly measurement allowance, not the daily write budget: paid plans keep counting past it at no charge; Free stops at its allowance. Reading a passport is never metered.
capture_measurements_by_serial — args: { serial, gtin?, measurements }. Same, addressed by your own serial.
list_measurements — args: { id, fieldKey?, from?, to? (ISO 8601), limit? (≤200), cursor? }. Read-only. Measurement history, newest first; page with the returned nextCursor.
list_measurements_by_serial — args: { serial, gtin?, fieldKey?, from?, to?, limit?, cursor? }. Read-only.
latest_measurements — args: { id }. Read-only. The newest measurement per accepted key (null where none yet).
latest_measurements_by_serial — args: { serial, gtin? }. Read-only.

Name	Required	Description	Default
`args`	No	Arguments for the chosen action; required fields depend on `action` (see each action above).
`action`	Yes	Which passport operation to run. Reads: list \| get \| get_by_serial \| compliance \| registry_readiness \| get_condition_flags \| get_condition_flags_by_serial \| get_qr \| get_qr_by_serial \| list_snapshots \| get_snapshot \| list_measurements(_by_serial) \| latest_measurements(_by_serial). Writes: set_condition_flags \| set_condition_flags_by_serial \| capture_measurements(_by_serial) \| create (a draft, not billed). Lifecycle: suspend (reversible) \| archive (IRREVERSIBLE; battery passports need `reason`), each with a _by_serial variant.

Output Schema

Name	Required	Description
`id`	No	The resource's TracePass id, when the response is a single entity.
`page`	No	Current page number (list actions).
`error`	No	Machine-readable error code, when the API rejected the request.
`items`	No	The page of results, when the action is a list.
`limit`	No	Page size (list actions).
`total`	No	Total matching records across all pages (list actions).
`result`	No	Wraps a non-object response body (e.g. a QR code string).
`message`	No	Human-readable error or status detail, when present.
`totalPages`	No	Total number of pages (list actions).

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: archive is irreversible and permanently 404s the QR, drafts take no plan slot and are never billed, slot/overage occurs at publish, creates consume a daily write budget, measurements are metered against a separate monthly allowance, writes are audited, Idempotency-Key and externalId dedupe are supported, and specific error codes (400/409/422) are named. None of this contradicts the annotations (write-capable, destructive, non-idempotent).

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

Conciseness4/5

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

Well-structured with a warnings block first, then identifier schemes, then an action-by-action list. Length is justified by 24 actions, but the identifier-scheme section substantially duplicates the schema's `identifier` description and the billing rules are restated in several places.

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?

For a 24-action polymorphic tool with nested args, the description supplies what the schema cannot: mutability semantics, billing/metering behavior, legal-basis notes, error taxonomy, and action-to-argument mapping. An output schema and annotations exist, so return shapes need not be explained.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: the five EN 18219 schemes with their per-scheme fields, the battery-only restriction, the doi granularity requirement, lineage triggers and immutability, and the 16 KB measurement value cap. Some of this restates the schema's own `identifier` and `flags` descriptions, which caps it below 5.

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?

Opens with a specific verb+resource ('Manage Digital Product Passports — create, read, and run lifecycle actions') and then enumerates all 24 actions with their arguments. The scope is clearly delimited from siblings like tracepass_passport_fields, tracepass_passport_parties, and tracepass_epcis, which cover different resources.

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?

Explicitly routes between alternatives: prefer `suspend` over `archive` when a change might be undone, use `registry_readiness` for the formal submission gate vs `compliance` for the substantive verdict, pass `gtin` when a serial is ambiguous or fall back to the by-id action. It also states when each lifecycle state applies (create makes an unbilled draft; publishing happens outside this tool).

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

tracepass_productsTracePass productsA

Destructive

Inspect

Manage the TracePass product catalogue. A product is the catalogue layer — one product can have many passports (one per serialised unit). Products are not billable on their own.

Actions (pass via action, with args):

list — args: { page?, limit? (≤100), category?, status?, search? }. Read-only.
get — args: { id }. Read-only.
create — args: { name, model, category, description? }. category is one of: battery, textile, electronics, construction, steel, detergents, paints-coatings, packaging, furniture, tyres, jewelry, toys, fmcg.
update — args: { id, name?, model?, description? }; pass at least one field to change.
create_batch — args: { products: [ { name, model, category, description? }, … ] }, up to 100. Partial-success: the response carries a per-item status, so some items can be created while others error. The whole batch consumes N writes upfront; if that would exceed the daily cap NOTHING is created (429).
archive — args: { id }. Soft-archive a product. Blocked with 409 while any non-archived passport still references it — archive those passports first. This is reversible and is NOT deletion.

Name	Required	Description	Default
`args`	No	Arguments for the chosen action; required fields depend on `action` (see each action above).
`action`	Yes	Which product operation to run: list \| get \| create \| create_batch \| update \| archive.

Output Schema

Name	Required	Description
`id`	No	The resource's TracePass id, when the response is a single entity.
`page`	No	Current page number (list actions).
`error`	No	Machine-readable error code, when the API rejected the request.
`items`	No	The page of results, when the action is a list.
`limit`	No	Page size (list actions).
`total`	No	Total matching records across all pages (list actions).
`result`	No	Wraps a non-object response body (e.g. a QR code string).
`message`	No	Human-readable error or status detail, when present.
`totalPages`	No	Total number of pages (list actions).

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses partial-success semantics for create_batch, that the whole batch consumes N writes upfront and returns 429 with nothing created if the daily cap would be exceeded, and that archive is a soft, reversible state change blocked by 409 while passports reference it. It also clarifies the product is not billable on its own, which is genuinely useful behavioural context.

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

Conciseness4/5

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

Front-loads the domain concept, then uses a scannable action-by-action bullet layout with zero filler sentences. Slight redundancy in restating the category enum already present in the schema keeps it from a 5.

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?

For a multi-action tool with nested args and an output schema, the description covers everything an agent needs before calling: which action to pass, what args each requires, safety profile of reads vs archive, and failure modes. Return shapes are left to the output schema, appropriately.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, and the description adds meaning the schema lacks — the 'pass at least one field to change' rule on update, the limit ≤100 constraint, and the per-action required-field map. The category enum is duplicated from the schema rather than extended.

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?

States the specific resource (TracePass product catalogue) and enumerates six concrete actions with their verbs, while explicitly distinguishing the catalogue layer from passports ('one product can have many passports'). An agent can tell this apart from tracepass_passports without opening either schema.

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

Usage Guidelines4/5

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

Gives per-action guidance: list/get marked read-only, update requires at least one changed field, create_batch capped at 100, and archive blocked with 409 while non-archived passports reference the product. It does not explicitly route the agent to a sibling (e.g. when to manage passports instead), so it falls short of full when/when-not coverage.

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

tracepass_scopeTracePass DPP scope checkerAInspect

Check what EU law says for a product type matching the facts given: whether it needs a Digital Product Passport, from when, at which level, under which act and article, and the duties of each role. Also read the company's catalogue-wide scope report and trigger a catalogue refresh run.

HARD RULES — always apply these to scope answers:

Answers state what the law says for product types matching the given facts. This is not legal advice; never write 'you must' — use product-type phrasing ('LMT batteries need a passport from 18 February 2027, Battery Regulation Art. 77(1)').
Cite the article the answer gives for every verdict and duty. A regulation without an article is not a citation. A not_covered answer rests on no article: say our rules do not cover the product and name the nearest act it gives, never cite that act as the basis.
A date with precision 'quarter', 'month' or 'year' is a plan, NEVER a deadline or a start date. Write 'planned for Q2 2027 (planned, not law yet)', never 'from', 'by' or 'deadline'.
Relay not_covered and needs_input as the results they are, never as errors. not_covered = the product falls outside these scope rules. needs_input = blocking questions remain unanswered — relay the questions in ask[] to the user before giving a verdict.
Items in an act's planned list are not law yet: always label them 'Planned, not law yet' (labelText), with their wording.
ruleStatus: 'needs_recheck' means the law behind an act changed and our rules for it are being re-checked (since recheckSince): say so with the answer.

Actions (pass via action, with args):

check — args: { category?, facts?, role?, placedOnMarket?, lifecycleEvent?, contains?, productId?, passportId?, locale? }. Ask whether a product type needs a DPP. Available on every plan, Free included. Counts against the per-company scope-answer cap (~100/day, 30/min burst), NOT the v1 read/write budget. 429 scope_answer_cap when the daily cap is spent. not_covered and needs_input are 200 results, not errors. category: one of battery | detergents | toys | construction | textile | steel | tyres | furniture | electronics | packaging | paints-coatings | jewelry | fmcg | vehicles | other. facts: namespace-prefixed keys from the loaded rules (e.g. battery.use, battery.capacityKWh). Unknown keys or wrong values return 400 invalid_input. role: your role in the act's terms: manufacturer | importer | distributor | authorised_representative | fulfilment_service_provider. Selling under your own name = manufacturer with facts.ownBrand: true. Omit to list every role's duties. placedOnMarket: { date: 'YYYY-MM-DD' | 'YYYY-MM' | 'YYYY', precision?: 'day'|'month'|'year' } or null. contains: array (≤5) of component queries — use to ask about a battery inside a toy: [ { label?, facts? } ]. locale: en | bg | de | it (default: from Accept-Language header, else en).
catalogue_report — args: { classification?, category?, act?, changed?, q?, cursor?, limit? (≤500) }. Read the catalogue-wide scope report (one row per product). Requires the Growth plan or above; 403 plan_upgrade_required below Growth — tell the user this needs a plan upgrade, do not retry. Counts 1 against the daily read budget per page. classification filter: missing | draft_only | published_incomplete | published | not_required | open_questions | not_covered. Response: { run, running, totals, items: [{ productId, passportIds, gtin, category, summary, classification, changedAt }], nextCursor, disclaimer }. Full answer for one product: call check with that productId.
catalogue_run — args: {}. Start a catalogue scope refresh run (also runs nightly). Returns 202 { runId, status }; poll with catalogue_run_status. Requires Growth plan. 409 run_in_progress if already active; 429 run_cooldown with retryAfter within 10 minutes of a finished run.
catalogue_run_status — args: { runId }. Get the status (queued | running | done | failed) and result counts for one catalogue run. Requires Growth plan.

Name	Required	Description	Default
`args`	No	Arguments for the chosen action; required fields depend on `action` (see above).
`action`	Yes	Which scope operation to run: check \| catalogue_report \| catalogue_run \| catalogue_run_status.

Output Schema

Name	Required	Description
`id`	No	The resource's TracePass id, when the response is a single entity.
`page`	No	Current page number (list actions).
`error`	No	Machine-readable error code, when the API rejected the request.
`items`	No	The page of results, when the action is a list.
`limit`	No	Page size (list actions).
`total`	No	Total matching records across all pages (list actions).
`result`	No	Wraps a non-object response body (e.g. a QR code string).
`message`	No	Human-readable error or status detail, when present.
`totalPages`	No	Total number of pages (list actions).

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only carry the generic write-capable profile (readOnlyHint/idempotentHint false), and the description goes well beyond them: quota mechanics (~100 scope answers/day, 30/min burst, 429 scope_answer_cap), plan gates, async semantics (202 + poll via catalogue_run_status), cooldown with retryAfter, and per-page read budget accounting. The 'write' profile is consistent with catalogue_run starting a run, so nothing contradicts the annotations.

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

Conciseness4/5

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

Front-loaded with the purpose, then organized under hard rules and an actions list, so it scans well. It is long, but the length is justified by four actions plus legal-output constraints; the hard-rules block is dense with non-obvious phrasing mandates rather than filler, with only minor redundancy between the intro and the check section.

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?

For a four-action tool with nested args and an output schema, the description covers what the output schema cannot: result-vs-error interpretation, citation and label rules, plan requirements, quotas, and the exact shape of catalogue_report items plus nextCursor. An agent has everything needed to select the right action and interpret each response.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: facts are namespace-prefixed rule keys where wrong values yield 400 invalid_input, role uses act terminology with ownBrand:true implying manufacturer, contains is capped at 5 and is the mechanism for asking about a battery inside a toy, and locale defaults from Accept-Language. It also documents the category enum and placedOnMarket precision semantics in task terms.

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 first sentence gives a concrete verb and resource: check what EU law says for a product type (DPP need, date, level, act/article, role duties), plus reading the catalogue scope report and triggering a refresh run. The four named actions make the scope of the tool enumerable. It is obviously distinct from the sibling CRUD tools (products, passports, epcis, templates) without needing to name them.

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 routing is given per action, including when NOT to proceed: check is on every plan, catalogue_report/catalogue_run require Growth plan and must not be retried on 403, and needs_input blocking questions must be relayed before a verdict. Error-vs-result semantics (not_covered/needs_input as 200 results, 409 run_in_progress, 429 cooldown) tell the agent exactly how to behave on each outcome.

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

tracepass_templatesTracePass DPP templates (regulatory schemas)A

Read-onlyIdempotent

Inspect

Discover the regulatory field schema for each DPP category — what a COMPLIANT passport must contain, per the governing EU regulation. Read-only reference data. Use this to advise on requirements before creating products/passports, and to gap-check a draft against the rules.

Actions (pass via action, with args):

list — args: {}. Lists all 13 categories with their field count, required-field count, and governing regulation (name + number + effective/mandatory dates).
get — args: { category }. Full field schema for one category: every field's key, label, dataType, whether it is REQUIRED, its access level (public/restricted/authority), enum options, validation bounds, and — where known — the regulation article/annex that mandates it. category is one of: battery, textile, electronics, construction, steel, detergents, paints-coatings, packaging, furniture, tyres, jewelry, toys, fmcg.

BATTERY — required-ness is per-category, so required alone is the wrong answer. Resolve it in this order:

SCOPE FIRST. Only EV, LMT and industrial_gt_2kwh batteries owe a passport at all (Art. 77(1), Reg (EU) 2023/1542). For portable, SLI or industrial_lte_2kwh, NO field is required — do not list mandatory fields for them; say the battery is out of scope.
Then requiredBy[batteryCategory] where the field carries that map (required | conditional | notApplicable).
Then fall back to required. The map is keyed ONLY by the three in-scope categories, so skipping step 1 falls through to required and invents an obligation the Regulation does not impose. Note also that EV and LMT report state-of-health through MUTUALLY EXCLUSIVE field sets — an EV battery must leave the remaining-capacity cluster empty and an LMT battery must leave stateOfCertifiedEnergy empty, so no single battery ever fills every field.

Name	Required	Description	Default
`args`	No	Arguments for the chosen action; `category` is required for get, ignored for list.
`action`	Yes	List all DPP category templates, or get one template by category.

Output Schema

Name	Required	Description
`id`	No	The resource's TracePass id, when the response is a single entity.
`page`	No	Current page number (list actions).
`error`	No	Machine-readable error code, when the API rejected the request.
`items`	No	The page of results, when the action is a list.
`limit`	No	Page size (list actions).
`total`	No	Total matching records across all pages (list actions).
`result`	No	Wraps a non-object response body (e.g. a QR code string).
`message`	No	Human-readable error or status detail, when present.
`totalPages`	No	Total number of pages (list actions).

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing load-bearing domain behavior: per-category required-ness, the Art. 77(1) scope gate that makes portable/SLI/low-capacity industrial batteries out-of-scope, and the mutually exclusive EV vs LMT state-of-health field sets. It also warns that skipping the scope step 'invents an obligation the Regulation does not impose' — exactly the kind of failure mode an agent needs.

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

Conciseness4/5

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

Front-loaded with purpose, then action/args blocks, then the critical battery caveat — a sensible order. The length is largely justified by genuinely tricky battery semantics, though a few clauses overlap with what the annotations and schema already state.

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?

With an output schema present, return-value detail is not required, and the annotations already carry the safety profile. The description nonetheless supplies the domain-specific rules (scope gating, per-category required logic, mutually exclusive field clusters) that no structured field covers, making it fully sufficient for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents action and category, giving a baseline of 3. The description earns above baseline by enumerating the 13 category values, spelling out which args each action takes, and describing what each returns (field counts, required counts, governing regulation).

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?

States a specific verb and resource — 'Discover the regulatory field schema for each DPP category' — and immediately scopes it as read-only reference data describing what a compliant passport must contain. This clearly separates it from mutation-oriented siblings like tracepass_products and tracepass_passports.

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?

Explicitly gives when-to-use: 'advise on requirements before creating products/passports' and 'gap-check a draft against the rules', routing the agent here as a pre-flight reference rather than to the product/passport tools. The battery section further prescribes a concrete resolution order (scope first, then requiredBy, then required).

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 23, 2026

Changedtracepass_passports2 fields changed

changedInput schema / properties / action / description

Previous value: -"Which passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_condition_flags | get_condition_flags_by_serial | get_qr | get_qr_by_serial | list_snapshots | get_snapshot | list_measurements(_by_serial) | latest_measurements(_by_serial). Writes: set_condition_flags | set_condition_flags_by_serial | capture_measurements(_by_serial) | create (BILLABLE). Lifecycle: suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."New value: +"Which passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_condition_flags | get_condition_flags_by_serial | get_qr | get_qr_by_serial | list_snapshots | get_snapshot | list_measurements(_by_serial) | latest_measurements(_by_serial). Writes: set_condition_flags | set_condition_flags_by_serial | capture_measurements(_by_serial) | create (a draft, not billed). Lifecycle: suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."

removedInput schema / properties / args / properties / confirmOverage

Removed value: -{
-  "description": "Set true to accept per-passport overage charges when over the plan quota (402). Applies to create.",
-  "type": "boolean"
-}

7 tool updatesOct 11, 2026
- Changedtracepass_epcis4 fields changed
  - addedOutput schema / properties / error / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / error / type
```
Removed value: -"string"
```
  - addedOutput schema / properties / message / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / message / type
```
Removed value: -"string"
```
- Changedtracepass_passport_fields4 fields changed
  - addedOutput schema / properties / error / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / error / type
```
Removed value: -"string"
```
  - addedOutput schema / properties / message / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / message / type
```
Removed value: -"string"
```
- Changedtracepass_passport_parties4 fields changed
  - addedOutput schema / properties / error / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / error / type
```
Removed value: -"string"
```
  - addedOutput schema / properties / message / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / message / type
```
Removed value: -"string"
```
- Changedtracepass_passports4 fields changed
  - addedOutput schema / properties / error / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / error / type
```
Removed value: -"string"
```
  - addedOutput schema / properties / message / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / message / type
```
Removed value: -"string"
```
- Changedtracepass_products4 fields changed
  - addedOutput schema / properties / error / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / error / type
```
Removed value: -"string"
```
  - addedOutput schema / properties / message / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / message / type
```
Removed value: -"string"
```
- Addedtracepass_scope
- Changedtracepass_templates4 fields changed
  - addedOutput schema / properties / error / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / error / type
```
Removed value: -"string"
```
  - addedOutput schema / properties / message / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - removedOutput schema / properties / message / type
```
Removed value: -"string"
```

1 tool updateOct 5, 2026

Changedtracepass_passport_fields1 field changed

addedInput schema / properties / args / properties / source

Added value: +{
+  "description": "Where the value came from: \"manual\" (default — the user's statement) or \"ai_suggested\" (you found it; it goes to human review).",
+  "enum": [
+    "manual",
+    "ai_suggested"
+  ],
+  "type": "string"
+}

1 tool updateOct 1, 2026

Changedtracepass_passports7 fields changed

changedInput schema / properties / action / description

Previous value: -"Which passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_condition_flags | get_condition_flags_by_serial | get_qr | get_qr_by_serial | list_snapshots | get_snapshot. Writes: set_condition_flags | set_condition_flags_by_serial | create (BILLABLE). Lifecycle: suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."New value: +"Which passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_condition_flags | get_condition_flags_by_serial | get_qr | get_qr_by_serial | list_snapshots | get_snapshot | list_measurements(_by_serial) | latest_measurements(_by_serial). Writes: set_condition_flags | set_condition_flags_by_serial | capture_measurements(_by_serial) | create (BILLABLE). Lifecycle: suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."

changedInput schema / properties / action / enum

Previous value: -[
-  "list",
-  "get",
-  "get_by_serial",
-  "compliance",
-  "registry_readiness",
-  "get_condition_flags",
-  "get_condition_flags_by_serial",
-  "set_condition_flags",
-  "set_condition_flags_by_serial",
-  "create",
-  "suspend",
-  "suspend_by_serial",
-  "archive",
-  "archive_by_serial",
-  "get_qr",
-  "get_qr_by_serial",
-  "list_snapshots",
-  "get_snapshot"
-]New value: +[
+  "list",
+  "get",
+  "get_by_serial",
+  "compliance",
+  "registry_readiness",
+  "get_condition_flags",
+  "get_condition_flags_by_serial",
+  "set_condition_flags",
+  "set_condition_flags_by_serial",
+  "capture_measurements",
+  "capture_measurements_by_serial",
+  "list_measurements",
+  "list_measurements_by_serial",
+  "latest_measurements",
+  "latest_measurements_by_serial",
+  "create",
+  "suspend",
+  "suspend_by_serial",
+  "archive",
+  "archive_by_serial",
+  "get_qr",
+  "get_qr_by_serial",
+  "list_snapshots",
+  "get_snapshot"
+]

addedInput schema / properties / args / properties / cursor

Added value: +{
+  "description": "list_measurements(_by_serial): nextCursor from the previous page.",
+  "type": "string"
+}

addedInput schema / properties / args / properties / fieldKey

Added value: +{
+  "description": "list_measurements(_by_serial): only this field key.",
+  "type": "string"
+}

addedInput schema / properties / args / properties / from

Added value: +{
+  "description": "list_measurements(_by_serial): measuredAt from (ISO 8601).",
+  "type": "string"
+}

addedInput schema / properties / args / properties / measurements

Added value: +{
+  "description": "capture_measurements(_by_serial): [{ fieldKey, value, measuredAt, externalId?, unit? }], max 500.",
+  "items": {
+    "properties": {
+      "externalId": {
+        "type": "string"
+      },
+      "fieldKey": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "measuredAt": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "unit": {
+        "type": "string"
+      },
+      "value": {}
+    },
+    "required": [
+      "fieldKey",
+      "value",
+      "measuredAt"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedInput schema / properties / args / properties / to

Added value: +{
+  "description": "list_measurements(_by_serial): measuredAt to (ISO 8601).",
+  "type": "string"
+}

1 tool updateOct 1, 2026

Changedtracepass_passports1 field changed

addedInput schema / properties / args / properties / lineage

Added value: +{
+  "description": "create, battery only: link a second-life battery's new passport to the original passport(s) (Art. 77(7)). See the create action.",
+  "properties": {
+    "noPredecessorReason": {
+      "maxLength": 500,
+      "type": "string"
+    },
+    "predecessors": {
+      "items": {
+        "properties": {
+          "identifier": {
+            "maxLength": 2000,
+            "type": "string"
+          },
+          "internalPassportId": {
+            "type": "string"
+          },
+          "trigger": {
+            "enum": [
+              "preparation_for_reuse",
+              "preparation_for_repurposing",
+              "repurposing",
+              "remanufacturing"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "trigger"
+        ],
+        "type": "object"
+      },
+      "maxItems": 10,
+      "type": "array"
+    }
+  },
+  "required": [
+    "predecessors"
+  ],
+  "type": "object"
+}

1 tool updateSep 29, 2026

Changedtracepass_passports2 fields changed

addedInput schema / properties / args / properties / at

Added value: +{
+  "description": "list_snapshots: ISO 8601 instant — return the snapshot valid then instead of the list.",
+  "type": "string"
+}

addedInput schema / properties / args / properties / symbology

Added value: +{
+  "description": "get_qr/get_qr_by_serial: qr (default) | datamatrix.",
+  "type": "string"
+}

1 tool updateSep 29, 2026

Changedtracepass_passports3 fields changed

changedInput schema / properties / action / description

Previous value: -"Which passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_qr | get_qr_by_serial | list_snapshots | get_snapshot. Writes (BILLABLE): create. Lifecycle: suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."New value: +"Which passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_condition_flags | get_condition_flags_by_serial | get_qr | get_qr_by_serial | list_snapshots | get_snapshot. Writes: set_condition_flags | set_condition_flags_by_serial | create (BILLABLE). Lifecycle: suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."

changedInput schema / properties / action / enum

Previous value: -[
-  "list",
-  "get",
-  "get_by_serial",
-  "compliance",
-  "registry_readiness",
-  "create",
-  "suspend",
-  "suspend_by_serial",
-  "archive",
-  "archive_by_serial",
-  "get_qr",
-  "get_qr_by_serial",
-  "list_snapshots",
-  "get_snapshot"
-]New value: +[
+  "list",
+  "get",
+  "get_by_serial",
+  "compliance",
+  "registry_readiness",
+  "get_condition_flags",
+  "get_condition_flags_by_serial",
+  "set_condition_flags",
+  "set_condition_flags_by_serial",
+  "create",
+  "suspend",
+  "suspend_by_serial",
+  "archive",
+  "archive_by_serial",
+  "get_qr",
+  "get_qr_by_serial",
+  "list_snapshots",
+  "get_snapshot"
+]

addedInput schema / properties / args / properties / flags

Added value: +{
+  "additionalProperties": {
+    "anyOf": [
+      {
+        "type": "boolean"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "description": "For set_condition_flags / set_condition_flags_by_serial: Record<flagKey, boolean|null>. null clears the flag.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

1 tool updateSep 28, 2026

Changedtracepass_passports3 fields changed

changedInput schema / properties / action / description

Previous value: -"Which passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_qr | get_qr_by_serial. Writes (BILLABLE): create. Lifecycle: suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."New value: +"Which passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_qr | get_qr_by_serial | list_snapshots | get_snapshot. Writes (BILLABLE): create. Lifecycle: suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."

changedInput schema / properties / action / enum

Previous value: -[
-  "list",
-  "get",
-  "get_by_serial",
-  "compliance",
-  "registry_readiness",
-  "create",
-  "suspend",
-  "suspend_by_serial",
-  "archive",
-  "archive_by_serial",
-  "get_qr",
-  "get_qr_by_serial"
-]New value: +[
+  "list",
+  "get",
+  "get_by_serial",
+  "compliance",
+  "registry_readiness",
+  "create",
+  "suspend",
+  "suspend_by_serial",
+  "archive",
+  "archive_by_serial",
+  "get_qr",
+  "get_qr_by_serial",
+  "list_snapshots",
+  "get_snapshot"
+]

addedInput schema / properties / args / properties / snapshotId

Added value: +{
+  "description": "Snapshot id. Required for get_snapshot.",
+  "type": "string"
+}

2 tool updatesSep 28, 2026

Changedtracepass_passport_parties6 fields changed

changedInput schema / properties / args / properties / country / description

Previous value: -"Party country code (set, optional)."New value: +"ISO 3166-1 alpha-2 country code (set, optional)."

addedInput schema / properties / args / properties / facilityIdentifier

Added value: +{
+  "additionalProperties": {},
+  "description": "Structured facility identifier per EN 18219 §6.2–6.5. Same four schemes as operatorIdentifier; the gln variant also accepts optional `extension` (GS1 SGLN sub-location). Never fills the top-level gln field. Not set by AI extraction.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

changedInput schema / properties / args / properties / gln / description

Previous value: -"GS1 Global Location Number for the party (set, optional)."New value: +"GS1 Global Location Number (13 digits). Strongly recommended for multi-role disambiguation."

changedInput schema / properties / args / properties / legacyOperatorId / description

Previous value: -"Your internal operator id for the party (set, optional)."New value: +"Free-text fallback identifier (VAT, EORI, supplier code). Required when gln and operatorIdentifier are both absent."

addedInput schema / properties / args / properties / operatorIdentifier

Added value: +{
+  "additionalProperties": {},
+  "description": "Structured operator identifier per EN 18219 §6.2–6.5. Must have `scheme` plus scheme fields. Schemes: iso6523 {icd:\"<4 digits>\", value} | gln {gln:\"<13 digits>\"} | did {did:\"did:<method>:<id>\"} | doi {doi:\"10.<registrant>/<suffix>\"}. scheme gln also fills the top-level gln field; they must match if both are set (400 otherwise). Not set by AI extraction.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

changedInput schema / properties / args / properties / role / description

Previous value: -"Economic-operator role, e.g. manufacturer | importer | distributor | authorised_representative (required)."New value: +"Economic-operator role: manufacturer | importer | authorisedRepresentative | distributor | recycler | producerResponsibilityOrg (required)."

Changedtracepass_passports1 field changed

changedInput schema / properties / args / properties / identifier / description

Previous value: -"EN 18219 scheme-tagged identifier for create. Must have `scheme` plus scheme-specific fields. Schemes: gs1 {gtin, serialNumber} | iso15459 {issuingAgencyCode, primaryId, serial?} | iec61406 {uri} | did {did, method} | doi {doi}. Battery passports: gs1 and iso15459 only."New value: +"EN 18219 scheme-tagged identifier for create. Must have `scheme` plus scheme-specific fields. Schemes: gs1 {gtin, serialNumber} | iso15459 {issuingAgencyCode, primaryId, serial?} | iec61406 {uri} | did {did, method} | doi {doi, granularity} (granularity: \"model\"|\"batch\"|\"item\" REQUIRED per EN 18219 §5.6.2(b)). Battery passports: gs1 and iso15459 only."

1 tool updateSep 28, 2026

Changedtracepass_passports6 fields changed

changedInput schema / properties / action / description

Previous value: -"Which 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."New value: +"Which passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_qr | get_qr_by_serial. Writes (BILLABLE): create. Lifecycle: suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."

changedInput schema / properties / args / properties / confirmOverage / description

Previous value: -"Set true to accept a per-passport overage charge when create is over the plan quota (402)."New value: +"Set true to accept per-passport overage charges when over the plan quota (402). Applies to create."

changedInput schema / properties / args / properties / gtin / description

Previous value: -"GTIN disambiguator for *_by_serial actions when a serial isn't unique across GTINs (else 409 ambiguous_serial)."New value: +"For create (legacy): GS1 GTIN. Also used as a disambiguator for *_by_serial actions when a serial isn't unique (else 409 ambiguous_serial)."

changedInput schema / properties / args / properties / id / description

Previous value: -"Passport id. Required for get/compliance/create-result/suspend/archive/get_qr (the by-id actions)."New value: +"Passport id. Required for get/compliance/suspend/archive/get_qr (the by-id actions)."

addedInput schema / properties / args / properties / identifier

Added value: +{
+  "additionalProperties": {},
+  "description": "EN 18219 scheme-tagged identifier for create. Must have `scheme` plus scheme-specific fields. Schemes: gs1 {gtin, serialNumber} | iso15459 {issuingAgencyCode, primaryId, serial?} | iec61406 {uri} | did {did, method} | doi {doi}. Battery passports: gs1 and iso15459 only.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

changedInput schema / properties / args / properties / serialNumber / description

Previous value: -"Serial for the new passport. Required for create."New value: +"Serial for the new passport (create, legacy gs1 path)."

Related MCP Connectors

Cycle Intelligence A
com.cycle-platform
EU Digital Product Passport (DPP/ESPR) requirements, product readiness scoring and GS1 validation.
Legal & Compliance Data Platforms
61
https://edge.cycle-platform.com/v1/mcp
PassportCraft — EU Digital Product PassportsOAuth
com.passportcraft
Create & manage EU Digital Product Passports with PassportCraft: textiles, batteries, general goods.
Legal & Compliance E-commerce & Retail
1
https://passportcraft.com/api/mcp
Aeroz A
io.aeroz
Prove a physical item is genuine (NFC chip); read its EU Digital Product Passport, recalls, custody.
E-commerce & Retail Security Legal & Compliance
431
https://api.aeroz.io/mcp
CRPOAuth
io.github.z3green
Carbon accounting platform. Query emission factors and create or edit draft emissions.
Energy
1
https://app.crp.eco/api/mcp

Related MCP Servers

Trust Chain MCP
Security Legal & Compliance
CSOAI-ORG
A
license
B
quality
B
maintenance
Manages trust chains and attestations with built-in EU AI Act compliance.
Updated 21 days ago (2026-10-08 04:35 UTC)
5
3 npm
40 PyPI
MIT
product-crud-mcp
Databases Developer Tools
saurabhx04
F
license
Not graded
quality
D
maintenance
Exposes CRUD operations for products via MCP tools and a resource, sharing a common business logic layer with a GraphQL API.
Updated 3 months ago (2026-08-01 03:12 UTC)
-
Sharebox MCP Server
Legal & Compliance Project Management
dalvivishal
F
license
Not graded
quality
C
maintenance
Enables AI clients to manage projects, cases, and file uploads while maintaining an immutable audit trail for all write operations.
Updated a month ago (2026-09-15 08:10 UTC)
-
Open Food Facts MCP
Open Data Health & Wellness
MrBridgeHQ
A
license
B
quality
B
maintenance
Enables MCP clients to look up products by barcode, search products and text, retrieve taxonomy suggestions, and compare nutrition data through read-only tools.
Updated 16 days ago (2026-10-13 16:26 UTC)
5
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources