com.yaktool/gs1
NPM · YAKTOOL-GS1-MCP · SCANNED SEP 25
GS1 element strings, DataMatrix, eight keys, ITF-14 print specs and price-embedded in-store codes.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- No production dependencies, so there is no dependency health to assess. View diagnostics → Pass
Provenance & Transparency19
- Repository check failed: no source repository is declared. See how to fix → View diagnostics → Fail
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 18 days ago).Pass
- Security-disclosure policy not yet verified: we couldn't inspect the source repository.Unverified
Schema Quality & AI Usability62
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 3716 tokens (~530/item across 7 items; 7 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 7 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 7 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the com.yaktool/gs1 MCP server?
com.yaktool/gs1 runs locally as an npm package, launched with npx -y yaktool-gs1-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · yaktool-gs1-mcp
claude mcp add com-yaktool-gs1 -- npx -y yaktool-gs1-mcp
{
"mcpServers": {
"com-yaktool-gs1": {
"command": "npx",
"args": [
"-y",
"yaktool-gs1-mcp"
]
}
}
} {
"servers": {
"com-yaktool-gs1": {
"command": "npx",
"args": [
"-y",
"yaktool-gs1-mcp"
]
}
}
} codex mcp add com-yaktool-gs1 -- npx -y yaktool-gs1-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-yaktool-gs1": {
"type": "local",
"command": [
"npx",
"-y",
"yaktool-gs1-mcp"
],
"enabled": true
}
}
} openclaw mcp add com-yaktool-gs1 --command npx --arg -y --arg yaktool-gs1-mcp
mcp_servers:
com-yaktool-gs1:
command: "npx"
args: ["-y", "yaktool-gs1-mcp"] {
"McpServers": {
"com-yaktool-gs1": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"yaktool-gs1-mcp"
]
}
}
} assistant mcp add com-yaktool-gs1 -t stdio -c npx -a -y yaktool-gs1-mcp
{
"mcpServers": {
"com-yaktool-gs1": {
"command": "npx",
"args": [
"-y",
"yaktool-gs1-mcp"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 25 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 24 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 22 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.
- 20 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 18 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 73 to 77. That category is still filling its 30-day observation window: 22 days of observed history at the previous scan, 23 at this one. The score rises as the window fills, whether or not the server changes.
- 16 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 67 to 70. That category is still filling its 30-day observation window: 20 days of observed history at the previous scan, 21 at this one. The score rises as the window fills, whether or not the server changes.
- 14 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.
- 12 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 25 Sept 2026 · Analysed npm/yaktool-gs1-mcp@0.3.0
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Background: How many MCP packages publish verified provenance →
Dependencies 0 packages
| Packages resolved | 0 |
|---|---|
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
build_gs1_element_string Build a GS1-128 element string from application identifiers ~462
The inverse of parse_gs1_element_string: turn AI/value pairs into the string a barcode actually carries. THREE FORMS come back and only one of them is the data: `hri` is the human-readable form with brackets — never encode those; `data` is the real payload where FNC1 is the ASCII group separator (U+001D); `visible` is the same payload with FNC1 shown as <GS> so it survives being pasted into a chat or a ticket. Separator rule, both halves: a variable-length element is closed by FNC1 UNLESS it is the last element — omitting it runs two fields together, and adding a trailing one makes the symbol non-conformant. Predefined-length AIs never take a separator. By default predefined-length AIs are moved to the front, which removes separators from the middle; pass keepOrder to encode exactly as given. The data is identical either way. Values are validated before anything is produced (unknown AI, duplicate AI, wrong length, bad character set, invalid YYMMDD date, wrong GTIN/SSCC check digit, over 48 data characters) and NO string is returned when a check fails: a barcode that scans into the wrong thing is worse than none. Every output is parsed back with the same engine and compared element by element — see `roundTrip`. Input accepts structured elements, or use the `text` field for a free-form paste: "(01)…(10)…", one "AI value" per line, or a raw scanned string with real GS characters. Returns { hri, data, visible, segments[{ai, value, title, fixed, separatorAfter}], dataLength, reordered, roundTrip{ok, detail}, findings[], ok }.
| Name | Type | Req | Description |
|---|---|---|---|
| elements | array | – | Structured elements, e.g. [{ai:"01",value:"04006381333931"},{ai:"10",value:"LOT-A"}]. |
| keepOrder | boolean | – | Encode in the given order instead of moving predefined-length AIs to the front. |
| text | string | – | Free-form input instead of `elements`: bracketed HRI, one "AI value" per line, or a scanned string. |
No output schema declared.
No examples provided.
build_variable_measure_code Build a variable-measure barcode number with its price check digit ~649
The inverse of decode_variable_measure_code: from a national scheme, an item reference and a price or weight, produce the complete 13-digit number (and the 12-digit UPC-A form for prefix 02) with BOTH check digits computed — the price/measure verifier from GS1 General Specifications §7.9.3 (four-digit field: factors 2−,2−,3,5−, sum × 3, units digit) or §7.9.4 (five-digit field: factors 5+,2−,5−,5+,2−, complement to ten, reverse lookup in the 5− table), then the ordinary mod-10 check digit over the twelve. The standard's own worked examples (2875 → 9, 14685 → 6) are regression tests for this tool. Every weighted product is returned as a step so the calculation can be shown or audited, and the built number is what a scale or label printer should be configured to emit. Schemes: us = GS1 US (North America) (prefix 02); uk-branded = GS1 UK — branded variable measure (prefix 20/28); uk-instore = GS1 UK — in-store (prefix 02); au = GS1 Australia (VMN-13) (prefix 22/24/28/29); de = GS1 Germany (Spezialcode) (prefix 22/23/25/26/28/29); se = GS1 Sweden (Restricted Circulation Number) (prefix 20/21/22/23/24/25); gr = GS1 Greece (variable measure prefix) (prefix 25/26/27/28/29). Where a scheme's prefix decides the meaning of the field (Sweden 20–22 price / 23–25 weight; Germany 22/23 price, 25/26 count, 28/29 weight) `prefix` is required and the tool refuses to guess. Refuses (no number returned) when the item reference has the wrong length for the layout, when the value has more decimals than the scheme's implied decimal point, or when it does not fit the field — a label that scans into the wrong price is worse than no label. Returns { scheme, schemeName, prefix, layout, code, upcA?, segments[], value{digits, display}, verifier?{digits, algorithm, steps[{position, digit, factor, product}], sum, intermediate, checkDigit, finalStep}, checkDigit{payload, digit}, findings[], ok }.
| Name | Type | Req | Description |
|---|---|---|---|
| itemReference | string | yes | Item reference digits, exactly the length the scheme uses (5 for us/uk-branded/gr, 4 for uk-instore/au/de, 6 for se). |
| prefix | string | – | Two-digit GS1 prefix, e.g. "23"; required when the scheme has several with different meanings. |
| scheme | string | yes | National scheme to encode under. |
| value | number|string | yes | Price or measure in the scheme's unit, e.g. 28.75 or "1.234". |
No output schema declared.
No examples provided.
check_itf14_spec Check an ITF-14 case code print specification and compute its printed size ~796
Judge the PRINT SPECIFICATION of an ITF-14 carton barcode against the GS1 General Specifications (Release 26.0), and compute how big it will actually be. This is the layer the barcode generators skip: they draw the symbol, but a case code is rejected at goods-in for its dimensions far more often than for its number. THE BEARER BAR RULE DEPENDS ON THE PRESS, and getting this backwards is the main way a compliant label gets called non-conformant: a plate-based process needs a constant 4.83 mm bearer bar completely surrounding the symbol including its quiet zones (it equalises plate pressure); a plateless process (thermal, laser, offset label) needs only twice the narrow bar, top and bottom. Checks the GTIN-14 check digit, X-dimension against 0.495–1.016 mm, the 31.75 mm minimum bar height (which does NOT shrink with the symbol), 10X quiet zones each side, the 2.25:1–3.0:1 wide-to-narrow ratio, and warns when an X-dimension under 0.635 mm would be printed straight onto corrugate with a plate process. The width is computed from the standard’s own formula W = (P(4N+6)+N+6)X + 2Q, quiet zones included — the specification’s worked example (7 pairs, 2.5:1, X 1.016, Q 10.16 → 142.75 mm) is a regression test, so the number is the standard’s, not an estimate. WHAT IT DOES NOT DO: it does not grade print quality. The 1.5/10/660 in the specification is an ISO/IEC 15416 grade measured on a verifier at a stated aperture and wavelength; nothing computed from typed numbers can stand in for that, and this tool only states the requirement. It judges an intended specification, not artwork or a photograph. Where the standard allows a bearer bar to be omitted when "not technically feasible", that feasibility is the caller’s judgement — the omission is flagged, not excused. Returns { footprint{width{mm,inch},height{mm,inch}}, quietZone{mm,inch}, resolved{xDimension,ratio,barHeight,quietZone}, findings[{ruleId,severity,message,fix,sourceUrl}], conforms, qualitySpecification }.
| Name | Type | Req | Description |
|---|---|---|---|
| barHeight | number | – | Bar height in millimetres, excluding human readable digits and bearer bars. Defaults to the 31.75 mm minimum. |
| bearerBar | string | yes | Bearer bar layout: fully surrounding, top and bottom only, or absent. |
| bearerBarThickness | number | – | Bearer bar thickness in millimetres. Omit to skip the thickness rules rather than have them guessed. |
| bearerToHriGap | number | – | Gap between the bearer bar and the human readable digits, in millimetres. Minimum 1.02. |
| directOnCorrugate | boolean | – | True when the symbol is printed straight onto corrugate rather than onto an applied label. |
| gtin | string | – | The GTIN-14 the symbol carries; its check digit is verified when given. |
| printMethod | string | yes | "plate" for presses needing printing plates (flexo direct on carton), "plateless" for thermal, laser or offset labels. Decides which bearer bar rule applies. |
| quietZone | number | – | Quiet zone each side in millimetres. Defaults to 10X. |
| ratio | number | – | Wide-to-narrow ratio, 2.25 to 3.0. Defaults to the 2.5 target. |
| xDimension | number | yes | Width of a narrow element (X) in millimetres. Required — everything else scales off it. |
No output schema declared.
No examples provided.
decode_variable_measure_code Decode a variable-measure (price- or weight-embedded) in-store barcode ~723
Decode an RCN-12 / RCN-13 — the 02 or 20–29 number a scale prints on a deli, produce or butcher label — into item reference, embedded price or weight, and the two check digits it carries. WHY THIS IS NOT A GTIN VALIDATOR: prefixes 02 and 20–29 are Restricted Circulation Numbers whose layout is set by each GS1 member organisation, so the same 13 digits mean different things in different countries (22 is a five-digit AUD price with a verifier in Australia and an integer SEK price without one in Sweden). The tool decodes under every documented scheme whose prefix matches and lists them side by side; pass `scheme` to pin one. Documented schemes: us = GS1 US (North America) (prefix 02); uk-branded = GS1 UK — branded variable measure (prefix 20/28); uk-instore = GS1 UK — in-store (prefix 02); au = GS1 Australia (VMN-13) (prefix 22/24/28/29); de = GS1 Germany (Spezialcode) (prefix 22/23/25/26/28/29); se = GS1 Sweden (Restricted Circulation Number) (prefix 20/21/22/23/24/25); gr = GS1 Greece (variable measure prefix) (prefix 25/26/27/28/29). THE VERIFIER DIGIT IS THE KEY: North America, the UK, Australia and Germany put a price check digit between the item reference and the price, computed with the GS1 weighting factors 2−, 3, 5+ and 5− (General Specifications §7.9.3/7.9.4 — not the mod-10 of the last digit). Readings whose verifier matches come first and `consistent` lists them; a scheme without a verifier (Sweden, Greece) can never be ruled out by the digits alone, which the result says rather than hides. Also returns the four GS1-recommended generic layouts (Table 2-29) for countries not on the list, the UPC-A ↔ 13-digit normalisation, and always the reminder that an RCN cannot be listed as a product GTIN on a marketplace. Decimal positions are those stated by each member organisation; the North American two-decimal reading is marked as an assumption; German weight/count fields come back as raw digits because the guide gives no unit. Pass `values` (up to 1000) for a bat…
| Name | Type | Req | Description |
|---|---|---|---|
| scheme | string | – | Pin a national scheme instead of showing every scheme that fits the prefix. |
| value | string | – | One 13-digit EAN-13 (02…/2X…) or 12-digit UPC-A (2…) number; spaces and hyphens are tolerated. |
| values | array | – | Batch alternative to `value`: one number per element. |
No output schema declared.
No examples provided.
generate_gs1_datamatrix Generate a GS1 DataMatrix (ECC200) from application identifiers ~494
Build a GS1 DataMatrix symbol and return it as SVG plus the module matrix. WHAT MAKES IT A *GS1* DataMatrix: FNC1 in the first position (codeword 232). Without it the symbol is a plain DataMatrix carrying digits and no scanner has any reason to read 0104006381333931 as a GTIN; with it the scanner emits the ]d2 symbology identifier and downstream systems split the data into AIs. This tool always sets it. The element string is validated BEFORE anything is drawn (unknown AI, wrong length, bad check digit, invalid date, character set) and no symbol is returned when a check fails — a symbol that scans into a wrong GTIN is worse than a blank label. Sizing is the decision that matters: the result carries `size` in modules and, for the X-dimension you pass, the printed side in millimetres. GS1 gives 0.396–0.990 mm for general distribution. The quiet zone for DataMatrix is ONE module on each side (not the 10X a linear symbol needs) and it is included in the SVG. Encoder limits, stated rather than hidden: ASCII encodation only, so mixed letter/digit data may produce a symbol one size larger than a C40-capable encoder (the data is identical and any scanner reads it); square symbols up to 52×52, beyond which it refuses with the reason. The encoder is verified in CI against two independent implementations: bwip-js module-by-module, and zxing decoding a rasterised image back to the original string. Returns { svg, size, modules (boolean rows), spec{dataCodewords, ecCodewords}, printedSizeMm, hri, data, codewords{data, ec}, findings[], ok }.
| Name | Type | Req | Description |
|---|---|---|---|
| elements | array | – | Structured AI/value pairs, e.g. [{ai:"01",value:"04006381333931"}]. |
| moduleSize | number | – | SVG module size in px (default 8). Cosmetic only — it does not change the symbol. |
| text | string | – | Free-form alternative to `elements`: "(01)…(17)…", or one "AI value" per line. |
| xDimensionMm | number | – | Module size in millimetres for the printed-size calculation (default 0.5). |
No output schema declared.
No examples provided.
list_gs1_keys List the GS1 identification keys and their syntax ~138
Return the GS1 keys this server can validate, each with the application identifiers that carry it, what it identifies, and its syntax as written in the GS1 Barcode Syntax Dictionary (for example "N1,zero N13,csum [X..16]" for GRAI). Useful before validating: it tells you which key a given AI belongs to, which keys carry a check digit, and which two (GIAI, GINC) carry none at all. Returns { keys[{key, ais, name, identifies, syntax, hasCheckDigit, hasCheckPair, numericLength?, maxLength?}] }.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
validate_gs1_extended_key Validate GRAI, GIAI, GSRN, GDTI, GINC, GSIN, GCN or GMN ~454
Validate the eight GS1 keys beyond SSCC and GLN (those two live in validate_gs1_key). The key type must be given: several of these share a length, so guessing would be wrong more often than right. Formats come from the GS1 Barcode Syntax Dictionary, GS1's own machine-readable source: GRAI = a literal 0 plus 13 digits with a check digit plus an optional 16-character serial; GIAI = up to 30 characters, NO check digit; GSRN (8017 provider / 8018 recipient) = 18 digits with a check digit; GDTI = 13 digits with a check digit plus an optional 17-character serial; GINC = up to 30 characters, NO check digit; GSIN = 17 digits with a check digit; GCN = 13 digits with a check digit plus an optional 12-digit serial; GMN = up to 25 characters ending in a CHECK CHARACTER PAIR. Two things agents get wrong here. (1) GIAI and GINC have no check digit at all — a typo in them is undetectable from the value, and this tool says so rather than implying validity means correctness. (2) A GMN does not end in a check DIGIT: it ends in two check CHARACTERS computed with prime weights modulo 1021 and drawn from GS1 character set 32 (no I, O, 0 or 1). The GMN is also the Basic UDI-DI for EU medical devices, so getting it wrong is a regulatory problem, not a cosmetic one. Whitespace inside a value is reported as an invalid character rather than silently removed — stripping it would turn an invalid identifier into a valid-looking one while the value in the user's system stays broken. Returns { input, normalized, key, valid, base?, serial?, definition{name, ais, identifies, syntax}, findings[] }.
| Name | Type | Req | Description |
|---|---|---|---|
| key | string | yes | Which key this value is meant to be. Required — several of these share a length. |
| value | string | yes | The key, with or without its AI prefix such as "(8003)". |
No output schema declared.
No examples provided.
What is the com.yaktool/gs1 MCP server?
com.yaktool/gs1 is an MCP server listed in the public MCP registry as com.yaktool/gs1. GS1 element strings, DataMatrix, eight keys, ITF-14 print specs and price-embedded in-store codes. This page covers its npm package (yaktool-gs1-mcp).
Is the com.yaktool/gs1 MCP server safe to use?
com.yaktool/gs1 scores 77 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 25 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the com.yaktool/gs1 MCP server expose?
com.yaktool/gs1 exposes 7 tools: build_gs1_element_string, generate_gs1_datamatrix, validate_gs1_extended_key, list_gs1_keys, check_itf14_spec, and 2 more. Their descriptions and schemas cost roughly 3,716 tokens of context every time the server is loaded.
Is the com.yaktool/gs1 MCP server still maintained?
com.yaktool/gs1 is still listed as active in the MCP registry. We last reached this channel on 25 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the com.yaktool/gs1 MCP server under?
com.yaktool/gs1 declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.