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, chemicals, 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.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses behaviors beyond the single idempotentHint annotation: read-only actions are marked, archive is described as soft and reversible, and important edge cases like 409 blocking, 429 daily-cap behavior, and partial-success batch writes are explicitly stated.
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 longer but well-structured with a purpose intro and bulleted actions. Each sentence carries necessary information for a multi-action tool. It could be slightly more compact but remains focused.
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 complexity (six actions, nested args, enums, output schema), the description covers all action-specific details, constraints, and failure modes. It leaves no critical gaps for an agent to 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 schema coverage is 100%, the description adds substantial per-action parameter semantics: required fields for create, 'at least one field to change' for update, category enum spelled out, batch limit and item shape, and pagination limits. This goes well beyond the schema.
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 explains the product concept, distinguishing it from passport-related sibling tools. It lists all six actions with specific verbs, making the tool's scope unambiguous.
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 context on when to use products vs. passports ('one product can have many passports') and notes that products are not billable. It doesn't explicitly name sibling alternatives for when-not-to-use, but the action list and product-layer explanation imply appropriate usage.
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 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.
categoryis 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:
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?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses significant behavioral nuances: the battery scope resolution order (EV, LMT, industrial_gt_2kwh only), the requiredBy vs required distinction, and the mutually exclusive field sets for EV vs LMT. This is detailed, non-obvious behavioral context that the annotations do not provide.
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 long but every sentence earns its place. It is front-loaded with the core purpose, then structured into the two actions, and finally the critical battery edge cases. There is no filler or repetition; the density is justified by 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?
Given the tool has two actions, 12 categories, and several battery-specific exclusions, the description covers all essential aspects: the list action's output (12 categories with counts and regulation), the get action's full field details, and the battery resolution logic. The presence of an output schema covers return-value structure, so the description correctly focuses on usage and edge cases.
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?
Even though the schema describes both parameters at 100% coverage, the description adds operational semantics: it explains how to pass actions ('pass via `action`, with `args`'), clarifies that `category` is ignored for `list`, and provides category-specific logic (e.g., the three in-scope battery categories and the requiredBy map). This goes well beyond the schema's basic documentation.
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+resource: 'Discover the regulatory field schema for each DPP category' and defines the tool as read-only reference data for compliant passports. It clearly distinguishes itself from sibling tools by framing the purpose as pre-creation/gap-checking, not working with actual passports or products.
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?
Explicit use cases are provided: 'Use this to advise on requirements before creating products/passports, and to gap-check a draft against the rules.' However, it does not explicitly name sibling alternatives or state when not to use the tool, leaving that to the reader to infer from context.
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
- Flicense-qualityCmaintenanceExposes CRUD operations for products via MCP tools and a resource, sharing a common business logic layer with a GraphQL API.
- Alicense-qualityBmaintenanceEnables 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.