# com.yaktool/compliance (npm · yaktool-compliance-mcp)

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

- Trust score: 77/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-25

## Components

- npm · `yaktool-compliance-mcp`: 77/100 (this document), [markdown](https://verifymcp.io/servers/com-yaktool-compliance/yaktool-compliance-mcp.md), [page](https://verifymcp.io/servers/com-yaktool-compliance/yaktool-compliance-mcp)

## Channel facts

- Registry: `npm`
- Package: `yaktool-compliance-mcp`
- Version: `0.4.0`
- Transport: `stdio`

## Trust breakdown

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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-25.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - No production dependencies, so there is no dependency health to assess.
- **Provenance & Transparency**: 19/100
  - Repository check failed: no source repository is declared.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 18 days ago).
  - Security-disclosure policy not yet verified: we couldn't inspect the source repository.
- **Schema Quality & AI Usability**: 62/100
  - AI-judged instruction clarity (excellent).
  - 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.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 100/100
  - No destabilizing schema changes in the last 30 days.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 9 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 9 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## 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.

### Claude

```bash
claude mcp add com-yaktool-compliance -- npx -y yaktool-compliance-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "com-yaktool-compliance": {
      "command": "npx",
      "args": [
        "-y",
        "yaktool-compliance-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-yaktool-compliance": {
      "command": "npx",
      "args": [
        "-y",
        "yaktool-compliance-mcp"
      ]
    }
  }
}
```

### Codex

```bash
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
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-yaktool-compliance --command npx --arg -y --arg yaktool-compliance-mcp
```

### Hermes

```yaml
mcp_servers:
  com-yaktool-compliance:
    command: "npx"
    args: ["-y", "yaktool-compliance-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "com-yaktool-compliance": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "yaktool-compliance-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-yaktool-compliance -t stdio -c npx -a -y yaktool-compliance-mcp
```

### Other

```json
{
  "mcpServers": {
    "com-yaktool-compliance": {
      "command": "npx",
      "args": [
        "-y",
        "yaktool-compliance-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-25 (score 77, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-09-24 (score 77, +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.

### 2026-09-22 (score 76, +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.

### 2026-09-20 (score 75, +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.

### 2026-09-18 (score 74, +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.

### 2026-09-16 (score 73, +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.

### 2026-09-14 (score 72, +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.

### 2026-09-12 (score 71, +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.

## MCP tools (9)

### `check_gpsr_listing` (~426 tokens)

Check a listing against Article 19 of the EU GPSR

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.

Input parameters:

- `markets` (array): Target market country codes (e.g. ["DE","FR"]). Without them no judgement is made about warning languages.
- `text` (string, required): The listing text — title, description and whatever compliance block exists. Paste it raw.

### `check_eudr_geojson` (~464 tokens)

Pre-check EUDR plot geolocation before a DDS submission

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, ...} }.

Input parameters:

- `fileSizeBytes` (number): Real file size in bytes when known, for the 25 MB submission limit; otherwise it is computed from the text.
- `geojson` (string, required): The GeoJSON file contents as text (a FeatureCollection, or a single Feature).

### `check_nutrition_facts` (~499 tokens)

Round nutrient values for a US Nutrition Facts panel and check them

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.

Input parameters:

- `declared` (object): Values already printed on the label, same keys — each is compared with the required rounding.
- `declaredPercent` (object): Percent Daily Values already printed, same keys.
- `measured` (object, required): Unrounded lab values keyed by nutrient: calories, totalFat, saturatedFat, transFat, cholesterol, sodium, totalCarbohydrate, dietaryFiber, totalSugars, addedSugars, protein.

### `round_nutrient_value` (~145 tokens)

Round one nutrient value the way FDA requires

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.

Input parameters:

- `nutrient` (string, required): Which nutrient — each has its own increments.
- `value` (number, required): The unrounded amount per serving, in the unit for that nutrient (g, mg or kcal).

### `check_fragrance_allergens` (~561 tokens)

Work out which fragrance allergens must be named in an EU ingredient list

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} }.

Input parameters:

- `allergens` (array, required): The certificate rows: INCI name and its percentage WITHIN the fragrance compound.
- `compoundPercent` (number, required): How much fragrance compound the formula contains, as a percentage of the finished product.
- `ingredientList` (string): The ingredient list as printed, to check that declarable allergens are actually named in it.
- `productType` (string): Leave-on (0.001%) or rinse-off (0.01%). Omit and the stricter threshold is used, which the result states.

### `check_eu_nutrition_declaration` (~736 tokens)

Check an EU nutrition declaration against Regulation 1169/2011

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…

Input parameters:

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

### `eu_nutrition_tolerance` (~453 tokens)

Work out the range an official control accepts for one declared value

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.

Input parameters:

- `decimals` (number): How many decimals were printed, when that differs from the number itself (0.50 rather than 0.5). It changes the range.
- `declared` (number, required): The value as printed on the label, in grams per 100 g.
- `nutrient` (string, required): Which nutrient — the band and the rounding tier both depend on it.

### `check_cpsc_certificate` (~708 tokens)

Check a US CPSC certificate of compliance (CPC or GCC) against 16 CFR 1110

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…

Input parameters:

- `efiled` (boolean): 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.
- `imported` (boolean): Whether the goods are imported. Inferred from the place of manufacture when omitted; it decides who § 1110.7 puts on the certificate.
- `text` (string, required): The certificate as written, one field per line (for example "Certifier: ...", "Records custodian: ...", "Manufactured: ...", "Tested: ...").

### `check_eu_declaration_of_conformity` (~723 tokens)

Check an EU/EC Declaration of Conformity against the annex that actually applies

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…

Input parameters:

- `directives` (array): Override which annexes to check against. Omit to use the directives the declaration itself cites — that is the normal path.
- `text` (string, required): The declaration as written, ideally keeping its numbered items on separate lines.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/com-yaktool-compliance/yaktool-compliance-mcp#diagnostics

## Score history

- 2026-09-25: 77
- 2026-09-24: 77
- 2026-09-23: 76
- 2026-09-22: 76
- 2026-09-21: 75
- 2026-09-20: 75
- 2026-09-19: 74
- 2026-09-18: 74
- 2026-09-17: 73
- 2026-09-16: 73
- 2026-09-15: 72
- 2026-09-14: 72
- 2026-09-13: 71
- 2026-09-12: 71
- 2026-09-11: 70
- 2026-09-10: 70
- 2026-09-09: 70
- 2026-09-08: 69
- 2026-09-07: 69
- 2026-09-06: 53
- 2026-09-05: 68
- 2026-09-04: 67
- 2026-09-03: 67
- 2026-09-02: 66
- 2026-09-01: 66
- 2026-08-31: 64
- 2026-08-30: 64
- 2026-08-29: 64
- 2026-08-28: 64
- 2026-08-27: 64

## 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.

## Links

- npm package: https://www.npmjs.com/package/yaktool-compliance-mcp
- Socket report: https://socket.dev/npm/package/yaktool-compliance-mcp
- Changelog RSS feed: https://verifymcp.io/servers/com-yaktool-compliance/yaktool-compliance-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-yaktool-compliance/yaktool-compliance-mcp.json
- HTML version of this page: https://verifymcp.io/servers/com-yaktool-compliance/yaktool-compliance-mcp