Skip to main content
Glama
malinoto

tracepass-mcp-server

by malinoto

TracePass passport fields

tracepass_passport_fields
Idempotent

Update field values on a Digital Product Passport by ID or serial; every change is recorded in the audit trail.

Instructions

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.

Input Schema

TableJSON 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

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

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

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