TracePass
Server Details
Manage products, EU Digital Product Passports, operator parties, and GS1 EPCIS supply-chain events.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Tool Definition Quality
Average 4.5/5 across 6 of 6 tools scored. Lowest: 3.8/5.
Tools are organized into distinct namespaces (epcis, passport_fields, passport_parties, passports, products, templates), each with clearly separated actions. No two tools or actions overlap in purpose, making it easy for an agent to select the correct one.
All tool names follow the consistent pattern `tracepass_<domain>`, and actions are simple lowercase verbs (e.g., export, list, create). There is no mixing of naming conventions, and the pattern is predictable across the entire server.
With 6 tools covering distinct domains (EPCIS, passport fields, parties, passports, products, templates), the number is well-scoped for a Digital Product Passport management system. Each tool earns its place without redundancy.
The toolset covers the full lifecycle of passports (CRUD, suspend, archive), products (list/get/create/update), parties (set/remove), EPCIS events (capture/query/export), and template schemas (list/get). Minor gaps like product deletion are absent, but they are likely intentional for data integrity.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Action-specific arguments — see the description. | |
| action | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the single annotation (idempotentHint=false), the description discloses that export, capture_job, and query are read-only, while capture is not (returns a 202). It also reveals plan-dependent error behavior, adding substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence overview, plan requirements, then a clear bullet list of actions with their arguments and behavior. No unnecessary repetition; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 actions, no output schema), the description covers all action behaviors, argument requirements, return effects (JSON-LD document, 202 with jobId, polling, query results), and plan restrictions. It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite low schema description coverage (50%), the description thoroughly explains the `args` parameter for each action, detailing the expected structure (e.g., `id`, `events` as EPCISDocument/array, `jobId`, `params` as key/value map). This fully compensates for the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as handling GS1 EPCIS 2.0 supply-chain events, listing four distinct actions with specific purposes. It distinguishes itself from sibling tools (passports, parties, products, templates) by focusing on EPCIS event operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context by noting which actions are available on different plans and that unsupported actions return a 403-like error. However, it does not explicitly recommend when to use this tool over siblings, though the domain separation is clear.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Action-specific arguments — see the description. | |
| action | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond the idempotentHint annotation by explaining that every change is recorded in the passport's audit trail and tagged as an API-key update. This informs the agent about side effects and traceability. The annotation contradiction is minor and not definitive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, audit trail note, and action breakdown. It is immediately informative and wastes no words. The action list is clearly formatted in a code block, enhancing readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core functionality and parameters but lacks information on error handling (e.g., invalid fieldKey or data type mismatch), return values, and behavior when idempotency is violated. Given the tool's simplicity and lack of output schema, additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains the action enum and the structure of args for the 'update' action, including id, fieldKey, and value with type constraints matching field dataType. The input schema is minimal, so the description provides essential semantic information that would otherwise be missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates field values on a Digital Product Passport, with a specific verb ('update') and resource ('field values on a Digital Product Passport'). It distinguishes from sibling tools that handle other aspects like EPCIS, parties, products, and templates, ensuring no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only explains what the tool does but does not provide any guidance on when to use it versus alternatives. No explicit when-not-to-use or comparison to sibling tools. The agent must infer usage solely from the tool name and siblings.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Action-specific arguments — see the description. | |
| action | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the two actions and their effects (set/remove roles), adding value beyond the idempotentHint annotation. However, it does not cover error behavior, authentication needs, or state changes beyond the described actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using a brief introductory sentence followed by a clear bullet list for actions. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately explains inputs and actions. However, it lacks details on return values, error messages, or postconditions, leaving some gaps for complete contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 50% schema coverage, the description compensates by detailing the args structure for each action (set args: id, role, legalName, gln?, country?, legacyOperatorId?; remove args: id, role). This adds meaning beyond the generic 'Action-specific arguments' in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool manages economic-operator parties on a passport, listing specific roles (manufacturer, importer, etc.) and the available actions (set, remove). This clearly distinguishes it from sibling tools like tracepass_passports, which likely manage the passport itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., tracepass_passport_fields). It does not mention prerequisites, conditions, or scenarios where other tools would be more appropriate.
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? }. Read-only.
create — args: { productId, gtin, serialNumber, confirmOverage? }. BILLABLE.
suspend — args: { id }. Reversible — public QR shows 'suspended'.
archive — args: { id }. IRREVERSIBLE — confirm with the user first.
get_qr — args: { id, format? (svg|png) }. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Action-specific arguments — see the description for each action's shape. | |
| action | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the single annotation (idempotentHint: false), the description discloses billing behavior, irreversibility, read-only nature of list/get actions, and the effect of archive on QR codes. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bold warnings, bullet-like action list, and clear hierarchy. Every sentence adds value, no fluff. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for parameters and behavior, but lacks description of return values/output format. Given no output schema, a brief note on response structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite only 50% schema description coverage, the description fully enumerates each action's parameters (e.g., list args: page, limit, productId, etc.; create args: productId, gtin, serialNumber, confirmOverage). This fully compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool manages Digital Product Passports with specific actions (create, read, lifecycle). Distinguishes from sibling tools like tracepass_epcis by focusing on passports and listing unique actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use each action, including critical billing warning for 'create' (confirmOverage) and irreversibility for 'archive' (prefer 'suspend'). Provides clear context for safe invocation.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Action-specific arguments — see the description for each action's shape. | |
| action | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the idempotentHint false annotation, the description adds that list and get are read-only, that products are not billable, and that update requires at least one field. This provides helpful behavioral context but lacks details on permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~80 words), with a clear front-loaded purpose and a well-structured, bullet-style enumeration of actions. No extraneous sentences; every line adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and multiple nested actions, the description fully covers the product concept, action behaviors, and argument shapes. It is sufficient for an AI 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully compensates for the sparse schema (50% coverage) by detailing the shape of `args` for each action, including optional fields, defaults (e.g., limit ≤100), and enum values for category. This adds meaning far beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages the TracePass product catalogue, defines what a product is (catalogue layer), and lists all actions (list, get, create, update), distinctly separating from sibling tools dealing with passports, EPCIS, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly enumerates actions and their arguments, indicating when to use each (e.g., read-only vs. create/update). While it doesn't define exclusions or alternatives to sibling tools, the context implies usage for product catalogue management.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Action-specific arguments — see the description for each action's shape. | |
| action | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint as true, so the tool's safety is clear. The description adds value by explaining the return data (field schemas, categories, etc.) and that it is read-only reference data, which goes beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It front-loads the purpose, then provides actionable instructions with actions and args. Every sentence serves a purpose, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains what each action returns (list: categories with field counts; get: full field schema). Given the tool's moderate complexity and the context from annotations and siblings, the description is complete enough 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has vague descriptions for args, but the tool description explicitly details each action's arguments: list requires no args, get requires a category (with enumerated list). This adds significant meaning and compensates for the schema's lack of specificity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers regulatory field schemas for each DPP category, specifying it as read-only reference data. It distinguishes from sibling tools like tracepass_epcis and tracepass_passports by focusing on templates and compliance rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the tool to advise on requirements before creating products/passports and to gap-check drafts. It also outlines the two actions (list and get) with their arguments, providing clear context for when and how to invoke the tool.
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!