Skip to main content
Glama

Explain EU AI Act obligations

explain_obligation
Read-only

Get EU AI Act obligations for your role and risk tier, with Article citations and the competent national authority when country is supplied. Works offline.

Instructions

List the EU AI Act obligations for a role + risk tier, each with its Article citation. Pass country (and sector) to also get the competent national authority. Offline.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
riskYesThe risk tier, as returned by the classify tool. Do not guess it: call classify first and pass its "risk" value through, or the obligations returned will be confidently wrong.
roleYesWho the caller is for this system. "provider" develops or places it on the EU market under its own name and carries the Article 8 to 17 duties. "deployer" uses it under its own authority and carries Article 26. If the caller both builds and uses it, answer as provider.
sectorNoSector of the deployer, where it changes which authority is competent. Use "financial_services" for a company under financial-services supervision, "media" for broadcasting and press, "general" otherwise. Defaults to "general". Getting this wrong names the wrong regulator: in Germany a bank answers to BaFin and a broadcaster to its Bundesland, not to the default federal authority.
countryNoISO 3166-1 alpha-2 code of the member state the system is placed on the market in, e.g. "DE". Optional. Supply it to get the competent national authority alongside the obligations. Only states with a recorded primary source are mapped; for any other the response says so explicitly rather than guessing, and the EU-wide obligations are unaffected either way.
Install Server

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the read-only/destructive annotations, the description adds that every obligation is returned with its Article citation and that the tool is offline. There is no contradiction with annotations, and no destructive or open-world behavior is hidden.

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 carry the core purpose, optional-data behavior, and the offline constraint, with no filler. The most important information is front-loaded before the optional parameter note.

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 no output schema, the description states the response shape (obligations with Article citations, plus competent authority when country is passed). Combined with the richly documented input schema and read-only annotations, nothing essential is missing for correct invocation.

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 role, risk, sector, and country in detail. The description's mention of passing country/sector to get the regulator restates the schema rather than adding new parameter meaning; baseline 3 applies.

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 ('List') and a precise resource ('EU AI Act obligations for a role + risk tier'), and explicitly notes the Article citations and optional competent-authority output. This clearly differentiates it from siblings like classify (risk scoring) and generate_disclosure (document generation).

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?

It gives clear conditional usage for country and sector ('Pass country (and sector) to also get the competent national authority') and notes the tool is offline. It does not explicitly state when not to use it or name a sibling alternative, but the required role + risk inputs and optional extensions give a usable selection context.

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

Other Tools

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/legalithm-org/legalithm'

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