Skip to main content
Glama

TracePass

by eu.tracepass
OverviewDiscussionsAdmin

TracePass DPP scope checker

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_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

NameRequiredDescriptionDefault
argsNoArguments for the chosen action; required fields depend on `action` (see above).
actionYesWhich scope operation to run: check | catalogue_report | catalogue_run | catalogue_run_status.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

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.

All TracePass toolsInspect
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.

Resources