barcode-mcp

Encode EPC (UHF RFID)

encode_epc

Encode SGTIN-96, SSCC-96, or GIAI-96 EPCs for UHF RFID tags, returning EPC hex, tag URI, and 96-bit binary from a GS1 company prefix, reference, and optional serial.

Instructions

Encode an SGTIN-96, SSCC-96 or GIAI-96 EPC for UHF RFID tags from a GS1 company prefix, reference and (for SGTIN) serial. Returns the EPC hex, EPC tag URI and 96-bit binary. This computes the value to write to a tag; it does not program a physical tag.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "scheme": "<scheme>",
      "companyPrefix": "<companyPrefix>",
      "reference": "<reference>"
    },
    "name": "encode_epc"
  }
}

Input Schema

Name	Required	Description
`filter`	No	Filter value 0-7 (default 1 for SGTIN, 0 otherwise)
`scheme`	Yes	EPC scheme
`serial`	No	SGTIN only: numeric serial (0 to 274877906943)
`reference`	Yes	SGTIN: item reference incl. indicator digit; SSCC: serial reference incl. extension digit; GIAI: individual asset reference
`companyPrefix`	Yes	GS1 company prefix, 6-12 digits

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Jul 31, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states the tool computes a value and does not physically program a tag, and it lists the outputs (EPC hex, tag URI, binary). It does not cover potential validation errors or edge cases, but for a pure computation tool, the key behavioral traits are disclosed.

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 two sentences long and front-loaded with the action and target. It efficiently states the inputs, outputs, and a crucial caveat without redundancy or fluff. Every sentence adds value.

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?

Although there is no output schema, the description explicitly states the return values (EPC hex, tag URI, and 96-bit binary), which is essential for a tool with no structured response definition. It also clarifies the scope (computes, not physically writes). It does not provide examples or detailed scheme-specific guidance, but given the schema richness, it is sufficiently complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage for all five parameters, each with detailed descriptions. The tool description adds minimal extra meaning beyond naming the inputs in prose. Since the schema does the heavy lifting, a baseline score of 3 is appropriate.

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 begins with a specific verb 'Encode' and clearly identifies the resource (SGTIN-96, SSCC-96, or GIAI-96 EPC for UHF RFID tags). It lists the exact input types and distinguishes itself from sibling tools that deal with barcodes/QR codes rather than RFID EPC encoding.

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 implies when to use this tool: for computing EPC values for UHF RFID tags. It explicitly states what it does not do ('does not program a physical tag'), providing a clear exclusion. However, it does not name alternative tools or compare itself to siblings, though siblings are clearly different in purpose.

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

Deploy Server