ComplianceCN 跨境电商出海合规预检
Server Details
出海合规预检 · Source-cited EU/US/UK/AU market-access checks for cross-border sellers
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 5 of 5 tools scored.
Each tool has a clear, distinct purpose: market_access_check is the main workflow, compare_market_requirements for explicit comparisons, describe_coverage for scope info, explain_claim for specific claims, and watch_product_regulatory_changes for subscriptions. No overlap.
All tools follow a consistent verb_noun pattern using snake_case (e.g., compare_market_requirements, market_access_check). The naming is predictable and clear.
With 5 tools, the server is well-scoped for its specialized domain. Each tool serves a necessary function without being too few or excessive.
The tool set covers the full workflow: entry, comparison, scope explanation, claim detail, and subscription. No obvious gaps for the stated compliance domain.
Available Tools
5 toolscompare_market_requirements比较市场要求 / Compare marketsARead-onlyIdempotentInspect
可选辅助比较，不是卖家流程入口或最终结论。仅当用户明确比较同一产品进入2至4个市场时调用；即使部分产品事实未知，也会返回可展示的 partial_comparison，optional_refinement_questions 仅供用户希望进一步细化时使用，不应自动追问或重试。普通卖家问题先用 market_access_check。Optional supporting comparison, not the seller-workflow entry point or final result. Use only when the user explicitly asks to compare the same product across 2–4 markets. When product facts are unknown it still returns a presentable partial_comparison; optional_refinement_questions are non-blocking and must not trigger automatic questions or retries. For ordinary seller requests, use market_access_check. 访问提示：首个产品案件可免费完成。用 market_access_check 开始并继续同一案件：首次发送自然语言 message 且不传 case_id，之后原样携带服务端返回的 case_id，并严格遵循 state 和 next_action。回答 questions 时使用稳定的 question.key；卖家确认第一阶段摘要或已有适用于本案件的明确授权后，才使用 action=confirm_stage_1。人工复核、邮箱同意和付款通过返回的安全 action_url 进行；若 next_action.delegated_execution 所列授权已存在且智能体具备相应能力，可代用户完成，否则交给用户。不得推定权限。第二个产品或 SKU 需要付费访问。 Access notice: one complete product case is included free. Start and continue it only with market_access_check: send a plain-language message without case_id on the first call, then preserve the returned case_id and follow state and next_action exactly. Key answers by question.key and use action=confirm_stage_1 after the seller confirms the Stage 1 summary or an active case-scoped delegation explicitly authorises it. Human review, email consent and payment use the secure action_url. If next_action.delegated_execution is already satisfied and the agent has the required capability, it may complete that action; otherwise hand it to the seller. Never infer permission. A second product or SKU requires paid access.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | No | Opaque ComplianceCN product-case ID returned by the first successful free workflow call. Carry it unchanged through clarification retries, Stage 2 and human review for the same product/SKU. Never reuse it for another product or SKU. | |
| markets | Yes | ||
| category | Yes | Product category | |
| language | No | Response language. Defaults to Chinese. | zh |
| age_group | No | ||
| food_type | No | ||
| has_radio | No | ||
| has_battery | No | ||
| battery_type | No | ||
| is_sunscreen | No | ||
| repeated_use | No | ||
| verified_only | No | Exclude rules not yet checked against primary sources. Default false: unverified material is included but labelled via review_status and the trust envelope. | |
| eu_destination | No | ||
| contact_duration | No | ||
| supply_chain_role | No | Supply-chain role. Canonical values are manufacturer, importer, distributor, marketplace_seller or unknown. Common natural-language English and Chinese labels are accepted and normalized. | |
| claims_therapeutic | No | ||
| contact_temperature | No | ||
| ingredients_reviewed | No | ||
| is_childrens_product | No | Whether the product is marketed as a children's product; keep unknown when not established. | |
| food_contact_material | No | ||
| accessible_small_parts | No | ||
| includes_mains_charger | No | ||
| is_electrically_operated | No | Whether the toy is electrically operated, including mains-powered or battery-powered operation. | |
| battery_compartment_security | No | ||
| toy_chemical_assessment_complete | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| payload | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds that partial_comparison is returned even when facts unknown and that refinement questions are non-blocking. It does not contradict annotations, but the long workflow notes are somewhat tangential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long (bilingual, over 500 words) and includes an 'access notice' that pertains to the broader workflow, not specifically to this tool. It is not concise, though the key points are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the length, the description covers key behavioral aspects (partial results, non-blocking questions) and references the output schema indirectly. However, it omits many parameter explanations and is cluttered with workflow instructions that reduce completeness for this tool's context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 28%, yet the description adds almost no parameter-level detail. It does not explain the distinction between category values, market options, or other fields beyond what the schema provides. The description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'optional supporting comparison' for comparing the same product across 2-4 markets. It distinguishes itself from sibling tool market_access_check by specifying it is not the entry point or final result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Use only when the user explicitly asks to compare the same product across 2–4 markets' and 'For ordinary seller requests, use market_access_check.' It also warns against automatic retries or questions on optional_refinement_questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_coverage数据覆盖与核验状态 / Describe coverageARead-onlyIdempotentInspect
按需查看数据范围、可信度和服务运营资料；无需在每个卖家请求前重复调用。返回版本、类目/市场覆盖、逐项核验状态、来源政策和健康/更新链接。普通产品问题仍从 preflight_product 开始。Use when the user or agent needs to inspect scope, source trust or live-service details; do not repeat it before every seller request. Returns versions, category/market coverage, per-record verification, source policy and operational check links. Start ordinary product requests with preflight_product.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Response language. Defaults to Chinese. | zh |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| payload | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds useful behavioral context: it returns versions, category/market coverage, per-record verification, source policy and operational check links, and mentions that it does not need to be called before every seller request.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual and each sentence adds value: purpose, usage, output, and guidance. It could be slightly more concise, but it is well-structured and front-loads key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 optional param), presence of an output schema, and the description covering purpose, usage, and return contents, the description is complete enough for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (language) with 100% schema description coverage. The schema already fully describes the parameter (enum, default, description). The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('inspect scope, source trust or live-service details') and resource ('coverage'), and explicitly distinguishes the tool from the sibling 'preflight_product' by stating that ordinary product requests should start there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use ('Use when... inspect scope, source trust or live-service details') and when-not-to-use ('do not repeat it before every seller request', 'Start ordinary product requests with preflight_product').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_claim解释声明与证据 / Explain claimARead-onlyIdempotentInspect
仅解释 ComplianceCN 先前结果中返回的稳定 claim_id；不要用自然语言问题或自行猜测ID。返回声明、主要来源、核验日期和证据缺口。Explain only a stable claim_id returned by an earlier ComplianceCN result. Do not use this for broad natural-language questions or invent an ID. Returns the claim, primary-source evidence, verification date and evidence gaps. 访问提示：首个产品案件可免费完成。用 market_access_check 开始并继续同一案件：首次发送自然语言 message 且不传 case_id，之后原样携带服务端返回的 case_id，并严格遵循 state 和 next_action。回答 questions 时使用稳定的 question.key；卖家确认第一阶段摘要或已有适用于本案件的明确授权后，才使用 action=confirm_stage_1。人工复核、邮箱同意和付款通过返回的安全 action_url 进行；若 next_action.delegated_execution 所列授权已存在且智能体具备相应能力，可代用户完成，否则交给用户。不得推定权限。第二个产品或 SKU 需要付费访问。 Access notice: one complete product case is included free. Start and continue it only with market_access_check: send a plain-language message without case_id on the first call, then preserve the returned case_id and follow state and next_action exactly. Key answers by question.key and use action=confirm_stage_1 after the seller confirms the Stage 1 summary or an active case-scoped delegation explicitly authorises it. Human review, email consent and payment use the secure action_url. If next_action.delegated_execution is already satisfied and the agent has the required capability, it may complete that action; otherwise hand it to the seller. Never infer permission. A second product or SKU requires paid access.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | No | Opaque ComplianceCN product-case ID returned by the first successful free workflow call. Carry it unchanged through clarification retries, Stage 2 and human review for the same product/SKU. Never reuse it for another product or SKU. | |
| claim_id | Yes | ||
| language | No | Response language. Defaults to Chinese. | zh |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| payload | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and idempotentHint true. The description adds workflow context (e.g., case_id carried through, delegated execution, human review via action_url) and clarifies the tool's read-only nature. No contradiction with annotations; extra context earns a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but verbose, containing both Chinese and English paragraphs. While well-structured with clear sections, it could be more concise. The length may overwhelm some agents, though the information is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, output schema present, annotations), the description covers all essential aspects: purpose, constraints, workflow dependencies, return values (implied by output schema), and distinction from sibling tools. It leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 parameters have descriptions). The description compensates for the undocumented claim_id parameter by specifying it must be a stable ID from previous results and not guessed. It also adds workflow context for case_id beyond the schema. This adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool explains a stable claim_id from ComplianceCN results, specifying exactly what it returns (claim, primary-source evidence, verification date, evidence gaps). It distinguishes from siblings by explicitly warning against using it for broad natural-language questions and referencing market_access_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use instructions: only for stable claim_ids from earlier ComplianceCN results, not for natural language questions or invented IDs. It also details the workflow with market_access_check, including state and next_action adherence, making usage very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_access_check产品市场准入检查 / Product market-access checkAIdempotentInspect
卖家工作流的唯一入口和续接工具。首次调用时，用 message 发送产品、目标市场和已知供应商资料。服务端保存案件状态，并返回稳定的 state、questions 和 next_action。只询问 questions 中列出的项目；用同一 case_id 和以 question.key 为键的 answers 继续。第一阶段完成后，先向卖家展示摘要；只有卖家确认或已有适用于本案件的授权后，才以 action=confirm_stage_1 生成第二阶段材料包。浏览器操作会声明 delegated_execution：若智能体已有所需的范围化授权及浏览器、邮箱或付款能力，可以代用户完成；否则把 action_url 交给用户。不得推定权限。The single entry and continuation tool for the seller workflow. Start with a plain-language message describing the product, destination and known supplier material. The server owns case state and returns a stable state/questions/next_action contract. Ask only the returned questions and continue with the same case_id and answers keyed by question.key. Generate Stage 2 after the seller confirms Stage 1, or when an active delegation explicitly covers confirmation for this case. Browser actions declare delegated_execution: an agent with the listed scoped permissions and required browser, email or payment capability may complete them; otherwise give action_url to the seller. Never infer permission.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Use continue for the initial description and clarifications. Use confirm_stage_1 only after the seller confirms the Stage 1 summary. Use correct_stage_1 with message or answers to amend it. | continue |
| answers | No | Optional structured answers keyed by the stable question.key values returned by the previous call. | |
| case_id | No | Opaque ComplianceCN product-case ID returned by the first successful free workflow call. Carry it unchanged through clarification retries, Stage 2 and human review for the same product/SKU. Never reuse it for another product or SKU. | |
| message | No | The seller's initial product/market description or their latest natural-language clarification. Do not repeat information already supplied. | |
| language | No | Preferred response language; inferred from the seller message when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| payload | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description reveals the stateful nature, the stable state/questions/next_action contract, the two-stage process, and the delegation mechanism. It adds context about expected behavior (ask only returned questions, require seller confirmation) without contradicting the idempotentHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear bilingual text, front-loaded purpose, and logical flow. While thorough, it could be slightly more concise by reducing repetition between Chinese and English, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (stateful workflow, multiple actions, delegation), the description fully covers the needed information: initial call, continuation, stage generation, permissions, and error handling. With 100% schema coverage and an output schema, no gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds workflow context (e.g., clarifying the use of case_id across calls) but does not significantly enhance the parameter-level semantics beyond what the schema's property descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this tool as the single entry and continuation tool for the seller workflow, distinguishing it from sibling tools that handle comparison, coverage, claims, and regulatory changes. It specifies the exact resource (product-market access check) and the action (starting and continuing the workflow).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions: start with a message, then use the returned case_id and answers for continuation. It specifies when to use confirm_stage_1, correct_stage_1, and how to handle delegated execution. It also states what not to do (never infer permission), offering clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_product_regulatory_changes订阅产品变更提醒 / Watch product regulatory changesAInspect
Start Stripe Checkout for a paid ComplianceCN product-change alert subscription with a free trial. Call only after market_access_check has produced a usable product/market profile and the seller explicitly asks to be notified. Before calling, provide product_profile with category and markets, a real top-level email, and consent_to_alerts=true. The subscription emails when a human-reviewed ComplianceCN changelog update matches the saved product, market, requirement or rule profile. It does not guarantee detection of every regulatory change. The returned next_action allows an agent to complete Stripe Checkout only when an active payment mandate covers ComplianceCN and the displayed amount, currency and recurring terms; otherwise give the URL to the seller. Never infer payment permission or claim the subscription is active until Stripe confirms checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| payload | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly covers behavioral traits: it starts a paid subscription with a free trial, emails on changelog matches, does not guarantee all detections, and explains the next_action role in completing checkout. It also warns against inferring payment permission. No contradiction with annotations (readOnlyHint=false, opensWorldHint=true, idempotentHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is several sentences long but each sentence serves a purpose: purpose, prerequisites, input requirements, behavior, limitations, and output. It is front-loaded with purpose. Slightly verbose but acceptable given complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, nested objects, output schema exists), the description covers purpose, prerequisites, required inputs, behavioral details, and output hints. It references the output schema by mentioning next_action and its role. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that product_profile should come from market_access_check, that email must be a real top-level email, and that consent_to_alerts must be true. This workflow context goes beyond property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a Stripe Checkout for a paid alert subscription with a free trial, specifying the verb 'start' and the resource 'subscription'. It doesn't explicitly differentiate from sibling tools like compare_market_requirements, but includes a workflow dependency on market_access_check, which implicitly sets it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit conditions are given: call only after market_access_check, only when seller explicitly asks. It lists required inputs (product_profile, email, consent_to_alerts). However, it doesn't state when not to use the tool or suggest alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!