Skip to main content
Glama

Rekvira: EU regulation pinpoints for compliance AI

by com.rekvira
OverviewDiscussionsAdmin

Look up obligations by role

lookup_obligations
Read-onlyIdempotent

Articles whose official title names a role as an obligation addressee (e.g. role='deployer', optional system_class='high-risk'). Heading index, not annotated metadata — then read_unit the article. role accepts the word a title uses (deployer, provider, importer, operator, authorised representative, controller, processor, joint controller, data subject, or supervisory authority on gdpr). notified body on eu-ai-act returns Arts 34/45. Read also_named (Arts 31 through 38) for related titles without 'obligation'. When result_count is 0, read also_named before concluding none match (e.g. Arts 22/54 on eu-ai-act authorised representative; Arts 63/94 on eu-ai-act operator; Arts 29/39 on eu-ai-act conformity assessment body; Arts 76/77/85 on eu-ai-act market surveillance authority; Art 100 on eu-ai-act union institution; Arts 53/55/88 on eu-ai-act GPAI provider / general-purpose AI provider / provider of general-purpose AI models; Arts 13/14/21/22 on cra manufacturer / manufacturer of products with digital elements; when also_named is empty read heading_note and use search_regulation; Arts 24/26/27/29/79 on gdpr controller; Arts 27/28/29/79 on gdpr processor; Art 26 on gdpr joint controller; Arts 12/13/14/15/34/80 on gdpr data subject; Arts 31/33/51/53/54/56/60/62/77/78 on gdpr supervisory authority; Art 32 on nis2 essential entity; Arts 3/33/34 on nis2 important entity; Arts 23/31 on dora provider; Art 31 on dora ict third-party service provider; on dora financial entity or operator also_named is empty — read heading_note and use search_regulation for body mentions (Arts 28/30 for ICT third-party context); Art 18 on cra authorised representative). Then read_unit each article — the index is not a complete duty set.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleNoAddressee in the article title, e.g. deployer
limitNoMost rows to return (default 10 on searches, max 50)
queryNoAlias for role when agents pass search-style query= instead of role=
max_charsNoCap on the response size in characters (default 8000)
regulationNoRegulation id from list_regulations (required)
system_classNoOptional class in the same title, e.g. high-risk

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Most rows to return (default 10 on searches, max 50)",
+  "title": "Limit"
+}
    • addedInput schema / properties / max_chars
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Cap on the response size in characters (default 8000)",
+  "title": "Max Chars"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's burden is lower, yet it adds meaningful behavioral detail: indexing is by title only, result_count may be 0 even when related articles exist, and the index is deliberately 'not a complete duty set.' This prevents both false negatives and over-reliance on the tool's output.

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 core guidance is front-loaded and every sentence carries information, but the giant parenthetical list of per-regulation article examples makes the description dense and hard to scan. The structure would be easier to consume if the main workflow stayed separate from the exhaustive role/regulation mappings.

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?

Despite lacking an output schema, the description names the meaningful output signals (result_count, also_named, heading_note) and instructs on follow-up actions. For a complex 6-parameter lookup across multiple regulations, it gives an agent everything needed to call it correctly and interpret empty results.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds value by enumerating the accepted role words (deployer, provider, importer, etc.) and illustrating optional system_class like high-risk. It also gives regulation-specific examples that clarify how role values map to articles, going beyond the schema's one-sentence descriptions.

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 specifies a precise verb and resource: it returns 'Articles whose official title names a role as an obligation addressee.' It also differentiates this heading-index lookup from full article reads ('Heading index, not annotated metadata — then read_unit') and from search_regulation, so an agent can distinguish it from siblings.

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

Usage Guidelines5/5

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

It gives explicit when-to-use and follow-up instructions: use the role's title word, read_unit each returned article, check also_named before concluding no match, and fall back to search_regulation when also_named is empty. This is far beyond a vague 'use for role lookups' and routes the agent away from incorrect conclusions.

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

All Rekvira: EU regulation pinpoints for compliance AI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources