This server provides MiCA crypto compliance checks and EU regulation lookup via MCP tools.
classify_crypto_asset — classify a crypto-asset under MiCA (ART, EMT, other CA, or MiFID-II out)
check_casp_authorisation — check Crypto-Asset Service Provider authorisation requirements and transitional regimes
whitepaper_requirements — get MiCA Articles 6-15 whitepaper content requirements
market_abuse_check — check MiCA Title VI market abuse rules (insider dealing, market manipulation)
aml_overlay — get MiCA + 6AMLD AML overlay guidance for crypto operators
search_regulation — full-text search across 410+ articles of real EU regulation text (EUR-Lex verified) with optional filters
list_regulations_in_db — list all regulations available in the local EUR-Lex FTS5 database
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Mica Crypto MCP check compliance requirements for my crypto wallet"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp-name: io.github.CSOAI-ORG/mica-crypto-mcp
Buy Starter — £29/mo
Signed attestations + unlimited audits + email support. 👉 Subscribe at meok.ai — instant HMAC signing key + Stripe-managed billing.
Free tier remains MIT-licensed and zero-config. Upgrade only when you need signed compliance artefacts for audit.
EU MiCA (Reg 2023/1114) compliance MCP for crypto-asset issuers, exchanges, CASPs
EU MiCA (Reg 2023/1114) compliance MCP for crypto-asset issuers, exchanges, CASPs. MIT
Related MCP server: EU AI Act Compliance MCP
# Install via pip
pip install mica_crypto_mcp
# Or install via Smithery
npx -y @smithery/cli@latest install mica-crypto-mcp --client claudeMCP protocol compliant
Easy installation
Well-documented API
Production-ready
Active maintenance
This MCP server is built with EU AI Act compliance built-in:
Free: 10 calls/day. No API key required.
Pro £79/mo: unlimited + signed attestations. Subscribe
Enterprise £1,499/mo: white-label + on-premise + SLA. hello@meok.ai
✅ Article 9 — Risk Management System
✅ Article 13 — Transparency & Instructions for Use
✅ Article 15 — Bias Detection & Testing
✅ Article 26 — FRIA Support (where applicable)
✅ Article 50 — AI Content Watermarking (where applicable)
Need help getting compliant? Book a free 15-min diagnostic →
Need custom development, SLA guarantees, or white-label deployment?
Pro: $99/mo — Full MCP suite + EU AI Act tracking
Enterprise: $499/mo — Custom dev + SLA + Dedicated support
View Pricing → | Contact Sales →
This server is part of the MEOK AI Labs ecosystem — 300+ MCP servers for sovereign AI governance.
Domain | Purpose |
EU AI Act compliance marketplace | |
AI safety & monitoring | |
Sovereign AI platform | |
Legacy modernization |
MIT © CSOAI-ORG
Tier | Price | What you get | Stripe |
Smoke test | £1 | Signed sample MCP-Hardening report + Article 50 PDF | |
Quick Kit | £9 | EU AI Act Article 50 implementation guide (C2PA + EU-Icon) | |
Founder Call | £29 | 30-min 1-on-1 with the founder |
Refundable. UK Stripe — VAT-clean. Builds on the 81-MCP MEOK fleet. Verify any signed report at https://meok.ai/verify.
Add to your claude_desktop_config.json (Claude Desktop) or your MCP client config:
{
"mcpServers": {
"mica-crypto-mcp": {
"command": "uvx",
"args": ["mica-crypto-mcp"]
}
}
}Or: pip install mica-crypto-mcp then run the mica-crypto-mcp command (stdio transport).
Once configured, ask your assistant, for example:
"Use classify_crypto_asset to …"
"Use check_casp_authorisation to …"
"Use whitepaper_requirements to …"
MiCA + 6AMLD AML overlay for crypto operators
Args: query: Optional query parameter (regulation ref, identifier, or input data). api_key: Optional MEOK API key for Pro+ tier features.
Returns: JSON with structured assessment, regulation refs, and recommended actions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return format but does not disclose whether the tool is read-only, destructive, or has any side effects. No details on authentication requirements or rate limits.
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 concise with a clear opening line stating purpose. It uses a structured args format. Every sentence adds value without unnecessary detail.
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 lack of annotations and the existence of an output schema, the description provides basic context but is insufficient for a novice agent. It does not explain how the output schema integrates with the assessment or how to use the result. The sibling tools are more specific, so this overlay tool's place in the workflow is ambiguous.
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 0%, so the description must compensate. It adds context for 'query' as a regulation ref, identifier, or input data, and for 'api_key' as for Pro+ features. However, the descriptions remain vague and could specify acceptable formats or behaviors.
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 it provides an AML overlay for crypto operators under MiCA and 6AMLD regulations, and the return format is described. However, it does not explicitly differentiate from sibling tools, but the name and context imply a general assessment tool.
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?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or when to avoid it. The description is purely operational.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crypto-Asset Service Provider authorisation requirements + transitional regime
Args: query: Optional query parameter (regulation ref, identifier, or input data). api_key: Optional MEOK API key for Pro+ tier features.
Returns: JSON with structured assessment, regulation refs, and recommended actions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return format (JSON with assessment, refs, actions), but does not disclose any side effects, authentication needs, or rate limits. The tool appears to be read-only, but this is not explicitly stated.
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 concise, with the purpose stated upfront in a single line, followed by parameter and return descriptions. No unnecessary words or repetition.
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?
For a simple query tool with two optional parameters and an output schema, the description covers purpose, parameters, and return format. However, it lacks usage guidelines and deeper behavioral context, though the sibling tools cover different areas.
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?
The description adds meaning beyond the schema: it explains that 'query' is a parameter for regulation ref, identifier, or input data, and that 'api_key' enables Pro+ tier features. The schema only provides default empty strings and types.
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 checks Crypto-Asset Service Provider authorisation requirements and transitional regime. It distinguishes from sibling tools like aml_overlay or classify_crypto_asset by focusing on authorisation specifics.
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?
No guidance on when to use this tool versus alternatives. No mention of prerequisites or scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify a crypto-asset under MiCA (ART, EMT, other CA, MiFID-II out)
Args: query: Optional query parameter (regulation ref, identifier, or input data). api_key: Optional MEOK API key for Pro+ tier features.
Returns: JSON with structured assessment, regulation refs, and recommended actions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses that the tool returns JSON with structured assessment, regulation refs, and recommended actions, but does not detail side effects, authentication requirements beyond a mention of api_key for Pro+ features, or rate limits. It is adequate but not explicit about behavioral traits.
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 extremely concise: one line for purpose, bullet-style args, and return. It is front-loaded with the key verb and resource, with no wasted words. 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 presence of an output schema, the description does not need to explain return values. It sufficiently covers the input parameters, purpose, and output structure. The tool is simple and the description is complete for an AI agent to understand usage.
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?
With 0% schema description coverage, the description adds meaningful context for both parameters: query is described as optional (regulation ref, identifier, or input data) and api_key as optional for Pro+ features. This goes beyond the bare schema, though more detail on input formats would improve it.
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 classifies a crypto-asset under MiCA, listing specific categories (ART, EMT, other CA, MiFID-II out). This verb+resource combination is specific and distinguishes it from siblings focused on AML, authorisation, or whitepapers.
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 implies usage when classification under MiCA is needed, but does not explicitly state when to use this tool versus alternatives. No exclusions or context for alternative tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all regulations in the local EUR-Lex FTS5 database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as read-only nature, performance implications, or potential side effects. Minimal disclosure for a list operation.
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?
Single sentence of 10 words, highly concise and front-loaded with key information. Every word 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 zero parameters and no output schema, description is adequate but could mention expected result format (e.g., list of regulation identifiers) or error conditions.
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?
No parameters defined in schema. Baseline score of 4 applies as per guidelines for zero-parameter tools; description adds no param info but none needed.
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?
Description clearly states verb 'List', resource 'regulations', scope 'all', and context 'local EUR-Lex FTS5 database'. Distinct from sibling 'search_regulation' which implies filtered retrieval.
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?
No guidance on when to use this tool versus alternatives like 'search_regulation'. The description implies it returns all records but does not explicitly state when to prefer it or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MiCA Title VI market abuse rules (insider dealing, market manipulation)
Args: query: Optional query parameter (regulation ref, identifier, or input data). api_key: Optional MEOK API key for Pro+ tier features.
Returns: JSON with structured assessment, regulation refs, and recommended actions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It states it returns a JSON assessment with regulation refs and actions, implying a read-only check. However, it does not explicitly confirm non-destructiveness or mention auth requirements beyond optional api_key.
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?
Three concise sentences: purpose, arguments, return type. No wasted words, front-loaded with main purpose.
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 nature as a regulatory check with an output schema, the description covers purpose, parameters, and return type. It lacks examples or error handling but is sufficient for an agent to understand usage.
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?
Input schema has 0% description coverage, but the description explains both parameters: query as regulation ref/identifier/input data, and api_key for Pro+ tier. This adds significant meaning beyond the schema's empty defaults.
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?
Clearly identifies the tool's domain as MiCA Title VI market abuse rules, listing specific types (insider dealing, market manipulation). Differentiates from sibling tools like aml_overlay or check_casp_authorisation by focusing on a specific regulation area.
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?
Does not explicitly state when to use this tool versus alternatives. The description implies usage for market abuse checks under MiCA, but lacks clear guidance on context or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across 410+ articles of real EU regulation text (EUR-Lex verified).
Args: query: Search terms. FTS5 syntax supported (AND, OR, NEAR, phrase quoting). regulation: Optional filter - one of: eu-ai-act, dora, nis2, cra, csrd, gdpr. limit: Max results (default 10).
Returns:
Snippets from matching articles with regulation + article + relevance score.
Verbatim from EUR-Lex Cellar — auditor-defensible quotes with >>>match<<< highlights.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| regulation | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that results are verbatim from EUR-Lex Cellar, include snippets with regulation+article+relevance score, and feature auditor-defensible quotes with highlights. This adequately conveys that the operation is read-only and trustworthy.
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 highly concise, using a structured Args/Returns format. Every sentence adds value, with no wasted words. It is front-loaded with the core purpose and includes necessary details without verbosity.
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 having no output schema, the description fully describes return values (snippets, regulation, article, relevance score, highlights). All parameters are explained, and the tool's scope is clear. It meets all information needs for an agent to use the tool correctly.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter: query (FTS5 syntax), regulation (optional filter listing valid values), and limit (default 10). This adds significant meaning beyond the bare schema.
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 explicitly states it performs a full-text search across 410+ articles of EU regulation text from EUR-Lex, which clearly distinguishes it from sibling tools like list_regulations_in_db (listing) or specific checks like market_abuse_check. The verb 'search' and resource 'regulation text' are specific.
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 specifies the tool is for full-text search with FTS5 syntax and optional filters. While it doesn't explicitly state when not to use it or name alternatives, the context of siblings makes its primary use clear. A slight lack of exclusionary guidance prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MiCA Articles 6-15 whitepaper content requirements
Args: query: Optional query parameter (regulation ref, identifier, or input data). api_key: Optional MEOK API key for Pro+ tier features.
Returns: JSON with structured assessment, regulation refs, and recommended actions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only mentions optional parameters and return format, but does not describe side effects, permissions, or whether it is read-only. The description is too sparse for full transparency.
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?
Description is concise, with a clear purpose statement, Args section, and Returns line. It is front-loaded and contains no unnecessary words.
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 simplicity and the existence of an output schema, the description adequately covers purpose and parameters. Some additional context (e.g., typical usage) would improve completeness.
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 0%, but description adds meaningful context: query accepts regulation ref, identifier, or input data; api_key unlocks Pro+ features. This compensates well for missing schema 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?
Description clearly states the tool is for MiCA Articles 6-15 whitepaper content requirements, and specifies the return type (JSON with structured assessment, regulation refs, and recommended actions). This distinguishes it from siblings like search_regulation or aml_overlay.
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?
No explicit guidance on when to use this tool versus alternatives. The description only states what the tool does, without mentioning use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.8aml_overlaycheck_casp_authorisationclassify_crypto_assetlist_regulations_in_dbmarket_abuse_checksearch_regulationwhitepaper_requirementsEach tool targets a distinct aspect of MiCA regulation: AML overlay, CASP authorization, asset classification, market abuse, whitepaper requirements, and two database search tools. No overlapping purposes.
All tool names use snake_case with a consistent verb_noun structure (e.g., aml_overlay, check_casp_authorisation, classify_crypto_asset, list_regulations_in_db, market_abuse_check, search_regulation, whitepaper_requirements).
Seven tools cover a focused domain of MiCA crypto regulation, providing essential functionality without overwhelming or underserving the user.
The set covers major MiCA areas: AML, CASP authorization, asset classification, market abuse, whitepaper, and full-text search. Minor gaps like reporting requirements or stablecoin specifics are absent but acceptable for the scope.
Crypto marketing compliance rulesets over MCP: MiCA, FCA, GDPR, SEC, MAS, VARA. Not legal advice.
EU compliance corpus across 8 frameworks (NIS2, DORA, AI Act, ISO 27001 + more) via MCP.
MiCA Requirements: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not...
MiCAOracle — 24 tools for EU MiCA stablecoin compliance: peg, reserves, attestations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CSOAI-ORG/mica-crypto-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
