Skip to main content
Glama

TracePass

by eu.tracepass
OverviewDiscussionsAdmin

Server Details

Manage products, EU Digital Product Passports, operator parties, and GS1 EPCIS supply-chain events.

Ownership verified
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
malinoto/tracepass-mcp-server
GitHub Stars
1
Server Listing
tracepass-mcp-server

TDQS

A4.4/5.0

Scored across 6 tools

Disambiguation5/5

Each action targets a distinct operation, and the 'by_serial' variants are clearly differentiated from their by-id counterparts. The overlap between compliance and registry_readiness is minimal as they serve different checks (substantive compliance vs mechanical registry readiness).

Naming Consistency4/5

Most actions follow a consistent verb_noun pattern (export, capture, update, suspend, archive). A few exceptions like compliance and registry_readiness are noun-based but still unambiguous. The consistent use of 'by_serial' suffix across domains reinforces the pattern.

Tool Count2/5

With 27 distinct actions, the server exceeds the 25-tool threshold that signals heaviness. While the count reflects a comprehensive DPP management system, agents may face increased selection overhead. The scope is broad, but the number feels excessive for typical agent workflows.

Completeness5/5

The surface covers the full lifecycle: products (create/read/update/archive/batch), passports (create/read/suspend/archive/QR/compliance), parties (set/remove), EPCIS (capture/query/export), and templates (list/get). No obvious dead ends or missing critical operations for the domain.

Available Tools

6 tools
tracepass_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 }. events is 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? }. params is a key/value map of standard EPCIS query parameters (EQ_bizStep, GE_eventTime, MATCH_epc, …). Read-only.

ParametersJSON Schema
NameRequiredDescriptionDefault
argsNoArguments for the chosen action; required fields depend on `action`.
actionYesEPCIS 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
NameRequiredDescription
idNoThe resource's TracePass id, when the response is a single entity.
pageNoCurrent page number (list actions).
errorNoMachine-readable error code, when the API rejected the request.
itemsNoThe page of results, when the action is a list.
limitNoPage size (list actions).
totalNoTotal matching records across all pages (list actions).
resultNoWraps a non-object response body (e.g. a QR code string).
messageNoHuman-readable error or status detail, when present.
totalPagesNoTotal number of pages (list actions).

TDQS

A4.8/5.0
Behavior5/5

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

With only idempotentHint: false in annotations, the description carries the full behavioral burden and does so extensively. It marks four actions as read-only, reveals that capture returns a 202 with a captureJobId and is asynchronous, and discloses specific error conditions like 409 ambiguous_serial and 403-style messages. No contradiction 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 a concise lead sentence, a critical plan-requirement note, and a clean action-by-action bullet list. Every sentence adds value, and the structure makes the multi-action tool easy to scan and understand.

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 (five actions, nested args, async behavior, plan restrictions), the description is complete. It covers all actions, their required args, error conditions, and asynchronous behavior. Return values are not detailed, but an output schema exists, so that omission is acceptable.

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 the schema already has 100% description coverage, the description adds substantial meaning beyond it. It maps each parameter to its action, clarifies that a serial is unique only within a GTIN, explains that events can be an EPCISDocument or an array, and gives examples of EPCIS query parameters. This goes well beyond the schema's field-level descriptions.

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: 'GS1 EPCIS 2.0 supply-chain events.' It then enumerates each specific action (export, export_by_serial, capture, capture_job, query) with a precise verb and resource. This distinguishes it from sibling tools like tracepass_passports and tracepass_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?

The description provides explicit usage context: it notes which actions are included on Starter plans vs. require the paid add-on, and explains when to use export_by_serial versus export with a GTIN. It does not explicitly name alternative sibling tools, but the action-level guidance is clear enough for correct selection.

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 fieldsA
Idempotent
Inspect

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 }. value type 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
NameRequiredDescriptionDefault
argsNoArguments for the chosen action; required fields depend on `action`.
actionYesUpdate one passport field, addressed by passport id (update) or by your serial (update_by_serial).

Output Schema

