How do I use disclos-eu-ai-act?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@disclos-eu-ai-act Classify our AI screening tool for hiring under the EU AI Act." 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.

disclos-eu-ai-act

by GatisOzols

Overview Schema Related Servers Score Discussions

JavaScript

Local

disclos-eu-ai-act

An MCP server that lets AI assistants (Claude Desktop, Claude Code, Cursor, Windsurf, and any MCP-compatible client) classify an AI system under the EU AI Act — Regulation (EU) 2024/1689.

Ask your assistant a plain-English question and it returns a structured scope finding: the risk tier, the obligations, and the deadlines.

Built and maintained by Disclos — fixed-price EU AI Act audits for SaaS companies.

What it does

Four tools:

Tool	What it returns
`classify_ai_system`	A full scope finding — tier, obligations, deadline, and the exact EUR-Lex article — from a description of the product.
`eu_ai_act_timeline`	The enforcement timeline (Feb 2025 → Aug 2028) and what takes effect on each date.
`explain_tier`	A detailed explanation of one risk tier and its duties.
`framework_crosswalk`	Maps an EU AI Act tier to the equivalent controls in ISO/IEC 42001, NIST AI RMF, and GDPR.

It tests every tier the Act defines: prohibited (Art 5), high-risk (Annex III), GPAI provider (Art 53), transparency (Art 50), minimal, and out of scope — flags the common mistake of over-classifying as high-risk, and links every finding to the official EUR-Lex text.

Related MCP server: ai-act-mcp

TL;DR — 60-second install (Claude Desktop)

Add this to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "disclos-eu-ai-act": {
      "command": "npx",
      "args": ["-y", "github:GatisOzols/disclos-eu-ai-act"]
    }
  }
}

Restart Claude Desktop, then ask:

"We run a B2B SaaS with an AI chatbot and some EU customers. Are we in scope under the EU AI Act, and at what tier?"

Claude calls classify_ai_system and returns a finding with the tier, obligations, and the relevant deadline.

Run from source

git clone https://github.com/GatisOzols/disclos-eu-ai-act
cd disclos-eu-ai-act
npm install
npm start            # starts the server on stdio

Then point any MCP client at node /path/to/src/index.js.

How it works

A small, deterministic classifier maps six yes/no facts about your product to the Act's tiers. No network calls, no data collection, no tracking — everything runs locally on stdio.

Accuracy & limits

The logic follows the public text of Articles 5, 6, 50, 53 and Annex III.
It's a screening aid, accurate for most straightforward SaaS products.
Edge cases (multi-modal systems, mixed provider/deployer roles, biometric inference) need a human review.
This is general information, not legal advice.

License

Available Tools

4 tools

classify_ai_systemA

Classify an AI system or product under the EU AI Act (Regulation (EU) 2024/1689) and return its risk tier, obligations and deadlines. Map the user's description to the boolean flags below. When unsure, ask the user or choose the more cautious answer. Returns a structured 'scope finding'.

ParametersJSON Schema

Name	Required	Description
`eu_exposure`	Yes	Is the product available to people in the EU, or are its outputs used in the EU? Company location is irrelevant.
`has_ai_feature`	Yes	Does the product include any AI feature? (chatbot, content generation, recommendations, ranking/scoring, predictions, automated decisions)
`system_description`	No	Optional: short free-text description of the AI system, for the record.
`annex_iii_high_risk`	Yes	Is it used for an Annex III high-risk purpose? (biometric ID, critical infrastructure safety, education/exam scoring, hiring/worker management, access to essential services or creditworthiness, law enforcement, migration/border, justice)
`prohibited_practice`	Yes	Does it do an Article 5 banned practice? (social scoring, harmful manipulation, exploiting vulnerabilities, untargeted face scraping, real-time remote biometric ID in public, emotion recognition at work/school, biometric categorisation by sensitive traits)
`provides_own_gpai_model`	Yes	Does the user TRAIN or PROVIDE their own general-purpose AI model? Using someone else's model via an API is false.
`user_facing_or_generative`	Yes	Does it interact directly with people (chatbot) or generate/meaningfully alter content (text, image, audio, video, deepfakes)?

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It discloses that the tool may ask the user or opt for a cautious answer when uncertain, and that it returns a structured 'scope finding'. These are meaningful behavioral traits beyond the basic function, though it doesn't discuss side effects (likely none) or detailed output schema specifics.

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 three sentences: first states the core purpose, second explains the mapping/flag behavior, third addresses uncertainty handling. Every sentence earns its place with no redundancy or fluff.

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 complexity (7 params, no output schema), the description adequately covers purpose, return values (risk tier, obligations, deadlines, structured finding), and ambiguity handling. While it doesn't detail the structured finding's fields or differentiate from siblings, the schema's rich parameter descriptions complement the description well.

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% with detailed explanations for each boolean flag, so the baseline is 3. The description adds minimal parameter-level meaning, only mentioning mapping user descriptions to flags, which is somewhat vague. It doesn't compensate or enhance beyond the schema.

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 AI systems under the EU AI Act and returns risk tier, obligations, and deadlines. This specific verb+resource+output distinguishes it from sibling tools like eu_ai_act_timeline or explain_tier.

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?

It provides some guidance on handling uncertainty ('ask the user or choose the more cautious answer') and hints at mapping user descriptions to boolean flags, but it does not explicitly contrast with sibling tools or state when to choose this tool over alternatives. The usage context is implied but exclusions/alternatives are missing.

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

eu_ai_act_timelineA

Return the EU AI Act enforcement timeline — the key dates and what takes effect on each.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are present, so the description must fully convey behavior. It indicates a read-only informational tool that returns key dates and effects, but does not mention data recency, comprehensiveness, or return format. This is adequate for a simple timeline tool, but additional context (e.g., 'static reference' or 'covers all phases') would improve transparency.

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, well-structured sentence with no filler. It front-loads the action ('Return') and resource ('EU AI Act enforcement timeline'), followed by a concise clarification of content ('key dates and what takes effect'), making it immediately understandable.

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, no output schema, no annotations), the description is sufficient to convey its purpose and expected content. It does not specify whether the output is a list, text, or the exact coverage of phases, but for a basic timeline retrieval tool, this is acceptable. Sibling tools don't require additional context for this descriptor.

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 zero parameters, so there is no semantic burden on the description. The empty input schema already provides complete coverage, and the description appropriately adds no parameter details. This aligns with the baseline of 4 for tools with no parameters.

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 specifies the tool's function: returning the EU AI Act enforcement timeline with key dates and their effects. It uses a specific verb and resource, and the scope (EU AI Act) distinguishes it from sibling tools like classify_ai_system and explain_tier, which serve 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?

No explicit when-to-use or alternative guidance is provided. However, the tool's purpose is self-evident from the name and description, and sibling tools handle classification, tier explanation, and crosswalks, so using this tool for timeline queries is implied. A more explicit note about when to prefer it over siblings would have raised the score.

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

explain_tierA

Explain a single EU AI Act risk tier in detail: what it means, the obligations, and the deadline.

ParametersJSON Schema

Name	Required	Description	Default
`tier`	Yes	One of: out_of_scope, prohibited, high_risk, gpai, transparency, minimal.

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses what the explanation covers (meaning, obligations, deadline), setting expectations for the response content. However, it does not describe output format or limitations, but for a simple explanation tool this is largely sufficient.

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 one sentence, front-loaded with the verb 'Explain', and directly states the tool's core purpose and content areas. There is no redundant or extraneous text.

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 simplicity (one enum parameter, no output schema, no annotations), the description fully captures what the tool does and what it returns. It explicitly lists the three content areas covered, making it adequate for an agent to select and invoke the tool 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 schema already documents the 'tier' parameter and its enum values. The description adds minimal extra meaning ('single' implies one tier at a time), but it does not elaborate on each enum value's semantics, which the schema already enumerates.

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's function: explaining a single EU AI Act risk tier in detail, including meaning, obligations, and deadline. This distinguishes it from sibling tools like classify_ai_system (classification), eu_ai_act_timeline (timeline), and framework_crosswalk (mapping).

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 phrase 'a single...risk tier' clarifies the scope and suggests use when deep-diving into one tier. However, it does not explicitly mention when not to use this tool or alternatives, though the sibling tools indicate related but different purposes.

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

framework_crosswalkA

Map an EU AI Act risk tier to the equivalent controls in adjacent governance frameworks — ISO/IEC 42001, NIST AI RMF, and GDPR. Use when the user asks how the EU AI Act lines up with ISO 42001, NIST, GDPR, or their existing compliance program.

ParametersJSON Schema

Name	Required	Description	Default
`tier`	Yes	The EU AI Act tier to cross-map. One of: out_of_scope, prohibited, high_risk, gpai, transparency, minimal.

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the transparency burden. The core behavior is clear ('map ... to equivalent controls'), but it does not disclose additional behavioral aspects such as what the output looks like, whether it is a read-only operation, or any limitations. This is adequate but not rich.

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 sentences, front-loaded with the primary action, no redundant information. Every word earns its place, making this appropriately concise.

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?

