ComplianceCN — toys, batteries, cosmetics, food contact: CE, GPSR, UN 38.3, CPC/GCC and more

Email me when the rules for this product change

watch_product_regulatory_changes

Start free email alerts for regulatory changes affecting a product already checked here. Use when a seller says they want to be told if the rules change -- for example "let me know if this changes", "can you monitor this for me?", or "email me about updates". Requires a real top-level email and consent_to_alerts=true; there is no payment and no checkout step. Alerts start immediately and cover human-reviewed ComplianceCN changelog updates matching the saved product, market, requirement or rule profile. It does not guarantee detection of every regulatory change. Call only after a product check has produced a usable product/market profile and the seller has explicitly asked to be notified.

Input Schema

TableJSON Schema

Name	Required	Description
`email`	Yes	Seller email for product-change alerts. Provide only after the seller explicitly asks for the alert subscription.
`product_profile`	Yes	The same normalized product profile used for the completed preflight. Do not include document contents or unrelated personal data.
`preflight_result`	No	The completed preflight result when available. Its requirement, rule and claim IDs improve future change matching.
`consent_to_alerts`	Yes	Must be true. The seller explicitly agrees to save this product profile and receive matched product-change and subscription-service emails.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`payload`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that alerts are free, there is no checkout step, alerts start immediately, coverage is based on human-reviewed ComplianceCN changelog updates, and detection is not guaranteed. It also states requirements for a real email and consent_to_alerts=true, which clarifies side effects without contradicting the annotations.

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 and front-loaded with the core purpose, then usage signals, prerequisites, and behavior. It is slightly long but every sentence carries information, and the examples earn their place by disambiguating trigger phrases.

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?

With an output schema present and detailed input schema documentation, the description covers the remaining decision-relevant context: when to call it, prerequisites, consent requirement, subscription behavior, coverage scope, and limitations. Nothing critical is missing for an agent to select and invoke it 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?

Schema description coverage is 100%, so the parameters are already well documented. The description adds useful context about the product profile needing to come from a completed check and consent needing to be true, but it does not substantially go beyond what the schema already provides.

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 uses a specific verb ('Start free email alerts') and a clear resource ('regulatory changes affecting a product already checked here'). It is immediately distinguishable from the compliance-check siblings because it is about monitoring and notifying, not running a check.

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 trigger phrasing ('let me know if this changes', 'can you monitor this for me?', 'email me about updates') and states the precondition: only after a product check has produced a usable product/market profile and the seller has explicitly asked to be notified. It also excludes use before a product check exists, giving clear when-not guidance.

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

All ComplianceCN — toys, batteries, cosmetics, food contact: CE, GPSR, UN 38.3, CPC/GCC and more tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

The check_* tools each target a distinct regulatory aspect (transport, EU DoC, labeling, marketplace, US certification), and the auxiliary tools (describe, explain, compare, watch) are clearly separate. The only potential confusion is between market_access_check and preflight_product, which both assess product requirements but differ in input style and follow-up workflow.

Naming Consistency4/5

Most tools follow a verb_noun pattern (check_battery..., compare_market..., explain_claim), but market_access_check reverses the expected 'check_market_access' order and preflight_product uses a less common verb. Still, the pattern is recognizable and mostly consistent.

Tool Count5/5

Eleven tools is well within the ideal range for a compliance-checks server. Each tool addresses a distinct user scenario (general assessment, specialized checks, comparison, coverage, claims, alerts), and none feels redundant or superficial.

Completeness4/5

The server covers the core assessment lifecycle: initial check, structured preflight, detailed specialist checks, cross-market comparison, claim explanation, and regulatory change alerts. Minor gaps exist, such as no way to cancel alert subscriptions or retrieve a saved full report, but the main compliance-checking domain is thoroughly covered.

Resources

Need Help?