ParametersJSON Schema
NameRequiredDescription
idNoThe resource's TracePass id, when the response is a single entity.
pageNoCurrent page number (list actions).
errorNoMachine-readable error code, when the API rejected the request.
itemsNoThe page of results, when the action is a list.
limitNoPage size (list actions).
totalNoTotal matching records across all pages (list actions).
resultNoWraps a non-object response body (e.g. a QR code string).
messageNoHuman-readable error or status detail, when present.
totalPagesNoTotal number of pages (list actions).

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the idempotentHint annotation, the description discloses that every change is recorded in the passport's audit trail and tagged as an API-key update. It also explains the 409 error condition for ambiguous serials and that the value type must match the field's dataType. This adds meaningful behavioral context without contradicting 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 well-structured: a purpose sentence followed by a clear list of actions with their args and usage notes. Every sentence adds value; there is no redundant repetition of schema information. The format makes it easy to scan and understand the tool's 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 complexity (two actions, nested args, optional disambiguator) and the presence of an output schema, the description covers all necessary aspects: purpose, action mechanics, error handling, audit trail, and value typing. No critical behavior is left unexplained, and the output schema handles return-value details.

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 the input schema describes each parameter, the description adds crucial semantic meaning by tying parameters to actions: it details the args structure for update vs update_by_serial, clarifies the optional `gtin` disambiguator, and specifies that `value` must match the field's dataType. This goes well beyond the schema's one-line descriptions.

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: 'Update field values on a Digital Product Passport.' This clearly states the tool's function and distinguishes it from sibling tools that manage passports, products, parties, EPCIS, or templates. The two actions (update, update_by_serial) are concrete and further clarify the scope.

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 the two actions: 'update' by passport id and 'update_by_serial' by your own serial. It explains the serial-uniqueness caveat within a GTIN and the 409 ambiguous_serial error, advising to pass `gtin` or use update by id. However, it does not explicitly compare this tool to sibling tools or state when to prefer this over them.

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 partiesA
Idempotent
Inspect

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
NameRequiredDescriptionDefault
argsNoArguments for the chosen action; required fields depend on `action`.
actionYesSet (add/replace) or remove an economic-operator party on a passport by its role.

Output Schema

ParametersJSON Schema
NameRequiredDescription
idNoThe resource's TracePass id, when the response is a single entity.
pageNoCurrent page number (list actions).
errorNoMachine-readable error code, when the API rejected the request.
itemsNoThe page of results, when the action is a list.
limitNoPage size (list actions).
totalNoTotal matching records across all pages (list actions).
resultNoWraps a non-object response body (e.g. a QR code string).
messageNoHuman-readable error or status detail, when present.
totalPagesNoTotal number of pages (list actions).

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the idempotentHint annotation, the description adds behavioral context: 'set' adds/replaces one role, 'remove' clears one role, and parties ideally carry a validated GLN. It does not contradict annotations and provides useful detail about how each action behaves.

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, front-loaded with purpose, and uses a clean bullet structure for actions. Every sentence adds meaningful information with no redundancy or filler.

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?

The description covers both actions, their required arguments, and the domain concept of economic-operator parties. Given the output schema exists and annotations declare idempotency, the description is sufficiently complete, though it does not discuss validation failure or edge-case behavior.

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 the baseline is 3, but the description adds value by grouping parameters per action (set includes legalName, gln, country, legacyOperatorId; remove only id and role) and by highlighting the validated 13-digit GLN requirement that is not in the schema description.

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 manages economic-operator parties on a passport, lists the specific roles, and distinguishes it from sibling tools like passport_fields or passports. The verb 'manage' paired with the resource and action definitions leaves no ambiguity.

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 explicitly shows when to use set vs remove actions and their required args, providing clear operational context. It does not mention alternatives or exclusions relative to sibling tools, but the action-based instructions are sufficient for most use cases.

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
NameRequiredDescriptionDefault
argsNoArguments for the chosen action; required fields depend on `action` (see each action above).
actionYesWhich 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
NameRequiredDescription
idNoThe resource's TracePass id, when the response is a single entity.
pageNoCurrent page number (list actions).
errorNoMachine-readable error code, when the API rejected the request.
itemsNoThe page of results, when the action is a list.
limitNoPage size (list actions).
totalNoTotal matching records across all pages (list actions).
resultNoWraps a non-object response body (e.g. a QR code string).
messageNoHuman-readable error or status detail, when present.
totalPagesNoTotal number of pages (list actions).

