TracePass

TracePass passport fields

tracepass_passport_fields

Idempotent

Update field values on a Digital Product Passport. Every change is recorded in the passport's audit trail with the credential that made it (API key or connected app) and this MCP channel.

source (optional) says where the value came from. Omit it, or pass "manual", when the user gave you the value or it comes from their own records: it is written with the user's rights (approved for an API key or an admin; sent to review for a connected app acting for an editor). Pass "ai_suggested" when you found or inferred the value yourself (web research, reading a document): it lands in the dashboard review queue for a human to approve, and it is refused on fields only the economic operator may state or that must be measured (e.g. battery stateOfHealth).

Actions (pass via action, with args):

update — args: { id, fieldKey, value, source? }. value type matches the field's dataType (string, number, boolean, array, object).
update_by_serial — args: { serial, fieldKey, value, gtin?, source? }. 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

Name	Required	Description	Default
`args`	No	Arguments for the chosen action; required fields depend on `action`.
`action`	Yes	Update one passport field, addressed by passport id (update) or by your serial (update_by_serial).

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No	The resource's TracePass id, when the response is a single entity.
`page`	No	Current page number (list actions).
`error`	No	Machine-readable error code, when the API rejected the request.
`items`	No	The page of results, when the action is a list.
`limit`	No	Page size (list actions).
`total`	No	Total matching records across all pages (list actions).
`result`	No	Wraps a non-object response body (e.g. a QR code string).
`message`	No	Human-readable error or status detail, when present.
`totalPages`	No	Total number of pages (list actions).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

addedInput schema / properties / args / properties / source

Added value: +{
+  "description": "Where the value came from: \"manual\" (default — the user's statement) or \"ai_suggested\" (you found it; it goes to human review).",
+  "enum": [
+    "manual",
+    "ai_suggested"
+  ],
+  "type": "string"
+}

Changed6 schema fields changedJun 14, 2026

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"
+}

Changed1 schema field changedJun 14, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "update"
-]New value: +[
+  "update",
+  "update_by_serial"
+]

First observedJun 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With only idempotentHint in the annotations, the description carries the behavioral burden well: it discloses the audit-trail recording (credential plus MCP channel), the human review queue behavior of ai_suggested values, refusal on operator-only or measured fields such as battery stateOfHealth, and the 409 ambiguous_serial failure mode. This is rich context beyond the structured fields.

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 dense but front-loaded with the core purpose, then organized into `source` semantics and an action list with per-action args. Nearly every sentence earns its place, though the action bullets partially restate parameter details already visible in the schema.

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?

An output schema exists, so return values need no explanation, and the description fully covers the mutation semantics, error path, and review behavior for a nested-argument tool with minimal annotations. Nothing an agent needs to invoke it correctly appears to be missing.

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 already 100%, so the baseline is 3, but the description adds real meaning: it explains the rights implications of each `source` value (approved for API key/admin, sent to review for connected apps), how `value` must match the field's dataType, and how `gtin` disambiguates a non-unique serial. That goes meaningfully beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource: 'Update field values on a Digital Product Passport,' which is more precise than the title alone. It is clear what the tool mutates, but it never contrasts itself with the related tracepass_passports sibling, so an agent must infer the boundary between editing fields and managing 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use rules for `source`: omit it or pass 'manual' when the user supplied the value or it comes from their own records, and pass 'ai_suggested' when the agent inferred it. It also explains when to prefer update_by_serial over update by id, and the 409 ambiguous_serial fallback condition, leaving little to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All TracePass tools Inspect

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.