tracepass-mcp-server

TracePass DPP templates (regulatory schemas)

tracepass_templates

Read-onlyIdempotent

Discover regulatory field schemas for DPP categories, list all categories or fetch one category's required fields to advise on compliance and gap-check draft passports.

Instructions

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). 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.
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.

Input Schema

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).

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.23.2Oct 31, 2026

removedOutput schema / properties / error / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / error / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / message / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / message / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Changed4 schema fields changedv1.19.1Oct 14, 2026
- 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"
```

Changed1 schema field changedv1.8.0Sep 28, 2026

changedInput schema / properties / args / properties / category / description

Previous value: -"DPP category to fetch (required for get): battery | textile | electronics | construction | steel | chemicals | packaging | furniture | tyres | jewelry | toys | fmcg."New value: +"DPP category to fetch (required for get): battery | textile | electronics | construction | steel | detergents | paints-coatings | packaging | furniture | tyres | jewelry | toys | fmcg."

Changed6 schema fields changedv1.7.3Aug 7, 2026

addedInput schema / properties / action / description

Added value: +"List all DPP category templates, or get one template by category."

removedInput schema / properties / args / additionalProperties
```
Removed value: -{}
```

changedInput schema / properties / args / description

Previous value: -"Action-specific arguments — see the description for each action's shape."New value: +"Arguments for the chosen action; `category` is required for get, ignored for list."

addedInput schema / properties / args / properties

Added value: +{
+  "category": {
+    "description": "DPP category to fetch (required for get): battery | textile | electronics | construction | steel | chemicals | packaging | furniture | tyres | jewelry | toys | fmcg.",
+    "type": "string"
+  }
+}

removedInput schema / properties / args / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "error": {
+      "description": "Machine-readable error code, when the API rejected the request.",
+      "type": "string"
+    },
+    "id": {
+      "description": "The resource's TracePass id, when the response is a single entity.",
+      "type": "string"
+    },
+    "items": {
+      "description": "The page of results, when the action is a list.",
+      "items": {},
+      "type": "array"
+    },
+    "limit": {
+      "description": "Page size (list actions).",
+      "type": "number"
+    },
+    "message": {
+      "description": "Human-readable error or status detail, when present.",
+      "type": "string"
+    },
+    "page": {
+      "description": "Current page number (list actions).",
+      "type": "number"
+    },
+    "result": {
+      "description": "Wraps a non-object response body (e.g. a QR code string)."
+    },
+    "total": {
+      "description": "Total matching records across all pages (list actions).",
+      "type": "number"
+    },
+    "totalPages": {
+      "description": "Total number of pages (list actions).",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

First observedv1.1.4Jun 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, yet the description goes far beyond them: it discloses that required-ness is scoped by battery category, that out-of-scope chemistries owe no fields, the precedence order (scope → requiredBy → required), that Annex XIII use data never blocks publishing, and that EV/LMT health fields are mutually exclusive. It even flags the specific failure mode ('skipping step 1 ... invents an obligation').

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 a one-line purpose, then a tight bulleted action list before the deep-dive. The BATTERY block is long and dense, but every sentence prevents a concrete error (false obligations, contradictory field sets), so the length is largely earned rather than padded.

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?

An output schema exists and the description still summarizes return shapes; for a two-parameter, read-only reference tool with nested return objects this is fully sufficient. The domain traps an agent would otherwise hit (out-of-scope batteries, conditional fields, mutually exclusive clusters) are all pre-empted.

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: it specifies that `args` is empty for list and ignored-for-list/required-for-get for category, and enumerates what each action returns (field count, required count, regulation, dataType, access level, enum options, validation bounds, article/annex). That is more than the schema supplies, though `category` itself is not expanded beyond the enum list.

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+resource ('Discover the regulatory field schema for each DPP category') and enumerates both actions with their arguments, so an agent can distinguish this reference-lookup tool from siblings like tracepass_passport_fields. The 'what a COMPLIANT passport must contain, per the governing EU regulation' clause pins the scope precisely.

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 clear use contexts: 'advise on requirements before creating products/passports' and 'gap-check a draft against the rules.' It does not name a sibling alternative or state when not to use it (e.g., versus tracepass_passport_fields for an actual passport's values), so it falls short of a 5.

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

Deploy Server