TDQS

A5/5.0
Behavior5/5

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

The description discloses critical behavioral traits beyond the idempotentHint annotation: create is billable and may return 402, archive permanently 404s the QR, serials are only unique within a GTIN and trigger 409 errors, and registry_readiness is only a formal check not substantive compliance. These are non-obvious, high-impact details not visible in annotations or schema.

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 well-structured: a short intro, a prominent billing/irreversibility warning, then a bullet-style action list with inline args and notes. Each sentence serves a purpose, and critical warnings are front-loaded before the action list. Despite the length, it is easy to scan and reference.

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?

For a tool with 12 actions, nested args, multiple enums, and high-stakes side effects, the description covers all bases: read vs write actions, per-action parameter requirements, error conditions (402, 409), and the distinction between registry readiness and compliance. The presence of an output schema for each action likely completes the picture, but the description alone is already thorough.

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?

Though schema coverage is 100%, the description adds significant semantic value: it clarifies that `confirmOverage` must only be true after explicit user consent, that `format` values differ by action (summary/full vs svg/png), that `status` is an enum with exact values, and that `gtin` resolves ambiguous_serial. These enrich the schema definitions with usage context.

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 clear verb+resource statement: 'Manage Digital Product Passports — create, read, and run lifecycle actions.' It then enumerates 12 specific actions with distinct purposes, effectively distinguishing this tool from siblings like tracepass_products (products) and tracepass_epcis (event data). No ambiguity about scope.

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?

Provides explicit guidance on when to use each action, including when to avoid certain ones: 'archive is IRREVERSIBLE... prefer suspend when a change might be undone.' It also explains when to pass `gtin` to resolve ambiguous serials, and warns about the billing implications of `create`. This goes well beyond basic context.

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? }. category is 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
NameRequiredDescriptionDefault
argsNoArguments for the chosen action; required fields depend on `action` (see each action above).
actionYesWhich product operation to run: list | get | create | create_batch | update | archive.

Output Schema

ParametersJSON Schema
NameRequiredDescription
idNoThe resource's TracePass id, when the response is a single entity.
pageNoCurrent page number (list actions).
errorNoMachine-readable error code, when the API rejected the request.
itemsNoThe page of results, when the action is a list.
limitNoPage size (list actions).
totalNoTotal matching records across all pages (list actions).
resultNoWraps a non-object response body (e.g. a QR code string).
messageNoHuman-readable error or status detail, when present.
totalPagesNoTotal number of pages (list actions).

TDQS

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)A
Read-onlyIdempotent
Inspect

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. category is 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:

  1. SCOPE FIRST. Only EV, LMT and industrial_gt_2kwh batteries owe a passport at all (Art. 77(1), Reg (EU) 2023/1542). For portable, SLI or industrial_lte_2kwh, NO field is required — do not list mandatory fields for them; say the battery is out of scope.

  2. Then requiredBy[batteryCategory] where the field carries that map (required | conditional | notApplicable).

  3. Then fall back to required. The map is keyed ONLY by the three in-scope categories, so skipping step 1 falls through to required and invents an obligation the Regulation does not impose. Note also that EV and LMT report state-of-health through MUTUALLY EXCLUSIVE field sets — an EV battery must leave the remaining-capacity cluster empty and an LMT battery must leave stateOfCertifiedEnergy empty, so no single battery ever fills every field.

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

Output Schema

