TracePass

eu.tracepass/tracepassVersion 1.25.2

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

Status

Responds24 msNov 14, 2026, 14:31 UTCAnswered our handshake without sign-in.

Registry data may be out of date

We could not refresh it, so this page shows the last copy.

Last checked: Nov 14, 2026, 14:31 UTC
Latency: 24 ms
Remotes responding: 1 of 1
Sign-in: API key
Hosting: EU hosting detected (detected, not a legal statement)
Registry data as of: Nov 14, 2026, 22:14 UTC

Data from the official MCP Registry, checked by run.zero. How we check

Connect

Streamable HTTP

https://ai.tracepass.eu/mcpResponds24 msNov 14, 2026, 14:31 UTC

No sign-in

Claude Code

claude mcp add --transport http tracepass https://ai.tracepass.eu/mcp --header 'Authorization: Bearer <YOUR_TOKEN>'

Replace <YOUR_TOKEN> before running.

Claude Desktop and claude.ai

Settings > Connectors > Add custom connector
Name: tracepass
Remote MCP server URL: https://ai.tracepass.eu/mcp
This server expects the header Authorization.

Cursor

{
  "mcpServers": {
    "tracepass": {
      "url": "https://ai.tracepass.eu/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_TOKEN>"
      }
    }
  }
}

Replace <YOUR_TOKEN> before running.

VS Code

code --add-mcp '{"name":"tracepass","type":"http","url":"https://ai.tracepass.eu/mcp","headers":{"Authorization":"Bearer <YOUR_TOKEN>"}}'

Replace <YOUR_TOKEN> before running.

Streamable HTTP

npm: tracepass-mcp-server 1.25.2

Package only

npm (npx)

claude mcp add tracepass -- npx -y tracepass-mcp-server@1.25.2

Built your own server? run.zero hosts MCP servers on European infrastructure.

Host your own MCP server on run.zero

Tools

8 tools

Tools of TracePass
	Description		Read-only	Idempotent	Open world
