A
licenseB
qualityA
maintenanceManages trust chains and attestations with built-in EU AI Act compliance.
5
11
MIT
TracePass
by eu.tracepass
Ownership verified
Server Details
Manage products, EU Digital Product Passports, operator parties, and GS1 EPCIS supply-chain events.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- malinoto/tracepass-mcp-server
- GitHub Stars
- 1
- Server Listing
- tracepass-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.6/5.0
Tool DescriptionsA
Average 4.7/5 across 6 of 6 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool targets a distinct domain: EPCIS events, passport fields, passport parties, passport lifecycle, product catalogue, and regulatory templates. There is no overlap in purpose between tools, and even the related passport_fields and passport_parties are clearly separated by the type of data they manage.
Naming Consistency5/5
All tools follow a consistent 'tracepass_' prefix followed by a plural noun (epcis, passport_fields, passport_parties, passports, products, templates). Actions within each tool use lowercase verbs (e.g., list, get, create, update, export, capture) with consistent _by_serial variants, creating a uniform and predictable naming scheme.
Tool Count5/5
With 6 tools, the server is well-scoped for a Digital Product Passport platform. Each tool covers a necessary slice of the domain without redundancy or excessive granularity, fitting comfortably within the ideal range of 3-15 tools.
Completeness4/5
The tool set covers the full passport lifecycle (create, read, update via fields/parties, suspend, archive), product management, EPCIS event capture/query, and regulatory template discovery. The only notable gap is the lack of a delete action for products, but this is a minor oversight given the strong overall coverage.
Available Tools
6 toolstracepass_epcisTracePass EPCIS 2.0AInspect
GS1 EPCIS 2.0 supply-chain events. export is included on Starter plans and up; capture, capture_job, and query require the paid EPCIS add-on (those actions return a 403-style message without it).
Actions (pass via action, with args):
export — args: { id }. Export a passport's events as an EPCIS 2.0 JSON-LD document. Read-only.
export_by_serial — args: { serial, gtin? }. Same as export, addressed by your own serial. A serial is unique only WITHIN a GTIN — if it isn't unique in your account the call returns 409 ambiguous_serial; pass
gtin(or use export by id). Read-only.capture — args: { events }.
eventsis an EPCISDocument, a single event, or an array of events (JSON-LD). Returns a 202 with a captureJobId.capture_job — args: { jobId }. Poll an async capture job. Read-only.
query — args: { params? }.
paramsis a key/value map of standard EPCIS query parameters (EQ_bizStep, GE_eventTime, MATCH_epc, …). Read-only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments for the chosen action; required fields depend on `action`. | |
| action | Yes | EPCIS 2.0: export a passport's events (export | export_by_serial), capture new events, poll a capture job, or query events. |
Output Schema
ParametersJSON 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). |
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the minimal idempotentHint annotation. It discloses read-only actions, the 202 return with captureJobId for capture, potential 409 ambiguous_serial errors, and entitlement/403 behaviors. It also explains that serial uniqueness is GTIN-scoped. This is rich behavioral context absent from structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the domain and then systematically listing actions, arguments, and side effects. Despite being moderately long, every sentence carries essential operational information. The use of bullet-like formatting within the text aids quick scanning.
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?
Given the tool's multi-action complexity, the description is remarkably complete: it covers all parameters, return types, error cases, entitlement restrictions, and the read-only vs. write distinction. The presence of an output schema reduces the need to document return structures, and the description adequately covers the rest.
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 each parameter has a description in the schema itself. The tool description adds extra meaning: for example, it clarifies that serial is unique only within a GTIN, that events can be a single event or array, and that params are standard EPCIS query parameters. This adds value beyond the schema definitions.
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 states the tool's purpose: managing GS1 EPCIS 2.0 supply-chain events, and enumerates five specific actions with their arguments. It strongly distinguishes itself from sibling tools (passport fields, parties, products, etc.) by focusing on EPCIS event capture/export/query.
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?
The description provides explicit guidance on when to use each action, including choosing between export and export_by_serial, paying for the EPCIS add-on, and polling capture_job. It doesn't explicitly contrast with sibling tools, but the tool's domain is distinct enough that the context is clear. The one missing element is an explicit 'use this for X, not for Y' statement relative to siblings, but the action-level guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tracepass_passport_fieldsTracePass passport fieldsAIdempotentInspect
Update field values on a Digital Product Passport. Every change is recorded in the passport's audit trail, tagged as an API-key update.
Actions (pass via action, with args):
update — args: { id, fieldKey, value }.
valuetype matches the field's dataType (string, number, boolean, array, object).update_by_serial — args: { serial, fieldKey, value, gtin? }. Same as update, addressed by your own serial. A serial is unique only WITHIN a GTIN — if it isn't unique in your account the call returns 409 ambiguous_serial; pass
gtin(or use update by id) to resolve exactly.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments for the chosen action; required fields depend on `action`. | |
| action | Yes | Update one passport field, addressed by passport id (update) or by your serial (update_by_serial). |
Output Schema
ParametersJSON 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). |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond the idempotentHint annotation: every change is recorded in the passport's audit trail and tagged as an API-key update, and the value type must match the field's dataType. It also discloses the 409 ambiguous_serial error condition, providing important runtime behavior that the schema and annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a single-sentence purpose followed by a concise bulleted list of the two actions. It uses code formatting for parameters and avoids redundant prose. Every sentence contributes either to usage guidance or to clarifying behavior.
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?
Given the tool's modest complexity (2 parameters, one enum, nested args), the description covers all necessary aspects: both actions, their argument requirements, the serial uniqueness rule, error handling, value type matching, and audit trail behavior. An output schema exists, so not explaining return values is acceptable. The description is sufficient for an agent to select and invoke the tool correctly.
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?
While the schema already describes each parameter, the description adds crucial cross-parameter semantics: it specifies how the `action` parameter selects between the two operations, which args are required for each action, and how `gtin` disambiguates `serial` in case of collisions. This is more meaningful than the individual property descriptions and helps the agent assemble correct invocations.
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 opens with a specific verb and resource: 'Update field values on a Digital Product Passport.' This clearly distinguishes it from sibling tools like tracepass_passports or tracepass_passport_parties, which focus on different entities. The two sub-actions (update and update_by_serial) are explicitly enumerated, leaving no ambiguity about what the tool does.
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?
The description gives clear guidance on choosing between update and update_by_serial based on whether you have a passport id or your own serial. It also explains how to resolve ambiguity when a serial isn't unique within a GTIN, by passing gtin or using update by id. However, it doesn't explicitly mention alternatives like tracepass_passports or state when NOT to use this tool, 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.
tracepass_passport_partiesTracePass passport partiesAIdempotentInspect
Manage the economic-operator parties on a passport — manufacturer, importer, authorisedRepresentative, distributor, recycler, producerResponsibilityOrg. Each party carries a legal name and ideally a validated 13-digit GS1 GLN.
Actions (pass via action, with args):
set — args: { id, role, legalName, gln?, country?, legacyOperatorId? }. Sets or updates one role.
remove — args: { id, role }. Clears one role.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments for the chosen action; required fields depend on `action`. | |
| action | Yes | Set (add/replace) or remove an economic-operator party on a passport by its role. |
Output Schema
ParametersJSON 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). |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The idempotentHint annotation is present and not contradicted. The description adds behavioral context by explaining that 'set' updates an existing role and 'remove' clears it, and it notes the ideal GS1 GLN validation requirement, which goes beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with purpose, followed by a clean bulleted action list. Every sentence earns its place, with no filler or redundancy, and the structure makes actions and their argument shapes easy to scan.
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?
For a tool with only 2 top-level parameters and an output schema, the description sufficiently covers all actions, required arguments, and domain context. Minor gaps exist around edge-case behaviors (e.g., removing a non-existent role), but these are not essential given the output schema.
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%, so the baseline is 3. The description's action summary restates parameter requirements already present in the schema (e.g., legalName required for set, gln optional). It provides a readable shorthand but does not introduce new parameter-level information.
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 opens with a specific verb 'Manage' and names the exact resource: 'economic-operator parties on a passport,' enumerating all role types. It clearly distinguishes this tool from sibling tools handling other TracePass entities such as passports, products, and templates.
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?
The description provides clear context for when to use the tool—managing party roles on a passport—and explains the set/remove actions. It does not explicitly name sibling alternatives, but the party-specific scope and action list make the intended usage unambiguous, meeting the 'clear context, no exclusions' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tracepass_passportsTracePass passportsAInspect
Manage Digital Product Passports — create, read, and run lifecycle actions.
IMPORTANT: create consumes a DPP slot on the account's plan and IS BILLABLE. Creating a passport beyond the included quota incurs a per-passport overage charge; if over quota the tool returns a 402-style message — only re-run with args.confirmOverage=true after the user explicitly agrees to the charge. archive is IRREVERSIBLE (the public QR permanently 404s); prefer suspend when a change might be undone.
Actions (pass via action, with args):
list — args: { page?, limit? (≤100), productId?, status?, search? }. status ∈ draft|in_review|approved|published|suspended|expired|archived. Read-only.
get — args: { id, format? (summary|full), lang? }. Read-only.
get_by_serial — args: { serial, format?, lang?, gtin? }. Read-only. Addresses the passport by your own serial. A serial is unique only WITHIN a GTIN — if the same serial exists under two GTINs in your account the call returns 409 ambiguous_serial; pass
gtin(or use the by-id action) to resolve exactly.compliance — args: { id }. Read-only. Returns a three-tier compliance verdict (compliant | compliant_with_warnings | incomplete) with regulation-cited findings — use to gap-check a passport against the rules for its category, fix the cited fields/parties, then re-check.
registry_readiness — args: { id }. Read-only. Returns { ready, findings[] } — whether the passport would pass the EU DPP Registry's FORMAL submission gate (mandatory fields present, correct formatting, a resolvable public link, item-level granularity via a serial number, and a well-formed commodity code where the category carries one). This is the registry's mechanical pre-submission check, NOT the substantive compliance verdict; a passport can be registry-ready yet not substantively compliant. Battery passports only.
create — args: { productId, gtin, serialNumber, confirmOverage? }. BILLABLE.
suspend — args: { id }. Reversible — public QR shows 'suspended'.
suspend_by_serial — args: { serial, gtin? }. Same as suspend, addressed by your serial. 409 ambiguous_serial if the serial isn't unique in your account — pass
gtin.archive — args: { id }. IRREVERSIBLE — confirm with the user first.
archive_by_serial — args: { serial, gtin? }. IRREVERSIBLE, addressed by your serial — confirm first. 409 ambiguous_serial if the serial isn't unique — pass
gtin.get_qr — args: { id, format? (svg|png) }. Read-only.
get_qr_by_serial — args: { serial, format? (svg|png), gtin? }. Read-only. Same as get_qr, addressed by your own serial. A serial is unique only WITHIN a GTIN — if the same serial exists under two GTINs in your account the call returns 409 ambiguous_serial; pass
gtin(or use get_qr by id) to resolve exactly.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments for the chosen action; required fields depend on `action` (see each action above). | |
| action | Yes | Which passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_qr | get_qr_by_serial. Lifecycle: create (BILLABLE) | suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant. |
Output Schema
ParametersJSON 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). |
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the single idempotentHint annotation, the description discloses billable create with overage charges/402 confirmOverage, archive irreversibility (QR 404s), suspend reversibility, and ambiguous_serial 409 behavior. It marks each action as read-only or lifecycle, providing operational expectations the agent cannot infer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured as a bullet list with CAPITALIZED warnings, the description front-loads billing/irreversibility and logically groups action args. It is lengthy but each sentence contributes; there is no filler.
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?
Given 12 actions, nested args, billing side effects, and two distinct by_serial addressing modes, the description covers every operation, its required args, edge cases, and error conditions. Output schema exists, and the description need not restate return values; it still mentions compliance verdict tiers and registry_readiness shape.
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?
Although schema covers 100% of parameters, the description adds cross-parameter semantics and action-specific requirements: e.g., limit ≤100, status enum, serial unique only within GTIN, and per-action arg sets. It explains confirmOverage and the ambiguous_serial condition for multi-param interactions.
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 opens with 'Manage Digital Product Passports — create, read, and run lifecycle actions,' a specific verb+resource purpose. It enumerates all 12 actions, clearly distinguishing this tool from siblings like tracepass_products or tracepass_passport_fields.
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 guidance includes 'prefer suspend when a change might be undone' vs archive, and the compliance vs registry_readiness distinction ('NOT the substantive compliance verdict'). It also tells when to pass gtin to resolve ambiguous_serial, and when to use the by-id vs by-serial actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tracepass_productsTracePass productsAInspect
Manage the TracePass product catalogue. A product is the catalogue layer — one product can have many passports (one per serialised unit). Products are not billable on their own.
Actions (pass via action, with args):
list — args: { page?, limit? (≤100), category?, status?, search? }. Read-only.
get — args: { id }. Read-only.
create — args: { name, model, category, description? }.
categoryis one of: battery, textile, electronics, construction, steel, detergents, paints-coatings, packaging, furniture, tyres, jewelry, toys, fmcg.update — args: { id, name?, model?, description? }; pass at least one field to change.
create_batch — args: { products: [ { name, model, category, description? }, … ] }, up to 100. Partial-success: the response carries a per-item status, so some items can be created while others error. The whole batch consumes N writes upfront; if that would exceed the daily cap NOTHING is created (429).
archive — args: { id }. Soft-archive a product. Blocked with 409 while any non-archived passport still references it — archive those passports first. This is reversible and is NOT deletion.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Arguments for the chosen action; required fields depend on `action` (see each action above). | |
| action | Yes | Which product operation to run: list | get | create | create_batch | update | archive. |
Output Schema
ParametersJSON 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). |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given only idempotentHint=false annotation, the description carries the full burden of behavioral disclosure. It explicitly marks list and get as 'Read-only', describes create_batch's partial-success model with per-item status, mentions the daily cap for batch operations returning 429, and details archive as a reversible soft-archive (not deletion) with conflict conditions. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear section headers (Actions) and bullet-point style for each action. Every sentence provides essential operational detail without redundancy. It front-loads the core concept ('A product is the catalogue layer') and then precisely documents each action's semantics in minimal space.
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?
Despite having an output schema, the description fully characterizes the tool's behavior across six actions, including error conditions (409, 429), success semantics (partial-success), and limitations (batch max 100, daily cap). Given the complexity (nested objects, multiple actions, edge cases), the description is remarkably complete without relying on output schema documentation.
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 description coverage is 100%, so baseline is 3. The description adds significant value by grouping parameters per action (e.g., 'args: { page?, limit? (≤100), category?, status?, search? }'), enumerating valid category values, clarifying that update passes 'at least one field to change', and specifying batch limits. However, the description doesn't document all nested object properties for create_batch's products array beyond the example structure, which the schema also lacks.
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 states 'Manage the TracePass product catalogue' and defines a product as 'the catalogue layer — one product can have many passports'. It explicitly enumerates six distinct actions (list, get, create, update, create_batch, archive) with their specific behavior, which distinguishes this tool from siblings like tracepass_passports.
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?
The description provides excellent when-to-use guidance by explaining the relationship between products and passports, noting that 'Products are not billable on their own' and for archive action specifying when a 409 conflict occurs (blocked while any non-archived passport references it). This context helps the agent decide when to use this catalog tool vs passport-specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tracepass_templatesTracePass DPP templates (regulatory schemas)ARead-onlyIdempotentInspect
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.
categoryis 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).Then fall back to
required. The map is keyed ONLY by the three in-scope categories, so skipping step 1 falls through torequiredand 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.
ParametersJSON 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
ParametersJSON 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). |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, repeatable reads. The description adds substantial behavioral context beyond these annotations: it explains that the data is regulatory schema (not actual passport data), details the resolution logic for the battery 'required' field, warns about mutual exclusivity of field sets for EV/LMT, and describes the scope-first rule. This provides rich behavioral transparency without contradicting 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?
The description is well-structured with a clear intro sentence, followed by action specifications and a detailed battery resolution section. It is front-loaded with the main purpose and use cases. The battery section is somewhat long but necessary for safe usage. Slightly verbose in the enum listing, which could be redundant given schema coverage. Overall earns its length with valuable content.
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?
Given the complexity of regulatory schema, two actions, and an output schema existence, the description is comprehensive. It covers return value semantics for both actions, provides critical edge case handling for battery category, explains the resolution order for 'required-ness', and notes the mutual exclusivity rule for EV/LMT. The output schema likely documents the return structure, so the description does not need to duplicate that. A fully complete description for a moderately complex 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 description coverage is 100%; the schema already documents both parameters (action and category) with enums and descriptions. The description adds value by explaining what each action returns (list yields category list with field counts; get yields full field schema) and provides the complete list of category enum values. It also adds critical context about the battery category's special resolution logic, though parameter semantics themselves are mostly covered by the schema. Baseline 3 plus one extra for the battery-specific nuance.
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 states it is a 'read-only reference data' tool to 'discover the regulatory field schema for each DPP category'. It explicitly distinguishes two actions (list and get) and specifies what each returns, making the purpose unambiguous. The verb 'discover' combined with the resource 'regulatory field schema' provides a specific verb+resource pairing that differentiates it from sibling tools.
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?
The description explicitly tells when to use this tool: 'advise on requirements before creating products/passports' and 'to gap-check a draft against the rules'. It provides clear guidance on the actions (list vs. get) and when to use each. No explicit when-not-to-use exclusions are needed as the scope is well-defined, and there are no obvious alternative siblings that compete for the same use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceExposes CRUD operations for products via MCP tools and a resource, sharing a common business logic layer with a GraphQL API.
- AlicenseNot gradedqualityBmaintenanceEnables natural-language setup and management of a governed digital product catalog, including schema, products, and rules, with dry-run previews, audit logging, and two-phase confirmations for destructive actions.MIT
- AlicenseAqualityBmaintenanceEnables read-only discovery and verification of products across droplinked's KYB-attested merchant network via tools for inventory, merchant, and brand attestation lookups.7MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.