Skip to main content
Glama
sebastianfoerste

eu-reg-mcp

by sebastianfoerste
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

eu-reg-mcp

An MCP server that gives AI agents cited, review-gated grounding in EU regulation. Agents answering crypto or AI-compliance questions can check a live official register and cite pinpoint provisions instead of guessing.

Five tools:

Tool

What it does

Needs

search_micar_register

Look up an entity by name or LEI in the ESMA interim MiCAR register: white papers (Titles II–IV), authorised CASPs, non-compliant entities

—

micar_register_summary

Current register totals and white paper format coverage

—

micar_register_changes

Register movement: new filings, changed entries, removals (withdrawal tracking)

—

lint_micar_whitepaper

Deterministic Annex I–III lint of a draft white paper: cited candidate findings

lint extra

classify_eu_ai_act_system

EU AI Act risk-tier classification with pinpoint Art. 5 / Annex III / GPAI citations

classify extra

Register data comes from the MiCAR Register Observatory, which snapshots the public ESMA register weekly (Art. 109 VO (EU) 2023/1114). The linter is micar-whitepaper-linter (36 rules mapped to Annex I–III); the classifier is eu-ai-act-classifier.

Install

Claude Code

claude mcp add eu-reg -- uvx --from git+https://github.com/sebastianfoerste/eu-reg-mcp eu-reg-mcp

Claude Desktop (claude_desktop_config.json)

{
  "mcpServers": {
    "eu-reg": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/sebastianfoerste/eu-reg-mcp", "eu-reg-mcp"]
    }
  }
}

The three register tools work with no configuration and no API key. The lint and classify tools need their optional extras:

uv pip install 'eu-reg-mcp[lint] @ git+https://github.com/sebastianfoerste/eu-reg-mcp'
uv pip install 'eu-reg-mcp[classify] @ git+https://github.com/sebastianfoerste/eu-reg-mcp'

Note: the linter and classifier packages are source-available under their own licenses (portfolio display, reference, and evaluation use), not MIT — see their repositories before production use. Without the extras, both tools return an install hint instead of failing.

Related MCP server: attestix

Try it

Ask an agent with this server connected:

  • "Is <entity> on the MiCAR register, and what format is its white paper?"

  • "What changed on the MiCAR register recently — any removals?"

  • "Classify this AI system under the EU AI Act" (paste a system profile; call with an empty string to get the schema).

Guardrails

Every response carries its framing: register results are facts from a public register with the snapshot date; lint and classification outputs are candidate flags from deterministic rules, pending human legal review. Extraction artifacts exist. Nothing this server returns is a legal assessment of any entity or legal advice — that is a design contract, not a disclaimer.

Development

git clone https://github.com/sebastianfoerste/eu-reg-mcp
cd eu-reg-mcp
make install && make test

Tests run offline against fixtures. The server itself is MIT-licensed.

Available Tools

5 tools
classify_eu_ai_act_systemA

Classify an AI system's EU AI Act risk tier with pinpoint citations.

Pass a SystemProfile as JSON; pass an empty string to get the schema. Requires the optional classify extra; degrades to an install hint.

ParametersJSON Schema
NameRequiredDescriptionDefault
profile_jsonNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior4/5

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

No annotations provided, but description reveals key behavior: the tool requires an optional extra and degrades to an install hint if missing. Also states it provides 'pinpoint citations'. Does not explain error handling for invalid input, but covers main behavioral aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, front-loaded with purpose, no redundant information. Every sentence adds value.

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?

Given the tool's single parameter and presence of output schema, the description covers necessary context: both usage modes and installation requirement. No missing critical details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has one parameter with 0% descriptive coverage; description fully compensates by explaining that empty string retrieves schema and non-empty JSON classifies. Adds clear semantics beyond raw type definition.

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 clearly states the tool classifies an AI system's EU AI Act risk tier, with specific verb ('Classify') and resource ('EU AI Act risk tier'). It distinguishes from sibling tools which focus on MiCAR regulation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Describes when to use (passing a SystemProfile JSON) and an alternative mode (empty string for schema). Mentions dependency on optional extra. No explicit exclusion of when not to use, but context is clear.

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

lint_micar_whitepaperA

Lint a draft MiCAR white paper (JSON) against Annex I-III rules.

Returns cited candidate findings pending human review. Requires the optional lint extra; degrades to an install hint when absent.

ParametersJSON Schema
NameRequiredDescriptionDefault
whitepaper_jsonYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior3/5

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 results are pending human review and that the tool degrades gracefully when the dependency is absent. However, it does not describe side effects, authorization needs, or output format specifics beyond mentioning 'cited candidate findings'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that deliver purpose, key constraints, and behavioral notes without excess. Front-loaded with the primary action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is an output schema (not shown), the description adequately hints at return type. It covers main functionality and a dependency caveat. However, it could mention error cases or what 'install hint' entails.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, 'whitepaper_json', has no schema description (0% coverage). The description compensates by clarifying it is the 'draft MiCAR white paper (JSON)', adding semantic meaning about the expected input format and content.

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 'lint' and identifies the resource as a 'draft MiCAR white paper (JSON)' against specific rules (Annex I-III). This clearly distinguishes it from sibling tools like classify_eu_ai_act_system or search_micar_register.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the tool returns 'candidate findings pending human review' and mentions a required optional dependency (lint extra), giving context on when to use it. However, it does not explicitly state when not to use it or provide alternatives.

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

