Click on "Deploy 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., "@disclos-article-50 Generate disclosure for my AI chatbot in German and French."
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.
An MCP server that generates the exact EU AI Act Article 50 transparency disclosure you have to show users, in all 24 EU languages, with copy-paste code.
Article 50 is the part of the Act that hits almost every SaaS shipping an AI feature into the EU, and it takes effect on 2 August 2026. This tool hands you the right disclosure text and tells you where to put it, from inside Claude or Cursor.
Built and maintained by Disclos. The companion classifier is disclos-eu-ai-act.
Two tools:
Tool | What it returns |
| The visible label for your use case in the language you pick, where and when to show it, and a copy-paste snippet (HTML for chatbots, a machine-readable marker for generated content). |
| From a few yes/no facts about your product, which Article 50 sub-rules apply, and the use cases to generate. |
It covers all four Article 50 duties: AI interaction (50(1)), synthetic content (50(2)), emotion recognition and biometric categorisation (50(3)), and deepfakes (50(4)). Languages: all 24 official EU languages (English, German, French, Spanish, Italian and Dutch are the maintained translations; the other 18 are first-pass and should be reviewed before you rely on them).
Related MCP server: EU AI Act Compliance MCP Server
Add this to your Claude Desktop config
(~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"disclos-article-50": {
"command": "npx",
"args": ["-y", "github:GatisOzols/disclos-article-50"]
}
}
}Restart Claude Desktop, then ask:
"I run an AI chatbot with German and French users. Give me the Article 50 disclosure I need to show them."
Claude calls article_50_disclosure and returns the label, the rules, and the
HTML to paste in.
git clone https://github.com/GatisOzols/disclos-article-50
cd disclos-article-50
npm install
npm startAll 24 EU languages are included here. The six core ones (English, German, French, Spanish, Italian, Dutch) are the maintained Disclos translations, also published in the open-source eu-ai-act-checklist. The canonical generator lives at https://www.disclos.eu/tools/article-50-disclosure-generator.
The text follows the public structure of Article 50. It is a drafting aid for the common cases, accurate for most straightforward SaaS products.
Sensitive cases (biometric categorisation, deepfakes of real people) can cross into prohibited or high-risk territory and need a human review.
English, German, French, Spanish, Italian and Dutch are the maintained translations. The other 18 EU languages are first-pass and should be checked by a native speaker before you rely on them.
This is general information, not legal advice.
MIT © 2026 Gatis Ozols / Disclos. Original work, free to use, copy, modify and share.
Generate the exact EU AI Act Article 50 transparency disclosure you must show users, for a given use case and language. Returns the visible label, where and when to show it, and a copy-paste implementation snippet. Covers chatbots (50(1)), AI-generated content (50(2)), emotion recognition and biometric categorisation (50(3)), and deepfakes (50(4)).
| Name | Required | Description | Default |
|---|---|---|---|
| use_case | Yes | One of: chatbot, generated_content, deepfake, emotion_recognition, biometric_categorisation. | |
| language | No | Disclosure language. Any of the 24 official EU language codes (e.g. en, de, fr, pl, el, mt). Defaults to en. | |
| company | No | Optional: your company name, used in the machine-readable marker for generated content. | |
| model | No | Optional: the AI model name and version, used in the machine-readable marker for generated content. |
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 describes what the tool returns (visible label, where/when to show, implementation snippet) and mentions coverage of specific paragraphs, but it does not disclose any behavioral traits such as whether it is read-only, requires authentication, or has rate limits. For a generation tool, this is adequate but not comprehensive.
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 a single paragraph of three sentences, concise and front-loaded with the main purpose. No unnecessary words. Slightly more structure (e.g., bullet points for returns) could improve scannability, but it is efficient.
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 no output schema, the description adequately explains return values (visible label, where/when to show, implementation snippet). It covers all four parameters and references specific sub-sections (50(1)-50(4)). No output schema or nested objects, so the description provides sufficient completeness for this 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?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that company and model are used for the machine-readable marker and lists the use case categories and language codes contextually, going beyond the 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?
The description clearly states the tool generates the exact EU AI Act Article 50 transparency disclosure for a given use case and language, listing covered categories. It distinguishes from the sibling tool which_article_50_rules_apply but could be more explicit about the exact distinction.
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 by stating 'for a given use case and language' and listing what it covers, but it does not explicitly state when to use this tool versus the sibling or provide exclusions. The sibling tool name suggests a complementary role, but no direct comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Work out which Article 50 transparency duties apply to a product, from a few yes/no facts. Returns the relevant sub-rules and the use_case keys to feed into article_50_disclosure.
| Name | Required | Description | Default |
|---|---|---|---|
| interacts_with_users | Yes | Does it hold a conversation with people? (chatbot, voice assistant, AI support agent) | |
| generates_or_alters_content | Yes | Does it generate or meaningfully alter text, image, audio, or video output? | |
| deepfakes_real_subjects | Yes | Does the generated content resemble real people, objects, places, or events? (deepfakes) | |
| emotion_or_biometric | Yes | Does it recognise emotions or categorise people by biometric characteristics? |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently states the tool returns relevant sub-rules and use_case keys, and implies it is a computational classification without side effects. No contradictions or hidden behaviors.
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?
Two sentences, front-loaded with purpose, no wasted words. Every sentence earns its place.
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 boolean-input tool with full schema coverage, the description adequately explains output and purpose. Lack of output schema is mitigated by describing return values (sub-rules and keys). Minor gap: no detail on output format or edge cases.
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 baseline is 3. The description only references inputs as 'a few yes/no facts' without adding new meaning beyond the schema's detailed parameter 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 specifies the verb 'Work out', the resource 'Article 50 transparency duties', and the input type (yes/no facts). It explicitly distinguishes from the sibling tool by mentioning the output feeds into article_50_disclosure, making purpose and differentiation clear.
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 determining applicable transparency duties based on facts, and suggests a workflow by stating output keys feed into article_50_disclosure. However, no explicit when-not or alternative scenarios are provided.
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.
v0.1.0article_50_disclosurewhich_article_50_rules_applyScored across 2 tools
The two tools have completely distinct purposes: one identifies applicable rules, the other generates the disclosure. There is no overlap or ambiguity.
Both tool names follow a clear, descriptive pattern using snake_case with specific nouns and verbs, making them predictable and understandable.
Two tools is minimal but appropriate for the narrow domain of Article 50 compliance. It covers the essential workflow without unnecessary bloat.
The tool set covers the full process: first determine which rules apply, then generate the appropriate disclosure. No obvious gaps for this specific purpose.
One-step legal compliance for vibe-coded apps: privacy, terms, cookie banner and EU AI Act check.
MEOK EU AI Act Article 13 Instructions for Use generator — provider-side IFU with 7 mandatory Art
Compliance lint for AI, scraping, and privacy law. Cited findings in 200 or more jurisdictions.
MEOK EU AI Act Article 26(9) Fundamental Rights Impact Assessment generator. Auto-generates FRIA
