Skip to main content
Glama
Sign In

mcp-eu-ai-act

by io.github.ark-forge
OverviewDiscussionsAdmin

gdpr_check_compliance

Check whether your project passes or fails each GDPR requirement — no arguments. See pass/fail for lawful basis (Art. 6), consent (Art. 7), data subject rights (Art. 15–22), security (Art. 32), and breach notification (Art. 33–34) with fix instructions for every gap. GDPR fines reach 20M EUR or 4% turnover. For EU AI Act + GDPR together, call combined_compliance_report().

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "gdpr_check_compliance"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_pathNoPath to the project root. Leave empty or pass '.' to check the current directory..
processing_roleNoGDPR role: controller, processor, or minimal_processing.controller

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / processing_role / description
      Added value: +"GDPR role: controller, processor, or minimal_processing."
    • addedInput schema / properties / project_path / default
      Added value: +"."
    • addedInput schema / properties / project_path / description
      Added value: +"Path to the project root. Leave empty or pass '.' to check the current directory."
    • removedInput schema / required
      Removed value: -[
-  "project_path"
-]
  2. First observed

TDQS

C2.8/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 behavioral disclosure. It reveals the output format (pass/fail per article, fix instructions) but fails to mention that the tool takes arguments (or that they are optional), and does not explain how the compliance check is performed (e.g., static analysis, scanning files). The 'no arguments' statement is actively misleading about the tool's behavior.

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

Conciseness3/5

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

The description is reasonably concise (four sentences) and front-loads the primary purpose. However, the sentence about GDPR fines ('GDPR fines reach 20M EUR or 4% turnover') is promotional and not directly relevant to tool invocation, adding unnecessary noise. The structure could be tightened by removing that filler and correcting the parameter claim.

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

Completeness2/5

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

The tool has no output schema and no annotations, so the description needs to provide complete context. It does well by outlining the covered articles and the pass/fail output with fix instructions. But it fails to mention the two optional parameters, misrepresents argument usage, and lacks any explanation of the underlying mechanism (e.g., does it scan the project path?). This leaves significant gaps for an agent deciding how to call it.

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

Parameters2/5

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

Schema coverage is 100% (both project_path and processing_role have descriptions), so the baseline would be 3. However, the description's assertion 'no arguments' directly contradicts the schema, adding no value and potentially confusing an agent. The parameter descriptions in the schema are self-explanatory, but the false claim in the description outweighs the baseline benefit.

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's purpose: 'Check whether your project passes or fails each GDPR requirement' and lists specific articles (Art. 6, 7, 15–22, 32, 33–34), giving a focused scope. It also distinguishes itself from combined_compliance_report by directing users there for EU AI Act + GDPR. However, the claim 'no arguments' is inaccurate given the input schema, which slightly undermines clarity.

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 explicitly names an alternative: 'For EU AI Act + GDPR together, call combined_compliance_report().' This provides a clear when-to-use vs. alternative. However, the misleading statement 'no arguments' contradicts the actual schema and could cause an agent to ignore the optional project_path and processing_role parameters, which is a significant usage guidance flaw.

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

All mcp-eu-ai-act toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources