Skip to main content
Glama
malinoto

tracepass-mcp-server

by malinoto

TracePass DPP templates (regulatory schemas)

tracepass_templates
Read-onlyIdempotent

Fetch the regulatory field schema for each DPP category to determine what a compliant passport must include under EU law. Use to advise before creating products or to validate drafts.

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 12 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, chemicals, 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).

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

TableJSON Schema
NameRequiredDescriptionDefault
argsNoArguments for the chosen action; `category` is required for get, ignored for list.
actionYesList all DPP category templates, or get one template by category.

Output Schema

TableJSON 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).
Behavior5/5

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

Beyond the readOnlyHint/idempotentHint annotations, the description adds substantial behavioral detail: the battery-specific resolution order, the warning that using `required` without checking scope invents obligations, and the mutually exclusive EV/LMT field sets. This goes far beyond what annotations alone convey.

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?

The description is long but well-structured: a lead purpose sentence, a clear action breakdown, and a focused battery caveat. Every sentence carries meaningful constraints or guidance, and the critical battery logic is visually separated. It is dense but appropriate for the tool's complexity.

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?

Combined with the rich input schema, output schema, and annotations, the description is complete: it covers scope, all categories, action-specific behavior, and the most confusing edge case (battery). It even references governing regulations and dates, leaving little ambiguity for an agent selecting or invoking this tool.

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%, but the description adds semantic depth by explaining the action/args passing pattern and elaborating on the meaning of `category` (including the full enum and battery-specific resolution logic). It slightly duplicates what the schema already states, so it does not reach 5, but it does exceed the baseline.

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 description clearly identifies this as a read-only discovery tool for regulatory DPP templates, with a specific verb ('Discover') and resource ('regulatory field schema for each DPP category'). It distinguishes itself from siblings (e.g., tracepass_passports, tracepass_products) by focusing on compliance requirements and template-level reference data.

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 provides clear usage context: 'Use this to advise on requirements before creating products/passports, and to gap-check a draft against the rules.' This tells the agent when to consult the tool, though it does not explicitly name sibling tools as alternatives or state when not to use it.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/malinoto/tracepass-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server