`tracepass_epcis`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.	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.	No	No	No	No
`tracepass_passport_fields`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.	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.	Yes	No	Yes	No
`tracepass_passport_lifecycle`WARNING: Every action here changes what the public sees or is a legal act, some irreversible. `archive` permanently removes the public QR code (it 404s forever). `record_registration` records the economic operator's registration in the production EU DPP Registry and locks the passport's operator and facility identifiers. `place_on_market` submits a registration to an EN 18222 registry API. The assistant MUST confirm with the user before each call. Use `suspend` (reversible — public QR shows 'suspended') as the safe alternative to archive when a change might need to be undone; a passport placed on the market cannot be suspended, because it must stay public. EU DPP REGISTRY: the economic operator registers a battery passport itself, on the EU DPP Registry website under its own EU Login. TracePass prepares what the operator submits (prepare_registry_upi / prepare_registry_upload_file in tracepass_passports) and records what the operator reports; it never submits to the Registry and never verifies the registration. The Registry's acceptance environment is for testing and has no legal effect (record_acceptance_test in tracepass_passports); only a registration in the production environment counts, and that is what record_registration records. The EU DPP Registry does not accept registrations through place_on_market. record_registration and undo_registration need a paid plan, and a connected app (OAuth) must act for an admin or owner. Actions (pass via `action`, with `args`): - record_registration — args: { id, placedOnMarketAt? (YYYY-MM-DD), registrationId? (≤200 chars) }. WRITE, battery passports only, published only. Records that the operator has registered this passport in the PRODUCTION EU DPP Registry, as the operator states it: TracePass does not check it with the Registry. Confirm with the user first, and only after the operator has registered on the Registry website. Effects: the passport is marked placed on the market (placeOnMarketStatus "placed", registration	WARNING: Every action here changes what the public sees or is a legal act, some irreversible. `archive` permanently removes the public QR code (it 404s forever). `record_registration` records the economic operator's registration in the production EU DPP Registry and locks the passport's operator and facility identifiers. `place_on_market` submits a registration to an EN 18222 registry API. The assistant MUST confirm with the user before each call. Use `suspend` (reversible — public QR shows 'suspended') as the safe alternative to archive when a change might need to be undone; a passport placed on the market cannot be suspended, because it must stay public. EU DPP REGISTRY: the economic operator registers a battery passport itself, on the EU DPP Registry website under its own EU Login. TracePass prepares what the operator submits (prepare_registry_upi / prepare_registry_upload_file in tracepass_passports) and records what the operator reports; it never submits to the Registry and never verifies the registration. The Registry's acceptance environment is for testing and has no legal effect (record_acceptance_test in tracepass_passports); only a registration in the production environment counts, and that is what record_registration records. The EU DPP Registry does not accept registrations through place_on_market. record_registration and undo_registration need a paid plan, and a connected app (OAuth) must act for an admin or owner. Actions (pass via `action`, with `args`): - record_registration — args: { id, placedOnMarketAt? (YYYY-MM-DD), registrationId? (≤200 chars) }. WRITE, battery passports only, published only. Records that the operator has registered this passport in the PRODUCTION EU DPP Registry, as the operator states it: TracePass does not check it with the Registry. Confirm with the user first, and only after the operator has registered on the Registry website. Effects: the passport is marked placed on the market (placeOnMarketStatus "placed", registration	Yes	No	No	No
`tracepass_passport_parties`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:<method>:<id>" } — syntax-checked only (EN 18219 §6.4.2(b)). • doi — { scheme:"doi", doi:"10.<registrant>/<suffix>" } — 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. Once a battery passport is placed on the market, a change to a stored operatorIdentifier or facilityIdentifier returns 409 operator_locked; other party edits stay allowed. To correct a locked identifier, the passport is marked for deletion and a new one created.	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:<method>:<id>" } — syntax-checked only (EN 18219 §6.4.2(b)). • doi — { scheme:"doi", doi:"10.<registrant>/<suffix>" } — 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. Once a battery passport is placed on the market, a change to a stored operatorIdentifier or facilityIdentifier returns 409 operator_locked; other party edits stay allowed. To correct a locked identifier, the passport is marked for deletion and a new one created.	Yes	No	Yes	No
`tracepass_passports`Manage Digital Product Passports — create, read, and run compliance checks. 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, suspend and place on market are in tracepass_passport_lifecycle. EU DPP REGISTRY (battery passports): the economic operator registers a passport itself, on the EU DPP Registry website under its own EU Login. TracePass prepares what the operator submits (prepare_registry_upi, prepare_registry_upload_file) and records what the operator reports back; it never submits to the Registry and never verifies the outcome. The Registry has two environments: acceptance (for testing, no legal effect) and production (the registration that counts). An acceptance result is recorded here (record_acceptance_test); a production registration is recorded with record_registration in tracepass_passport_lifecycle. These actions need a paid plan, and a connected app (OAuth) must act for an admin or owner. 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.<registrant>/<suffix> (any https://doi.org/ or doi: prefix stripped on input; resolves as https://do	Manage Digital Product Passports — create, read, and run compliance checks. 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, suspend and place on market are in tracepass_passport_lifecycle. EU DPP REGISTRY (battery passports): the economic operator registers a passport itself, on the EU DPP Registry website under its own EU Login. TracePass prepares what the operator submits (prepare_registry_upi, prepare_registry_upload_file) and records what the operator reports back; it never submits to the Registry and never verifies the outcome. The Registry has two environments: acceptance (for testing, no legal effect) and production (the registration that counts). An acceptance result is recorded here (record_acceptance_test); a production registration is recorded with record_registration in tracepass_passport_lifecycle. These actions need a paid plan, and a connected app (OAuth) must act for an admin or owner. 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.<registrant>/<suffix> (any https://doi.org/ or doi: prefix stripped on input; resolves as https://do	Yes	No	No	No
`tracepass_products`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 is in tracepass_passport_lifecycle.	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 is in tracepass_passport_lifecycle.	Yes	No	No	No
`tracepass_scope`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_cover	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_cover	No	No	No	No
`tracepass_templates`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: 1. 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. 2. Then `requiredBy[batteryCategory]` where the field carries that map (required \| conditional \| notApplicable). `conditional` means owed only when a fact holds (a commercial warranty offered, a BMS present, the battery in service); an approved condition flag can make it required. Annex XIII 4(d) use data (charging cycles, negative events, temperature history, state of charge) is expected once the battery is in service and never blocks publishing. 3. 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	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: 1. 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. 2. Then `requiredBy[batteryCategory]` where the field carries that map (required \| conditional \| notApplicable). `conditional` means owed only when a fact holds (a commercial warranty offered, a BMS present, the battery in service); an approved condition flag can make it required. Annex XIII 4(d) use data (charging cycles, negative events, temperature history, state of charge) is expected once the battery is in service and never blocks publishing. 3. 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	No	Yes	Yes	No

Details

Registry status: Active
Published: Nov 9, 2026
Updated: Nov 9, 2026
Website: https://www.tracepass.eu/⁠ (opens in a new tab)
Repository: https://github.com/malinoto/tracepass-mcp-server⁠ (opens in a new tab)
Categories: Uncategorized
GDPR: Not declared

Are you the operator? Claim this listing