ParametersJSON Schema
NameRequiredDescription
idNoThe resource's TracePass id, when the response is a single entity.
pageNoCurrent page number (list actions).
errorNoMachine-readable error code, when the API rejected the request.
itemsNoThe page of results, when the action is a list.
limitNoPage size (list actions).
totalNoTotal matching records across all pages (list actions).
resultNoWraps a non-object response body (e.g. a QR code string).
messageNoHuman-readable error or status detail, when present.
totalPagesNoTotal number of pages (list actions).

TDQS

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Changedtracepass_products1 field changed
      • changedInput schema / properties / args / properties / category / description
        Previous value: -"DPP category for create: battery | textile | electronics | construction | steel | chemicals | packaging | furniture | tyres | jewelry | toys | fmcg."New value: +"DPP category for create: battery | textile | electronics | construction | steel | detergents | paints-coatings | packaging | furniture | tyres | jewelry | toys | fmcg."
    • Changedtracepass_templates1 field changed
      • changedInput schema / properties / args / properties / category / description
        Previous value: -"DPP category to fetch (required for get): battery | textile | electronics | construction | steel | chemicals | packaging | furniture | tyres | jewelry | toys | fmcg."New value: +"DPP category to fetch (required for get): battery | textile | electronics | construction | steel | detergents | paints-coatings | packaging | furniture | tyres | jewelry | toys | fmcg."
  2. 1 tool update
    • Changedtracepass_products3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Which product operation to run: list | get | create | update."New value: +"Which product operation to run: list | get | create | create_batch | update | archive."
      • changedInput schema / properties / action / enum
        Previous value: -[
-  "list",
-  "get",
-  "create",
-  "update"
-]New value: +[
+  "list",
+  "get",
+  "create",
+  "create_batch",
+  "update",
+  "archive"
+]
      • addedInput schema / properties / args / properties / products
        Added value: +{
+  "description": "Products to create for create_batch: [{ name, model, category, description? }], max 100.",
+  "items": {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  "type": "array"
+}
  3. 1 tool update
    • Changedtracepass_passports3 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Which passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_qr. Lifecycle: create (BILLABLE) | suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."New value: +"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."
      • changedInput schema / properties / action / enum
        Previous value: -[
-  "list",
-  "get",
-  "get_by_serial",
-  "compliance",
-  "registry_readiness",
-  "create",
-  "suspend",
-  "suspend_by_serial",
-  "archive",
-  "archive_by_serial",
-  "get_qr"
-]New value: +[
+  "list",
+  "get",
+  "get_by_serial",
+  "compliance",
+  "registry_readiness",
+  "create",
+  "suspend",
+  "suspend_by_serial",
+  "archive",
+  "archive_by_serial",
+  "get_qr",
+  "get_qr_by_serial"
+]
      • changedInput schema / properties / args / properties / format / description
        Previous value: -"get/get_by_serial: summary|full. get_qr: svg|png."New value: +"get/get_by_serial: summary|full. get_qr/get_qr_by_serial: svg|png."
  4. 1 tool update
    • Changedtracepass_passports2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Which passport operation to run. Reads: list | get | get_by_serial | compliance | get_qr. Lifecycle: create (BILLABLE) | suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."New value: +"Which passport operation to run. Reads: list | get | get_by_serial | compliance | registry_readiness | get_qr. Lifecycle: create (BILLABLE) | suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."
      • changedInput schema / properties / action / enum
        Previous value: -[
-  "list",
-  "get",
-  "get_by_serial",
-  "compliance",
-  "create",
-  "suspend",
-  "suspend_by_serial",
-  "archive",
-  "archive_by_serial",
-  "get_qr"
-]New value: +[
+  "list",
+  "get",
+  "get_by_serial",
+  "compliance",
+  "registry_readiness",
+  "create",
+  "suspend",
+  "suspend_by_serial",
+  "archive",
+  "archive_by_serial",
+  "get_qr"
+]
  5. 6 tool updates
    • Changedtracepass_epcis6 fields changed
      • addedInput schema / properties / action / description
        Added value: +"EPCIS 2.0: export a passport's events (export | export_by_serial), capture new events, poll a capture job, or query events."
      • removedInput schema / properties / args / additionalProperties
        Removed value: -{}
      • changedInput schema / properties / args / description
        Previous value: -"Action-specific arguments — see the description."New value: +"Arguments for the chosen action; required fields depend on `action`."
      • addedInput schema / properties / args / properties
        Added value: +{
+  "events": {
+    "description": "EPCIS 2.0 event payload (an EPCISDocument or event list). Required for capture."
+  },
+  "gtin": {
+    "description": "GTIN disambiguator for export_by_serial when the serial isn't unique (else 409).",
+    "type": "string"
+  },
+  "id": {
+    "description": "Passport id. Required for export.",
+    "type": "string"
+  },
+  "jobId": {
+    "description": "Capture job id to poll. Required for capture_job.",
+    "type": "string"
+  },
+  "params": {
+    "additionalProperties": {
+      "type": "string"
+    },
+    "description": "EPCIS query parameters as key→value strings (query, optional).",
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  "serial": {
+    "description": "Your serial. Required for export_by_serial.",
+    "type": "string"
+  }
+}
      • removedInput schema / properties / args / propertyNames
        Removed value: -{
-  "type": "string"
-}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "error": {
+      "description": "Machine-readable error code, when the API rejected the request.",
+      "type": "string"
+    },
+    "id": {
+      "description": "The resource's TracePass id, when the response is a single entity.",
+      "type": "string"
+    },
+    "items": {
+      "description": "The page of results, when the action is a list.",
+      "items": {},
+      "type": "array"
+    },
+    "limit": {
+      "description": "Page size (list actions).",
+      "type": "number"
+    },
+    "message": {
+      "description": "Human-readable error or status detail, when present.",
+      "type": "string"
+    },
+    "page": {
+      "description": "Current page number (list actions).",
+      "type": "number"
+    },
+    "result": {
+      "description": "Wraps a non-object response body (e.g. a QR code string)."
+    },
+    "total": {
+      "description": "Total matching records across all pages (list actions).",
+      "type": "number"
+    },
+    "totalPages": {
+      "description": "Total number of pages (list actions).",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
    • Changedtracepass_passport_fields6 fields changed
      • addedInput schema / properties / action / description
        Added value: +"Update one passport field, addressed by passport id (update) or by your serial (update_by_serial)."
      • removedInput schema / properties / args / additionalProperties
        Removed value: -{}
      • changedInput schema / properties / args / description
        Previous value: -"Action-specific arguments — see the description."New value: +"Arguments for the chosen action; required fields depend on `action`."
      • addedInput schema / properties / args / properties
        Added value: +{
+  "fieldKey": {
+    "description": "The field key to set (required).",
+    "type": "string"
+  },
+  "gtin": {
+    "description": "GTIN disambiguator for update_by_serial when the serial isn't unique (else 409).",
+    "type": "string"
+  },
+  "id": {
+    "description": "Passport id. Required for update.",
+    "type": "string"
+  },
+  "serial": {
+    "description": "Your serial. Required for update_by_serial.",
+    "type": "string"
+  },
+  "value": {
+    "description": "The new value for the field (required). Type depends on the field's dataType."
+  }
+}
      • removedInput schema / properties / args / propertyNames
        Removed value: -{
-  "type": "string"
-}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "error": {
+      "description": "Machine-readable error code, when the API rejected the request.",
+      "type": "string"
+    },
+    "id": {
+      "description": "The resource's TracePass id, when the response is a single entity.",
+      "type": "string"
+    },
+    "items": {
+      "description": "The page of results, when the action is a list.",
+      "items": {},
+      "type": "array"
+    },
+    "limit": {
+      "description": "Page size (list actions).",
+      "type": "number"
+    },
+    "message": {
+      "description": "Human-readable error or status detail, when present.",
+      "type": "string"
+    },
+    "page": {
+      "description": "Current page number (list actions).",
+      "type": "number"
+    },
+    "result": {
+      "description": "Wraps a non-object response body (e.g. a QR code string)."
+    },
+    "total": {
+      "description": "Total matching records across all pages (list actions).",
+      "type": "number"
+    },
+    "totalPages": {
+      "description": "Total number of pages (list actions).",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
    • Changedtracepass_passport_parties6 fields changed
      • addedInput schema / properties / action / description
        Added value: +"Set (add/replace) or remove an economic-operator party on a passport by its role."
      • removedInput schema / properties / args / additionalProperties
        Removed value: -{}
      • changedInput schema / properties / args / description
        Previous value: -"Action-specific arguments — see the description."New value: +"Arguments for the chosen action; required fields depend on `action`."
      • addedInput schema / properties / args / properties
        Added value: +{
+  "country": {
+    "description": "Party country code (set, optional).",
+    "type": "string"
+  },
+  "gln": {
+    "description": "GS1 Global Location Number for the party (set, optional).",
+    "type": "string"
+  },
+  "id": {
+    "description": "Passport id (required).",
+    "type": "string"
+  },
+  "legacyOperatorId": {
+    "description": "Your internal operator id for the party (set, optional).",
+    "type": "string"
+  },
+  "legalName": {
+    "description": "Party legal name. Required for set.",
+    "type": "string"
+  },
+  "role": {
+    "description": "Economic-operator role, e.g. manufacturer | importer | distributor | authorised_representative (required).",
+    "type": "string"
+  }
+}
      • removedInput schema / properties / args / propertyNames
        Removed value: -{
-  "type": "string"
-}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "error": {
+      "description": "Machine-readable error code, when the API rejected the request.",
+      "type": "string"
+    },
+    "id": {
+      "description": "The resource's TracePass id, when the response is a single entity.",
+      "type": "string"
+    },
+    "items": {
+      "description": "The page of results, when the action is a list.",
+      "items": {},
+      "type": "array"
+    },
+    "limit": {
+      "description": "Page size (list actions).",
+      "type": "number"
+    },
+    "message": {
+      "description": "Human-readable error or status detail, when present.",
+      "type": "string"
+    },
+    "page": {
+      "description": "Current page number (list actions).",
+      "type": "number"
+    },
+    "result": {
+      "description": "Wraps a non-object response body (e.g. a QR code string)."
+    },
+    "total": {
+      "description": "Total matching records across all pages (list actions).",
+      "type": "number"
+    },
+    "totalPages": {
+      "description": "Total number of pages (list actions).",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
    • Changedtracepass_passports6 fields changed
      • addedInput schema / properties / action / description
        Added value: +"Which passport operation to run. Reads: list | get | get_by_serial | compliance | get_qr. Lifecycle: create (BILLABLE) | suspend (reversible) | archive (IRREVERSIBLE), each with a _by_serial variant."
      • removedInput schema / properties / args / additionalProperties
        Removed value: -{}
      • changedInput schema / properties / args / description
        Previous value: -"Action-specific arguments — see the description for each action's shape."New value: +"Arguments for the chosen action; required fields depend on `action` (see each action above)."
      • addedInput schema / properties / args / properties
        Added value: +{
+  "confirmOverage": {
+    "description": "Set true to accept a per-passport overage charge when create is over the plan quota (402).",
+    "type": "boolean"
+  },
+  "format": {
+    "description": "get/get_by_serial: summary|full. get_qr: svg|png.",
+    "type": "string"
+  },
+  "gtin": {
+    "description": "GTIN disambiguator for *_by_serial actions when a serial isn't unique across GTINs (else 409 ambiguous_serial).",
+    "type": "string"
+  },
+  "id": {
+    "description": "Passport id. Required for get/compliance/create-result/suspend/archive/get_qr (the by-id actions).",
+    "type": "string"
+  },
+  "lang": {
+    "description": "Resolve field values to one of the 24 EU locales server-side (get/get_by_serial).",
+    "type": "string"
+  },
+  "limit": {
+    "description": "Page size for list, max 100.",
+    "type": "number"
+  },
+  "page": {
+    "description": "Page number for list (1-based).",
+    "type": "number"
+  },
+  "productId": {
+    "description": "Parent product id. Required for create.",
+    "type": "string"
+  },
+  "search": {
+    "description": "Filter list by a search term.",
+    "type": "string"
+  },
+  "serial": {
+    "description": "Your own serial number. Required for the *_by_serial actions.",
+    "type": "string"
+  },
+  "serialNumber": {
+    "description": "Serial for the new passport. Required for create.",
+    "type": "string"
+  },
+  "status": {
+    "description": "Filter list by status: draft|in_review|approved|published|suspended|expired|archived.",
+    "type": "string"
+  }
+}
      • removedInput schema / properties / args / propertyNames
        Removed value: -{
-  "type": "string"
-}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "error": {
+      "description": "Machine-readable error code, when the API rejected the request.",
+      "type": "string"
+    },
+    "id": {
+      "description": "The resource's TracePass id, when the response is a single entity.",
+      "type": "string"
+    },
+    "items": {
+      "description": "The page of results, when the action is a list.",
+      "items": {},
+      "type": "array"
+    },
+    "limit": {
+      "description": "Page size (list actions).",
+      "type": "number"
+    },
+    "message": {
+      "description": "Human-readable error or status detail, when present.",
+      "type": "string"
+    },
+    "page": {
+      "description": "Current page number (list actions).",
+      "type": "number"
+    },
+    "result": {
+      "description": "Wraps a non-object response body (e.g. a QR code string)."
+    },
+    "total": {
+      "description": "Total matching records across all pages (list actions).",
+      "type": "number"
+    },
+    "totalPages": {
+      "description": "Total number of pages (list actions).",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
    • Changedtracepass_products6 fields changed
      • addedInput schema / properties / action / description
        Added value: +"Which product operation to run: list | get | create | update."
      • removedInput schema / properties / args / additionalProperties
        Removed value: -{}
      • changedInput schema / properties / args / description
        Previous value: -"Action-specific arguments — see the description for each action's shape."New value: +"Arguments for the chosen action; required fields depend on `action` (see each action above)."
      • addedInput schema / properties / args / properties
        Added value: +{
+  "category": {
+    "description": "DPP category for create: battery | textile | electronics | construction | steel | chemicals | packaging | furniture | tyres | jewelry | toys | fmcg.",
+    "type": "string"
+  },
+  "description": {
+    "description": "Free-text product description (create/update).",
+    "type": "string"
+  },
+  "id": {
+    "description": "Product id. Required for get and update.",
+    "type": "string"
+  },
+  "limit": {
+    "description": "Page size for list, max 100.",
+    "type": "number"
+  },
+  "model": {
+    "description": "Manufacturer model / SKU. Required for create; optional on update.",
+    "type": "string"
+  },
+  "name": {
+    "description": "Product name. Required for create; optional on update.",
+    "type": "string"
+  },
+  "page": {
+    "description": "Page number for list (1-based).",
+    "type": "number"
+  },
+  "search": {
+    "description": "Filter list by a search term.",
+    "type": "string"
+  },
+  "status": {
+    "description": "Filter list by product status.",
+    "type": "string"
+  }
+}
      • removedInput schema / properties / args / propertyNames
        Removed value: -{
-  "type": "string"
-}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "error": {
+      "description": "Machine-readable error code, when the API rejected the request.",
+      "type": "string"
+    },
+    "id": {
+      "description": "The resource's TracePass id, when the response is a single entity.",
+      "type": "string"
+    },
+    "items": {
+      "description": "The page of results, when the action is a list.",
+      "items": {},
+      "type": "array"
+    },
+    "limit": {
+      "description": "Page size (list actions).",
+      "type": "number"
+    },
+    "message": {
+      "description": "Human-readable error or status detail, when present.",
+      "type": "string"
+    },
+    "page": {
+      "description": "Current page number (list actions).",
+      "type": "number"
+    },
+    "result": {
+      "description": "Wraps a non-object response body (e.g. a QR code string)."
+    },
+    "total": {
+      "description": "Total matching records across all pages (list actions).",
+      "type": "number"
+    },
+    "totalPages": {
+      "description": "Total number of pages (list actions).",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
    • Changedtracepass_templates6 fields changed
      • addedInput schema / properties / action / description
        Added value: +"List all DPP category templates, or get one template by category."
      • removedInput schema / properties / args / additionalProperties
        Removed value: -{}
      • changedInput schema / properties / args / description
        Previous value: -"Action-specific arguments — see the description for each action's shape."New value: +"Arguments for the chosen action; `category` is required for get, ignored for list."
      • addedInput schema / properties / args / properties
        Added value: +{
+  "category": {
+    "description": "DPP category to fetch (required for get): battery | textile | electronics | construction | steel | chemicals | packaging | furniture | tyres | jewelry | toys | fmcg.",
+    "type": "string"
+  }
+}
      • removedInput schema / properties / args / propertyNames
        Removed value: -{
-  "type": "string"
-}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "error": {
+      "description": "Machine-readable error code, when the API rejected the request.",
+      "type": "string"
+    },
+    "id": {
+      "description": "The resource's TracePass id, when the response is a single entity.",
+      "type": "string"
+    },
+    "items": {
+      "description": "The page of results, when the action is a list.",
+      "items": {},
+      "type": "array"
+    },
+    "limit": {
+      "description": "Page size (list actions).",
+      "type": "number"
+    },
+    "message": {
+      "description": "Human-readable error or status detail, when present.",
+      "type": "string"
+    },
+    "page": {
+      "description": "Current page number (list actions).",
+      "type": "number"
+    },
+    "result": {
+      "description": "Wraps a non-object response body (e.g. a QR code string)."
+    },
+    "total": {
+      "description": "Total matching records across all pages (list actions).",
+      "type": "number"
+    },
+    "totalPages": {
+      "description": "Total number of pages (list actions).",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
  6. 3 tool updates
    • Changedtracepass_epcis1 field changed
      • changedInput schema / properties / action / enum
        Previous value: -[
-  "export",
-  "capture",
-  "capture_job",
-  "query"
-]New value: +[
+  "export",
+  "export_by_serial",
+  "capture",
+  "capture_job",
+  "query"
+]
    • Changedtracepass_passport_fields1 field changed
      • changedInput schema / properties / action / enum
        Previous value: -[
-  "update"
-]New value: +[
+  "update",
+  "update_by_serial"
+]
    • Changedtracepass_passports1 field changed
      • changedInput schema / properties / action / enum
        Previous value: -[
-  "list",
-  "get",
-  "get_by_serial",
-  "compliance",
-  "create",
-  "suspend",
-  "archive",
-  "get_qr"
-]New value: +[
+  "list",
+  "get",
+  "get_by_serial",
+  "compliance",
+  "create",
+  "suspend",
+  "suspend_by_serial",
+  "archive",
+  "archive_by_serial",
+  "get_qr"
+]
  7. 1 tool update
    • Changedtracepass_passports1 field changed
      • changedInput schema / properties / action / enum
        Previous value: -[
-  "list",
-  "get",
-  "get_by_serial",
-  "create",
-  "suspend",
-  "archive",
-  "get_qr"
-]New value: +[
+  "list",
+  "get",
+  "get_by_serial",
+  "compliance",
+  "create",
+  "suspend",
+  "archive",
+  "get_qr"
+]
  8. 6 tool updates
    • First observedtracepass_epcis
    • First observedtracepass_passport_fields
    • First observedtracepass_passport_parties
    • First observedtracepass_passports
    • First observedtracepass_products
    • First observedtracepass_templates

Related MCP Connectors

Related MCP Servers

  • product-crud-mcp

    saurabhx04
    F
    license
    Not graded
    quality
    C
    maintenance
    Exposes CRUD operations for products via MCP tools and a resource, sharing a common business logic layer with a GraphQL API.
    -

  • ro.autoid/autoid-support

    AutoID-Alex
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to search enterprise Auto-ID products and exact SKUs, read live stock and current pricing, and explore variants, accessories, consumables and support relationships through a public read-only endpoint. It also surfaces manuals, firmware, drivers and other verified technical resources from the vendor's support center.
    -
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources