Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

com.yaktool/compliance

NPM · YAKTOOL-COMPLIANCE-MCP · SCANNED SEP 25

GPSR, EUDR plots, nutrition labels, fragrance allergens, CPSC and EU conformity declarations.

+3 this week 77 Trust /100
Trust breakdown (7 categories)

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
Schema Quality & AI Usability62
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 4715 tokens (~523/item across 9 items; 9 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 9 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 9 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
Install

How do I install the com.yaktool/compliance MCP server?

com.yaktool/compliance runs locally as an npm package, launched with npx -y yaktool-compliance-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-compliance-mcp

# add to Claude Code
claude mcp add com-yaktool-compliance -- npx -y yaktool-compliance-mcp
// .cursor/mcp.json
{
  "mcpServers": {
    "com-yaktool-compliance": {
      "command": "npx",
      "args": [
        "-y",
        "yaktool-compliance-mcp"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "com-yaktool-compliance": {
      "command": "npx",
      "args": [
        "-y",
        "yaktool-compliance-mcp"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add com-yaktool-compliance -- npx -y yaktool-compliance-mcp
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-yaktool-compliance": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "yaktool-compliance-mcp"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add com-yaktool-compliance --command npx --arg -y --arg yaktool-compliance-mcp
# ~/.hermes/config.yaml
mcp_servers:
  com-yaktool-compliance:
    command: "npx"
    args: ["-y", "yaktool-compliance-mcp"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "com-yaktool-compliance": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "yaktool-compliance-mcp"
      ]
    }
  }
}
# add to Vellum
assistant mcp add com-yaktool-compliance -t stdio -c npx -a -y yaktool-compliance-mcp
// mcp.json
{
  "mcpServers": {
    "com-yaktool-compliance": {
      "command": "npx",
      "args": [
        "-y",
        "yaktool-compliance-mcp"
      ]
    }
  }
}
Changelog

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.

Diagnostics

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-compliance-mcp@0.4.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 →

MCP tools · 9 exposed · ~4,715 tokens

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 →

Tool Tokens
check_cpsc_certificate ~708

Check a Children's Product Certificate or General Certificate of Conformity against the 12 elements 16 CFR Part 1110 requires. THE TEXT YOU ARE PROBABLY REMEMBERING IS OUT OF DATE. The eFiling final rule rewrote § 1110.11 and has been in force since 2026-07-08; almost every template and guidance article in circulation — and the CFR annual-edition snapshots — still describe the 2008 text. Three differences decide most failures: (1) a unique identifier is now mandatory (GTIN, model number, registered number, serial number, SKU, UPC or an alternate identifier) where a description used to be enough; (2) ALL FOUR parties now need an email address, where the old text asked for one only from the records custodian, so a carried-over template is missing it on three parties at once; (3) there is now a prescribed attestation whose wording includes the acknowledgement that a materially false statement is a federal crime — a paraphrase is not it. FOUR OF THE SEVEN ELEMENTS ARE PARTIES and they are routinely conflated: the finished product certifier (a)(3), the individual maintaining records (a)(4), the place of manufacture (a)(5), and the third party conformity assessment body (a)(6). Each needs name, street address, city, state or province, country or region, email and telephone. The classic error is naming the foreign factory as the certifier: § 1110.7 puts a US party there — the importer for imports, the manufacturer or private labeler for domestic goods. It VALIDATES the check digit when the identifier is a GTIN or UPC, so a transcribed-wrong barcode surfaces here rather than at entry. Honesty contract to pass on when reporting: street, city and state are judged as ONE cell per party with three states — ok, missing, and "unclear" meaning address-like text was found but could not be confirmed from free text. "unclear" is NOT "missing". Email, telephone and country are judged reliably. Out of scope, deliberately: which rules apply to a given product (that is a judgement about…

NameTypeReqDescription
efiledboolean–True when this certificate is eFiled — the attestation then comes from the Product Registry and CATAIR rather than the document, so it is not required in the text.
importedboolean–Whether the goods are imported. Inferred from the place of manufacture when omitted; it decides who § 1110.7 puts on the certificate.
textstringyesThe certificate as written, one field per line (for example "Certifier: ...", "Records custodian: ...", "Manufactured: ...", "Tested: ...").

No output schema declared.

No examples provided.

check_eu_declaration_of_conformity ~723

Check a Declaration of Conformity against the numbered items its applicable annex requires, using 14 documented rules across 8 annexes taken from the primary EUR-Lex texts. DO NOT CHECK IT AGAINST "THE EIGHT ELEMENTS". Those eight are Annex III of Decision 768/2008/EC, which is a MODEL that sector legislation adapts; the annex that binds a product is the one in its own directive, and they differ in ways that produce FALSE POSITIVES if you use the generic list: (1) Annex IV of the LVD (2014/35/EU) and Annex VI of RoHS (2011/65/EU) have NO NOTIFIED BODY ITEM AT ALL — conformity there rests on internal production control, so "missing notified body" is wrong for them, and a notified body named against those alone is itself a signal the wrong template was used; (2) THE DECLARATION NUMBER IS OPTIONAL under RED, EMC, LVD, PPE and Machinery — each of those annexes carries a footnote saying so — while under the NLF model and the Toy Safety Directive it is point 1; (3) TOYS ARE THE ONE PLACE A COLOUR IMAGE IS MANDATORY: Annex III of 2009/48/EC says the object of the declaration "shall include a colour image of sufficient clarity"; every other annex says "may"; (4) HOW A STANDARD IS CITED IS ITSELF REGULATED — RED wants identification number, version AND date of issue; EMC and PPE want the date of the standard; Machinery wants the date the reference was published in the Official Journal plus which parts were applied if only partly used; the LVD asks for none of it. So "ETSI EN 300 328" is a defect under RED and fine under the LVD; (5) "EC" vs "EU" dates the template: Decision 768/2008/EC and the Toy Safety Directive say EC declaration of conformity, the 2014 alignment package and later say EU. The tool DETECTS which directives the declaration cites and checks against the UNION of those annexes, marking each item with which annex requires it. Pass directives[] only to override that. Honesty contract to pass on when reporting: a pasted text cannot carry a SIGNATURE or a COLOUR…

NameTypeReqDescription
directivesarray–Override which annexes to check against. Omit to use the directives the declaration itself cites — that is the normal path.
textstringyesThe declaration as written, ideally keeping its numbered items on separate lines.

No output schema declared.

No examples provided.

check_eu_nutrition_declaration ~736

Check a nutrition declaration for an EU pack against 13 documented rules, and return the range an official control accepts for every declared value. Pass `text` with the declaration EXACTLY as printed — the order of the lines is itself checked, and so is the presence of rows the declaration may not contain. Or pass `declared` for a structured call; both go through the same rules. THE ENERGY ROW IS THE POINT. Annex XIV gives kJ and kcal as two independent factor columns (carbohydrate 17 kJ/g AND 4 kcal/g; fat 37 and 9), so the kcal figure is NOT the kJ figure divided by 4.184 — that shortcut is flagged separately as EUN-005 because it looks like ordinary unit conversion and is the most common way the row goes wrong. Two definitions also differ from the US ones and both feed the energy calculation: carbohydrate INCLUDES polyols, so only the non-polyol part carries 17 kJ/g, and fibre is NOT part of carbohydrate but its own 8 kJ/g line. It catches what a US Nutrition Facts panel brings with it when the pack is ported: a trans fat or cholesterol row (the EU list of declarable nutrients is closed and has neither), a sodium row instead of salt (salt = sodium × 2.5, and the tool converts it), a per-serving basis with no per 100 g column, and values rounded on the US scale. SEVERITY IS SPLIT BY SOURCE, and reports should keep the split: errors come from the Regulation itself (Articles 30/31/32, Annexes I, XIV and XV); warnings and info come from the Commission guidance of December 2012 on rounding and tolerances, which states on its first page that it has no formal legal status. Add "(lab 8.34)" after a value in `text`, or pass `measured`, to test a laboratory result against the tolerance: the guidance widens the printed figure back to every value that rounds to it, applies the band for that nutrient at that level, and rounds the ends back — a declared 8.5 g of sugars accepts 6.5 to 11 g. Scope to state when reporting: no vitamins or minerals, no food-supplement or nutritio…

NameTypeReqDescription
basisstring–Overrides the basis read from the text.
declaredobject–Structured alternative to `text`: energyKj, energyKcal, fat, saturates, monounsaturates, polyunsaturates, carbohydrate, sugars, polyols, starch, fibre, protein, salt, sodium — grams per 100 g.
measuredobject–Unrounded laboratory values by the same keys, to drive the tolerance check and show what the label must print.
textstring–The declaration as printed, one nutrient per line. Needed for the order and forbidden-row checks.

No output schema declared.

No examples provided.

check_eudr_geojson ~464

Check an EUDR geolocation file against 24 rules taken from the European Commission's "EUDR GeoJSON File Description" — including the chapter of common file errors the Commission itself publishes. Due Diligence Statements are rejected for geometry far more often than for anything legal. Catches: unclosed polygon rings, rings with fewer than four positions, self-intersecting boundaries, polygons with holes, collinear coordinates that enclose no area, coordinates out of range (usually un-converted UTM metres), longitude/latitude written the wrong way round, coordinates that collapse into duplicates once rounded to six decimals, null-island 0,0 points, and the same coordinates reused across several plots. It MEASURES every polygon with a spherical-area formula and compares it against the declared Area property, which is how a unit mix-up (square metres or acres in a hectares field) surfaces — and that mix-up decides whether a plot may be a point at all: points stand in for plots of 4 ha or less, and a point with no Area is recorded by the system as 4 ha. Also validates ProducerCountry as an ISO 3166-1 alpha-2 code (UK is not one; GB is), property-name casing, quoted numbers in Area, point coordinates wrapped in an extra array, and the 25 MB submission limit. Honesty contract: on boundaries over 2000 vertices the self-intersection check is SKIPPED and those feature indexes are returned in summary.selfIntersectionSkipped — do not report those plots as fully checked. It does not judge deforestation and does not verify that coordinates fall inside the declared country. Returns { fileFindings[], features[{index, productionPlace, producerCountry, geometryType, declaredAreaHa, computedAreaHa, vertices, findings[], ok}], summary{features, points, polygons, invalidFeatures, totalAreaHa, duplicateGeometryGroups, selfIntersectionSkipped, byRule, ...} }.

NameTypeReqDescription
fileSizeBytesnumber–Real file size in bytes when known, for the 25 MB submission limit; otherwise it is computed from the text.
geojsonstringyesThe GeoJSON file contents as text (a FeatureCollection, or a single Feature).

No output schema declared.

No examples provided.

check_fragrance_allergens ~561

Convert a supplier's allergen certificate into concentrations in the finished cosmetic product and decide which substances must be named individually in the ingredient list (8 documented rules). THE ARITHMETIC IS THE POINT. A certificate says "4.2% Linalool" — that is 4.2% OF THE FRAGRANCE COMPOUND, not of the product. Dose the compound at 0.8% and the product contains 0.0336%, which is 33x the leave-on threshold. Dose it at 0.01% and the same certificate gives 0.00042%, below it. Comparing the certificate figure directly against the threshold gets both cases wrong, and it is the most common error in this area. Thresholds differ TENFOLD by product type: 0.001% for leave-on, 0.01% for rinse-off. When productType is omitted the stricter (leave-on) figure is used and the result says so — it does not quietly pick the more convenient answer. Pass `ingredientList` to also check that each declarable allergen actually appears in it; the tool reports the ones missing, and flags a separate "Contains:" box, which is not where the declaration belongs. IMPORTANT SCOPE NOTE to pass on: this tool does NOT carry the list of 80 declarable substances introduced by Regulation (EU) 2023/1545. That list could not be obtained from a verifiable machine-readable source (the Commission page states thresholds and deadlines but not the substances; EUR-Lex serves a JavaScript shell to automated requests), and publishing an unverifiable list in a compliance tool would be worse than publishing none. The substance names come from the user's own certificate. Deadlines it reports: no non-compliant product may be placed on the EU market after 2026-07-31; stock placed before then may be made available until 2028-07-31. Returns { assessments[{name, percentInCompound, percentInProduct, threshold, mustDeclare, ratio}], missingFromList[], findings[], summary{productType, thresholdUsed, declarable, belowThreshold, errors, warnings, byRule} }.

NameTypeReqDescription
allergensarrayyesThe certificate rows: INCI name and its percentage WITHIN the fragrance compound.
compoundPercentnumberyesHow much fragrance compound the formula contains, as a percentage of the finished product.
ingredientListstring–The ingredient list as printed, to check that declarable allergens are actually named in it.
productTypestring–Leave-on (0.001%) or rinse-off (0.01%). Omit and the stricter threshold is used, which the result states.

No output schema declared.

No examples provided.

check_gpsr_listing ~426

Check listing text against the four things Article 19 of Regulation (EU) 2023/988 requires an online offer to show, using 18 documented rules. Applies to anything sold into the EU since 13 December 2024. The four elements are judged SEPARATELY and returned as elements[] with a status each (ok / problem / missing / manual): (1) manufacturer name plus a postal AND an electronic address; (2) a responsible person established in the Union, required when the manufacturer is not; (3) information identifying the product (model, type, batch, GTIN); (4) warnings and safety information in the language of each market. The failure it exists to catch: a correct manufacturer block with a non-EU address and nobody inside the Union attached to the product — and its variant, a "responsible person" whose address is in the UK (which left the Union in 2020) or the US. Pass `markets` (EU country codes) to also judge warning languages: the check looks for warning wording in that market's language across 26 languages. Finding it is a FLOOR, not proof the text was translated — say so when reporting. It never claims to have checked the picture requirement: that element always comes back with status "manual" because a text checker cannot see images. Postal codes are validated against the country and barcodes against GS1, so a fabricated address or a broken GTIN surfaces here too. Returns { elements[{key, label, status, detail, findings[]}], findings[], summary{passed, required, errors, warnings, manufacturerCountry, responsiblePersonCountry, marketsMissingLanguage, byRule} }. Not legal advice: it checks whether the required information is present and consistent, not whether the product is in scope.

NameTypeReqDescription
marketsarray–Target market country codes (e.g. ["DE","FR"]). Without them no judgement is made about warning languages.
textstringyesThe listing text — title, description and whatever compliance block exists. Paste it raw.

No output schema declared.

No examples provided.

check_nutrition_facts ~499

Turn unrounded laboratory values into the numbers 21 CFR 101.9 requires on a US Nutrition Facts panel, and check any already-declared values against them (8 documented rules). FDA ROUNDING IS NOT ORDINARY ROUNDING and this is the whole point of the tool: total fat goes to the nearest 0.5 g below 5 g and the nearest 1 g above; sodium to the nearest 5 mg up to 140 mg and 10 mg above; calories to the nearest 5 up to 50 and 10 above; cholesterol under 2 mg may be zero and 2-5 mg may be stated as "less than 5 mg"; gram nutrients under 1 g may be stated as "less than 1 g". A value passed through Math.round is wrong on the label even when it looks close. It also catches the shortcut the regulation explicitly forbids: calories computed from the ROUNDED macronutrients rather than the actual amounts. When the declared calories match 4/4/9 on the rounded values but not the unrounded ones, that is reported (NFP-006). Consistency checks: saturated + trans must not exceed total fat, added sugars must not exceed total sugars, sugars and fibre must not exceed total carbohydrate. Percent Daily Value is computed from the unrounded amount and expressed as a whole percent — note total sugars has NO Daily Value, so a percentage beside it is wrong rather than merely imprecise. Out of scope, deliberately: serving size and the RACC table (21 CFR 101.12), vitamins and minerals, and EU rounding guidance, which differs. Returns { rows[{nutrient, label, measured, required{display, value, rule}, declared?, percentDailyValue?, findings[]}], findings[], summary{checked, mismatches, errors, warnings, computedCalories, byRule} }. Use rows[].required.display as the label text — it may be a phrase, not a number.

NameTypeReqDescription
declaredobject–Values already printed on the label, same keys — each is compared with the required rounding.
declaredPercentobject–Percent Daily Values already printed, same keys.
measuredobjectyesUnrounded lab values keyed by nutrient: calories, totalFat, saturatedFat, transFat, cholesterol, sodium, totalCarbohydrate, dietaryFiber, totalSugars, addedSugars, protein.

No output schema declared.

No examples provided.

eu_nutrition_tolerance ~453

Take one value as printed on an EU label and return the range an official control accepts for it, with the working. This is a THREE-STEP calculation and neither shortcut is right: it is not "declared ± 20%", and the band is not applied to the declared figure. The guidance first widens the printed number back to every value that would round to it (8.5 becomes 8.45 to 8.54 — the number of decimals you printed decides this, so pass `decimals` if the printed form has trailing zeros), then applies the tolerance band for that nutrient AT THAT LEVEL, then rounds both ends back per the rounding guidance. A declared 8.5 g of sugars accepts 6.5 to 11 g; a declared 12 g of protein accepts up to 15 g. The bands themselves differ by nutrient and by level: carbohydrate, sugars, protein and fibre get ±2 g below 10 g, ±20% from 10 to 40 g, ±8 g above; fat ±1.5 g below 10 g; saturates and the other fatty acids ±0.8 g below 4 g then ±20%; salt ±0.375 g below 1.25 g then ±20%. Energy returns nothing, and that is the correct answer rather than a gap: the guidance sets no tolerance for it. Source and status: the Commission guidance of December 2012, which has no formal legal status — say so when reporting a verdict. Which tolerance band applies is read off the DECLARED value; the two worked examples in the guidance cannot distinguish that reading from the alternative, and this tool documents the choice rather than hiding it. Returns { lower, upper, band, steps[{label, detail}] }, or nothing for energy.

NameTypeReqDescription
decimalsnumber–How many decimals were printed, when that differs from the number itself (0.50 rather than 0.5). It changes the range.
declarednumberyesThe value as printed on the label, in grams per 100 g.
nutrientstringyesWhich nutrient — the band and the rounding tier both depend on it.

No output schema declared.

No examples provided.

round_nutrient_value ~145

Round a single nutrient value per 21 CFR 101.9 and say which rule band was used. Returns { display, value, rule } — `display` is what goes on the label and may be a phrase such as "less than 1 g" rather than a number, in which case `value` is null. Use this when composing a label value by value; use check_nutrition_facts for a whole panel with its consistency checks.

NameTypeReqDescription
nutrientstringyesWhich nutrient — each has its own increments.
valuenumberyesThe unrounded amount per serving, in the unit for that nutrient (g, mg or kcal).

No output schema declared.

No examples provided.

Common questions

What is the com.yaktool/compliance MCP server?

com.yaktool/compliance is an MCP server listed in the public MCP registry as com.yaktool/compliance. GPSR, EUDR plots, nutrition labels, fragrance allergens, CPSC and EU conformity declarations. This page covers its npm package (yaktool-compliance-mcp).

Is the com.yaktool/compliance MCP server safe to use?

com.yaktool/compliance 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/compliance MCP server expose?

com.yaktool/compliance exposes 9 tools: check_gpsr_listing, check_eudr_geojson, check_nutrition_facts, round_nutrient_value, check_fragrance_allergens, and 4 more. Their descriptions and schemas cost roughly 4,715 tokens of context every time the server is loaded.

Is the com.yaktool/compliance MCP server still maintained?

com.yaktool/compliance 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/compliance MCP server under?

com.yaktool/compliance declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.