The tool has a single parameter, no output schema, and no annotations. The description covers purpose and usage adequately for its low complexity, but it does not describe the output structure or what 'equivalent controls' entail. This is a minor gap, so a 4 is appropriate.

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%, with the single parameter 'tier' fully described in the schema including its enum values. The description adds only the term 'risk tier', which is already implied by the schema, so it provides no significant extra meaning beyond the baseline.

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 action ('map') and the resource ('EU AI Act risk tier to equivalent controls in adjacent governance frameworks'), and it explicitly names the target frameworks. This distinguishes it from siblings like classify_ai_system and explain_tier, which focus on classification or explanation rather than cross-framework mapping.

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 second sentence gives explicit when-to-use guidance: 'Use when the user asks how the EU AI Act lines up with ISO 42001, NIST, GDPR, or their existing compliance program.' However, it does not mention when not to use or alternative tools, so it falls short of a 5.

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

Install Server

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

TDQS

A4.1/5.0

Disambiguation4/5

The tools are mostly distinct: classify_ai_system maps user input to a risk tier, explain_tier describes a known tier, while timeline and crosswalk serve clear reference purposes. There is slight overlap between classify_ai_system and explain_tier (both return obligations and deadlines), but their primary functions differ enough to avoid confusion.

Naming Consistency3/5

All names use snake_case, but the pattern is mixed: classify_ai_system and explain_tier are verb_noun, while eu_ai_act_timeline and framework_crosswalk are noun phrases. The inconsistency in starting part (verb vs. noun) makes the set slightly less predictable.

Tool Count5/5

Four tools is well-scoped for an information-focused EU AI Act server. Each tool covers a specific high-level user need without redundancy, and the count is neither too thin nor excessive.

Completeness4/5

The set covers classification, timeline, tier explanations, and cross-framework mapping, which addresses common compliance questions. Minor gaps exist (e.g., no tool for searching specific legal provisions or compliance checklists), but the core workflows are covered and agents can work around these gaps.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Warden
io.github.Larshiensch99
Register every AI agent, log every action, prove it. EU AI Act compliance built in.
Observability Security
2
mcp-agentcore A
com.geiant
AI governance MCP server for EU AI Act compliance and jurisdiction verification
Legal & Compliance AI & Machine Learning Government Data
32
Sovereignty Scan A
io.github.kajaril
EU AI Act sovereignty scanning. Provider residency, registration status, audit trail support.
Legal & Compliance Monitoring
21
VITNA — Agent Compliance Preflight A
xyz.costrinity
Pre-action allow/deny for AI agents. 24 statutes, 13 jurisdictions: EU AI Act, GDPR, DPDP.
Legal & Compliance Security Autonomous Agents
231

Related MCP Servers

EU AI Act Compliance MCP
Legal & Compliance Security
SonnyLabs
A
license
A
quality
D
maintenance
Provides automated EU AI Act compliance tools, including risk classification, role determination, transparency disclosures, content watermarking, deepfake labeling, and security threat detection.
Updated 9 months ago (2025-12-17 21:40 UTC)
16
32
Apache 2.0
ai-act-mcp
Legal & Compliance Developer Tools
a2welt
A
license
A
quality
D
maintenance
Enables EU AI Act compliance assessment by classifying AI systems, listing obligations, computing deadlines, and scanning repos for required documentation, all running locally.
Updated 3 months ago (2026-06-10 16:13 UTC)
4
2
MIT
Legalithmofficial
Legal & Compliance AI & Machine Learning
legalithm-org
A
license
A
quality
A
maintenance
EU AI Act compliance in your editor.Classify risk, cite obligations, draft Article 50 disclosures. Offline, no API key.
Updated 17 hours ago (2026-09-03 18:10 UTC)
2
7
MIT
AI Act Sentinel
Legal & Compliance Documentation Access
PierpyRenda
A
license
Not graded
quality
B
maintenance
MCP server for EU AI Act compliance analysis — classify any AI system or workflow against Regulation (EU) 2024/1689, updated with AI Omnibus 2026.
Updated a month ago (2026-07-21 12:21 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/GatisOzols/disclos-eu-ai-act'

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

disclos-eu-ai-act

What it does

TL;DR — 60-second install (Claude Desktop)

Run from source

How it works

Accuracy & limits

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Legalithmofficial

Latest Blog Posts

MCP directory API