tracepass-mcp-server

TracePass DPP scope checker

tracepass_scope

Check whether a product type needs an EU Digital Product Passport, which act and article apply, and each role's duties; read catalogue scope reports and start refresh runs.

Instructions

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.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv1.23.2Oct 31, 2026
- removedInput schema / properties / args / properties / lifecycleEvent / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / args / properties / lifecycleEvent / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedInput schema / properties / args / properties / passportId / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / args / properties / passportId / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedInput schema / properties / args / properties / productId / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / args / properties / productId / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- 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"
+]
```
Addedv1.19.1Oct 14, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well past the annotations with operational detail an agent cannot infer: per-company cap (~100/day, 30/min burst, 429 scope_answer_cap), that scope answers do NOT draw on the v1 read/write budget, 202 + polling for catalogue_run, 409 run_in_progress, 429 run_cooldown with retryAfter inside 10 minutes, and that not_covered/needs_input are 200 results rather than errors. It also explains the semantics of ruleStatus 'needs_recheck' and the 'planned' list, which are domain behaviours, not schema facts. Nothing here contradicts the annotations (readOnlyHint=false is consistent with catalogue_run starting a run).

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

Conciseness3/5

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

Purpose is front-loaded and the HARD RULES are operationally necessary, but the text is long and repeats itself: 'not_covered and needs_input are 200 results, not errors' appears in the rules and again under check, and 'Requires Growth plan' is restated for three separate actions. Trimming that duplication would lose no information.

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?

Although an output schema exists, the description still sketches the catalogue_report payload ({ run, running, totals, items, nextCursor, disclaimer }) and covers the parts an agent could otherwise get wrong: plan gating, error codes, polling flow, and how to phrase legal verdicts. For a four-action dispatcher with nested args this is complete.

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

Parameters5/5

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

Schema coverage is 100%, so 3 is the floor, but the description adds real meaning: the full category enum, that facts keys are namespace-prefixed ('battery.use', 'battery.capacityKWh') and that unknown keys or wrong values yield 400 invalid_input, that ownBrand:true maps to manufacturer, and that placedOnMarket precision changes whether a date is a plan or a deadline. It also documents the 5-item cap on contains and the meaning of limit ≤500.

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 opening sentence names a specific verb and resource ('check what EU law says for a product type… whether it needs a Digital Product Passport') and the Actions block enumerates all four operations (check, catalogue_report, catalogue_run, catalogue_run_status), so the multi-action surface is unambiguous. It never references the sibling tools (tracepass_passports, tracepass_products, tracepass_epcis), so an agent gets no explicit help separating this from them.

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?

Each action carries routing context: 'Full answer for one product: call check with that productId', 'poll with catalogue_run_status', and plan thresholds ('Requires the Growth plan or above; 403 plan_upgrade_required below Growth — tell the user this needs a plan upgrade, do not retry'). What is missing is guidance relative to the sibling tools — nothing says when to use tracepass_scope versus tracepass_passports for the same underlying data.

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

Deploy Server