micar_register_changesC

Recent register movement: new filings, changed entries, removals.

change_type: all | added | changed | removed.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
change_typeNoall

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not state that the operation is read-only or non-destructive, nor does it mention any rate limits or side effects. The brief description only implies a query-like operation.

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 very short (two sentences) and front-loads the purpose. It avoids unnecessary words, though it could benefit from slightly more detail without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (two optional parameters, output schema present), the description is minimal but somewhat adequate. It explains the core purpose and one parameter, but lacks details on the limit parameter and usage context. The presence of an output schema mitigates the need to describe return values, but overall completeness is mediocre.

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?

The schema has 0% description coverage, so the description must explain parameters. It describes change_type with allowed values 'all | added | changed | removed', adding meaning beyond the schema. However, the limit parameter is not explained at all, making the description only partially helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool shows 'Recent register movement: new filings, changed entries, removals.' It indicates the tool retrieves recent changes, which is specific and differentiates from summary or search tools in the sibling list, though it lacks an explicit verb like 'list' or 'get'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 such as micar_register_summary or search_micar_register. The description does not mention context, prerequisites, or exclusions, leaving the agent to infer usage without direction.

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

micar_register_summaryA

Current totals per MiCAR register and white paper format coverage.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It states the output is 'current totals' and 'coverage', which is adequate for a simple read-only tool. However, it does not disclose update frequency, data sources, or any potential limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no fluff. It packs the essential information efficiently, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, single output) and the presence of an output schema, the description is largely complete. It lacks detail about what 'totals' and 'coverage' entail, but the output schema presumably fills those gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the schema coverage is 100% (empty). Thus, the description does not need to add parameter meaning. It implicitly communicates that no input is required, which is sufficient.

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 clearly states the tool provides 'current totals per MiCAR register and white paper format coverage'. It uses a specific resource (MiCAR register) and implies a verb (returns/provides). It distinguishes from sibling tools like 'search_micar_register' or 'lint_micar_whitepaper' which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or context for selection. The agent must infer usage from the tool name alone.

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

search_micar_registerA

Search the ESMA interim MiCAR register by entity name or LEI.

query: entity-name substring (case-insensitive) or an exact LEI. register_slug: all | other-wp | emt-wp | art-wp | casps | ncasp. member_state: optional two-letter code (DE, IE, MT, ...).

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
member_stateNo
register_slugNoall

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. While it describes what the tool does, it does not disclose behavioral traits such as whether the operation is read-only, authentication requirements, or rate limits. The return format is also not mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise, with a single clear sentence for the purpose and three short lines for parameter details. No extraneous information; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks information about the output, despite an output schema existing. It also does not explain the register_slug codes (e.g., what 'other-wp' means). Given the tool's moderate complexity, more context would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates well by explaining that query is a case-insensitive substring or exact LEI, register_slug lists possible values, and member_state is a two-letter code. It adds meaning beyond the schema, though defaults are not mentioned.

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 clearly states the tool searches the ESMA interim MiCAR register by entity name or LEI. It distinguishes from sibling tools like micar_register_changes and micar_register_summary, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for searching the register but does not explicitly state when to use this tool over alternatives. No when-not or exclusion criteria are provided, leaving the agent to infer from sibling tool names.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv0.1.0
    • First observedclassify_eu_ai_act_system
    • First observedlint_micar_whitepaper
    • First observedmicar_register_changes
    • First observedmicar_register_summary
    • First observedsearch_micar_register
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a distinct regulatory framework or operation: AI Act classification, MiCAR whitepaper linting, and three distinct register queries (changes, summary, search). Descriptions clearly differentiate purposes, leaving no ambiguity.

Naming Consistency3/5

Tool names use snake_case but mix verb-first (classify_eu_ai_act_system, lint_micar_whitepaper) and noun-first (micar_register_changes, micar_register_summary, search_micar_register). While descriptive, the pattern is not uniform, causing moderate inconsistency.

Tool Count5/5

With 5 tools covering two regulatory domains, the count is well-scoped. Each tool serves a clear purpose without redundancy or unnecessary expansion.

Completeness4/5

The tool set covers key functionalities for AI Act classification and MiCAR white paper linting and register querying. However, a dedicated tool for retrieving full register entry details beyond search is missing, and AI Act coverage lacks compliance or summarization tools.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • hivelaw

    srotzin
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server for AI compliance auditing. Scores agent outputs for hallucination liability under the EU AI Act, issues verifiable compliance stamps, and tracks audit history by agent.
    MIT

  • attestix

    VibeTensor
    A
    license
    Not graded
    quality
    B
    maintenance
    MCP server for compliance automation of AI agents, enabling EU AI Act compliance, verifiable credentials, and decentralized identity management with 47 tools across 9 modules.
    17
    Apache 2.0

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sebastianfoerste/eu-reg-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server