Skip to main content
Glama
Sign In

TracePass DPP Compliance Assistant

by eu.tracepass
OverviewDiscussionsAdmin

Check if a product needs a passport

scope_check
Read-onlyIdempotent

Checks whether EU law requires a Digital Product Passport for a type of product, from when, and what the law requires of each role. Use it for "do I need a passport", "from when", "who is responsible", whether that responsibility can be handed to another company, who keeps and stores the passport and whether it must stay available after the company ceases, whether there is one passport per item, batch or model, and for repurposing, remanufacturing, waste or a battery inside another product. Pass whatever facts the user gave; if the result is needs_input, ask the user its questions in plain words and call again. The result's data.inScope is one of: yes, no, pending, depends. Use only what this tool returns: add no facts, dates or articles of your own, not even today's date. Keep every citation and the disclaimer line, and any "Planned, not law yet" or "being re-checked" label. Phrase answers about the product type, never as personal duties ("you must"). Never rank or recommend vendors. Never call this advice or yourself a consultant. If the result is not_covered, say so and point to the article given.

Input Schema

NameRequiredDescriptionDefault
roleNoThe user's role in plain words, e.g. "maker", "importer", "reseller". The platform maps this to the act's term.
factsNoProduct facts the scope rules declare, e.g. {"battery.capacityKWh": 10}. Any other key is rejected, so pass only a fact you know the rules use (such as one a needs_input result asked for), and never the user's question or free text.
localeNoLanguage for the answer text. Defaults to en.
categoryNoProduct category key, one of the listed values. Map the user's product to the closest key (paint → paints-coatings, an e-bike battery → battery); use "other" when no key fits. Never pass the user's own words.
placedOnMarketNoWhen the product was or will be placed on the market.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / category / description
      Previous value: -"Product category, e.g. battery, textile, electronics."New value: +"Product category key, one of the listed values. Map the user's product to the closest key (paint → paints-coatings, an e-bike battery → battery); use \"other\" when no key fits. Never pass the user's own words."
    • addedInput schema / properties / category / enum
      Added value: +[
+  "battery",
+  "construction",
+  "detergents",
+  "electronics",
+  "fmcg",
+  "furniture",
+  "jewelry",
+  "packaging",
+  "paints-coatings",
+  "steel",
+  "textile",
+  "toys",
+  "tyres",
+  "vehicles",
+  "other"
+]
    • removedInput schema / properties / category / maxLength
      Removed value: -100
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only cover the safe-read profile, but the description adds substantial behavior: the result can be needs_input or not_covered, data.inScope takes one of four values, and results may carry 'Planned, not law yet' or 'being re-checked' labels that must be preserved. It also constrains what the agent may add, which is real operational context.

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?

The purpose is front-loaded, but the body is a single dense paragraph mixing retrieval guidance with a long list of output-compliance rules ('never rank vendors', 'never call this advice'...), which makes it harder to scan than it needs to be. Most sentences do earn their place, but the block structure is poor.

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?

With no output schema, the description carries the burden of explaining returns, and it does name the status outcomes and the data.inScope enumeration. It stops short of describing the full response shape (e.g. what citation fields accompany the answer) for a fairly complex, nested-input tool.

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

Parameters3/5

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

Schema description coverage is 100%, with per-parameter descriptions already explaining role mapping, the facts allow-list, locale default, category mapping and date precision. The description adds only the downstream hint that facts may come from a needs_input result, so the baseline of 3 applies.

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 states a specific verb and resource: it checks whether EU law requires a Digital Product Passport for a product type, from when, and per-role obligations. It then enumerates the concrete question shapes the tool answers, which makes it unambiguously different from siblings like create_draft_passport or required_fields.

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 an explicit 'Use it for' list of user phrasings and prescribes a concrete follow-up loop (if needs_input, ask the user its questions in plain words and call again). It does not name any sibling or state when a different sibling tool is the better choice, so it falls short of full alternative routing.

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

All TracePass DPP Compliance Assistant 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