Read-only EU AI Act (Reg. 2024/1689 as amended) answers, citing official sources
Scored across 9 tools
Most tools are clearly distinct by resource type: articles, annexes, recitals, definitions, deadlines, search, and feedback. The only mild overlap is between assess_compliance and get_obligations, since both return obligation information, but their scopes (entity-specific assessment vs. role-based listing) are sufficiently differentiated by descriptions.
All tool names follow a consistent snake_case verb_noun pattern (get_article, get_annex, search_text, assess_compliance, send_feedback). The verbs vary appropriately by action but remain predictable and readable.
Nine tools are well-scoped for an EU AI Act explorer covering retrieval, search, compliance assessment, deadlines, and feedback. Each tool earns its place without redundancy.
The surface covers core legal text retrieval (articles, annexes, recitals, definitions), search, deadlines, obligations, compliance assessment, and feedback. A minor gap is the lack of a browse/list tool for articles or table of contents, though search_text largely mitigates this.
Run the EU AI Act compliance assessment: given the entity's answers (same decision tree as the interactive checker on euaiactlaw.com), returns the applicable roles, risk classification, full obligation list with legal basis and deadlines, and notes (e.g. Annex I Section B reduced regime, open-source GPAI exception, Art 27(3) NCA notification, distributor obligations under Art 24). Pass answers keyed by step id (E1, E2, S1, R1-R5, HR1-HR6, ...); E1 (roles) is required. Multi-select steps take arrays of option ids; single-choice steps take one option id.
| Name | Required | Description | Default |
|---|---|---|---|
| E1 | Yes | What is your role in relation to the AI system? Options: provider = Provider; deployer = Deployer; distributor = Distributor; importer = Importer; product_manufacturer = Product Manufacturer; auth_rep = Authorised Representative. Omit keys that do not apply to your scenario. | |
| E2 | No | Do you or any downstream entity make any of these modifications? Options: rename = Putting a different name or trademark on the system; repurpose = Modifying the intended purpose of a system already in operation; substantial_mod = Performing a substantial modification (Article 3(23)) to the system; none = None of the above. Omit keys that do not apply to your scenario. | |
| E3 | No | Does your product integrate an AI system and meet either criterion? Options: ai_with_product = AI system placed on the market together with the product under manufacturer name/trademark; ai_after_product = AI system put into service under manufacturer name/trademark after product placed on market; none = None of the above. Omit keys that do not apply to your scenario. | |
| R1 | No | Does your AI model meet any systemic risk criteria? (GPAI only) Options: high_flops = High impact capabilities (trained with cumulative compute >10²⁵ FLOPs); commission_decision = Commission has decided the model has high capabilities or impact (Annex XIII criteria); none = None of the above (or this is not a GPAI model). Omit keys that do not apply to your scenario. | |
| R2 | No | Does your system or use-case fall within any exclusion category? Options: military = AI systems developed and used exclusively for military purposes; third_country_law = Public authorities / international organisations in third countries using AI for law enforcement or judicial cooperation; research = AI research and development activity (not yet placed on market); open_source = AI components provided under free and open-source licences; personal_use = Purely personal, non-professional activity by a natural person; none = None of the above. Omit keys that do not apply to your scenario. | |
| R3 | No | Does your system perform any prohibited AI practices? Options: subliminal = Subliminal techniques, manipulation, or deception; vulnerable_exploit = Exploiting vulnerabilities of specific groups; biometric_categorisation_prohibited = Biometric categorisation to infer sensitive attributes; social_scoring = Social scoring — evaluating or classifying persons based on social behaviour; predictive_policing = Predictive policing based solely on profiling or personality traits; facial_scraping = Untargeted scraping of facial images from internet/CCTV to expand databases; emotion_recognition_prohibited = Emotion recognition in workplace or educational institutions; realtime_rbi = Real-time remote biometric identification in publicly accessible spaces for law enforcement; nonconsensual_intimate = Generating or manipulating non-consensual intimate material or child sexual abuse material; none = None of the above. Omit keys that do not apply to your scenario. | |
| R4 | No | Does your system perform any transparency-triggering functions? Options: deepfake = Generating or manipulating image/audio/video constituting a deep fake; public_interest_text = Generating or manipulating text published for matters of public interest (e.g., news); emotion_biometric = Emotion recognition or biometric categorisation (non-prohibited); natural_persons = Interacting directly with natural persons (e.g., chatbot); synthetic_content = Generating synthetic audio, image, video, or text content; none = None of the above. Omit keys that do not apply to your scenario. | |
| R5 | No | Are you a body governed by public law, or a private entity providing public services, or operating in insurance/banking? Options: yes = Yes — public law body, public service provider, or insurance/banking entity; no = No — private entity not providing public services and not in insurance/banking. Omit keys that do not apply to your scenario. | |
| S1 | No | Do you meet any of the following criteria for EU AI Act applicability? Options: placing_eu = I am placing on the market or putting into service AI systems in the EU; gpai_eu = I am placing on the market General Purpose AI (GPAI) models in the EU; established_eu = I am established or located within the EU; importer_eu = I am an importer placing on the EU market a system bearing a non-EU entity name; distributor_eu = I am a distributor making an AI system available on the EU market; output_eu = My AI system's output is used in the EU; none = None of the above. Omit keys that do not apply to your scenario. | |
| HR1 | No | Does your AI system fall within any Annex I, Section B categories? Options: aviation_security = Civil aviation security; motor_type_approval = Motor vehicles type approval; machinery = Machinery; vehicles_two_three = Two/three-wheel vehicles and quadricycles; agri_vehicles = Agricultural and forestry vehicles; marine = Marine equipment; rail = Interoperability of rail systems; motor_vehicles = Motor vehicles and their trailers; civil_aviation = Civil aviation; none = None of the above. Omit keys that do not apply to your scenario. | |
| HR2 | No | Does your AI system fall within any Annex I, Section A categories? Options: toys = Toys; recreational = Recreational craft & personal watercraft; lifts = Lifts and safety components of lifts; atex = Equipment for potentially explosive atmospheres; radio = Radio equipment; pressure = Pressure equipment; cableway = Cableway installations; ppe = Personal protective equipment; gas = Appliances burning gaseous fuels; medical = Medical devices; ivd = In vitro diagnostic medical devices; none = None of the above. Omit keys that do not apply to your scenario. | |
| HR3 | No | Is your product required to undergo third-party conformity assessment under the applicable EU laws? Options: yes = Yes — third-party conformity assessment is required; no = No — manufacturer self-declaration or no third-party assessment required. Omit keys that do not apply to your scenario. | |
| HR4 | No | Does your AI system fall within any Annex III high-risk categories? Options: biometrics = Biometrics; critical_infra = Critical infrastructure; education = Educational and vocational training; employment = Employment, workers management, self-employment access; essential_services = Access to essential private/public services and benefits; law_enforcement = Law enforcement; migration = Migration, asylum, border control; justice = Administration of justice and democratic processes; none = None of the above. Omit keys that do not apply to your scenario. | |
| HR5 | No | Does your AI system pose a significant risk of harm to health, safety, or fundamental rights? Options: yes = Yes — poses significant risk (or system performs profiling of natural persons); no = No — meets one of the Art 6(3) derogation conditions. Omit keys that do not apply to your scenario. | |
| HR6 | No | Does your product include an AI system as a "safety component" AND fall within Annex I, Section A categories? Options: toys = Toys; recreational = Recreational craft & personal watercraft; lifts = Lifts and safety components of lifts; atex = Equipment for potentially explosive atmospheres; radio = Radio equipment; pressure = Pressure equipment; cableway = Cableway installations; ppe = Personal protective equipment; gas = Appliances burning gaseous fuels; medical = Medical devices; ivd = In vitro diagnostic medical devices; none = None of the above. Omit keys that do not apply to your scenario. |
| Name | Required | Description |
|---|---|---|
| route | No | |
| groups | No | |
| source | No | |
| statuses | Yes | |
| terminal | Yes | |
| obligations | Yes | |
| checker_link | No | |
| obligation_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as a read-only, idempotent, non-destructive operation. The description adds useful behavioral context: it discloses that the tool follows the same decision tree as the interactive checker and returns roles, risk classification, obligations, deadlines, and special-case notes such as the Annex I Section B reduced regime and open-source GPAI exception.
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 front-loaded with purpose and output scope, followed by concise input conventions. Despite being a single paragraph, every sentence earns its place for a complex 15-parameter assessment tool, and the parenthetical examples clarify special-case outputs without wasting space.
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?
The tool is complex, with 15 parameters and an output schema, but the description supplies the essential context an agent needs: what the assessment returns, how to key answers, which parameter is required, and how array versus scalar steps work. The output schema and annotations cover the remaining structured details.
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 the schema already documents each answer key and its enum values. The description adds meaningful input mechanics beyond the schema: answers must be keyed by step id, E1 is required, multi-select steps use arrays of option ids, and single-choice steps use one option id.
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 states a specific verb and resource: 'Run the EU AI Act compliance assessment.' It also summarizes the outputs (roles, risk classification, obligations with legal basis and deadlines, and notes), making the tool's function clear without needing the schema.
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 gives clear usage context: it is used when you have the entity's answers and need a compliance assessment. It specifies that E1 is required and how to pass multi-select versus single-choice answers. It does not explicitly compare against sibling retrieval tools like get_obligations, but the assessment context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full text of one annex of the EU AI Act (roman numeral).
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Annex number as roman numeral, e.g. "III", "XIV" |
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| title | No | |
| number | Yes | |
| permalink | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered without prose. The description adds only that the entire annex text is returned in one call, with no notes on truncation, failure modes for invalid numerals, or citation format.
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?
A single sentence with the resource and identifier type front-loaded, and nothing that could be trimmed without losing information.
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?
An output schema exists, so the description needn't explain return values, and annotations cover behavior for this read-only lookup. What remains unstated, such as handling an invalid or nonexistent annex number, is minor for a one-parameter getter.
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% and the parameter already carries the example '"III", "XIV"'. The description's '(roman numeral)' merely echoes that constraint, adding no new syntax, validation, or edge-case information.
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?
States a specific verb ('Get') and resource ('full text of one annex of the EU AI Act'), which clearly separates it from the sibling get_article and get_recital tools. The parenthetical '(roman numeral)' clarifies the identifier form but the description never names the alternatives, so differentiation is implicit rather than explicit.
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?
Usage is only implied: an agent can infer this is the tool for retrieving annex text when an article or recital won't do. There is no explicit when-to-use guidance, no mention of when to prefer get_article or search_text, and no stated preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full amended text of one article of the EU AI Act, including lettered numbers such as "60a".
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Article number, e.g. "6", "25", "60a" |
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| title | Yes | |
| eurlex | No | |
| number | Yes | |
| permalink | Yes | |
| effective_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine context: the returned text is the 'full amended' version rather than an excerpt, which tells the agent it gets the current consolidated article in its entirety.
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?
A single front-loaded sentence with zero waste; the scope constraint and the lettered-number caveat are both packed into one clause without padding.
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?
A one-parameter read tool with a full output schema and rich annotations needs little more than this. Nothing an agent requires to call it correctly is missing.
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 the single 'number' parameter is already documented with examples. The mention of lettered numbers such as "60a" restates the schema example rather than adding new format or edge-case meaning, so baseline 3 applies.
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?
States a specific verb (Get) and resource (full amended text of one article of the EU AI Act), and the resource name itself separates it from siblings like get_annex, get_recital and get_definition. An agent can tell exactly what it retrieves without opening the schema.
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?
Usage is implied: fetch a specific article by its number. There is no explicit guidance on when to prefer this over search_text or the other get_* siblings, and no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show which EU AI Act obligations and phases are in force or pending as of a given date.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO date, e.g. "2027-06-01". Defaults to today. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | |
| phases | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, and an output schema exists, so the bar is lower. The description adds the useful behavioral point that results are a snapshot of what is in force vs pending at a date, but nothing about ordering, granularity or date-boundary handling.
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?
A single front-loaded sentence with no filler; the temporal qualifier is placed where it matters.
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?
With annotations, a fully documented single parameter and an output schema, the description covers what an agent needs to select and call it. Only a small gap remains around what a 'phase' comprises and how boundary dates are treated.
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 coverage is 100% and the single 'date' parameter is documented with ISO format and a default of today. The description only echoes the date scoping, adding no format or edge-case detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb ('Show which... obligations and phases') plus the resource (EU AI Act obligations/phases) and the temporal lens ('in force or pending as of a given date'). It is distinguishable from get_obligations by the in-force/pending framing, though no sibling is named explicitly.
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 'as of a given date' phrasing implies the temporal use case (checking status at a point in time), but the description never says when to prefer this over get_obligations or assess_compliance, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Article 3 definition of a term used in the EU AI Act.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The defined term, e.g. "provider", "high-risk AI system" |
| Name | Required | Description |
|---|---|---|
| term | Yes | |
| text | Yes | |
| permalink | Yes | |
| reference | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the result is specifically the Article 3 definition, but it does not disclose matching behavior (exact vs. fuzzy) or what happens when a term is not defined in Article 3.
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?
A single, front-loaded sentence with zero wasted text. The scope and action are immediately clear.
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?
The tool is simple, has a fully documented single parameter, an output schema, and rich annotations. The only meaningful gap is that term-matching and not-found behavior are not described, which could matter for correct invocation.
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% and the term parameter already includes examples such as "provider" and "high-risk AI system". The description adds only the domain constraint that the term is used in the EU AI Act, without extra syntax or matching details.
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 uses a specific verb ("Get") and resource ("Article 3 definition of a term") and scopes it to the EU AI Act. It is clearly distinguishable from siblings like get_article, get_recital, or search_text.
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?
Usage is implied: use this when you need the legal definition of a term. However, it does not explicitly say when to prefer this over get_article or search_text, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the obligations for a role under the EU AI Act, optionally filtered by risk tier.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | ||
| limit | No | Max obligations to return (default all, hard cap 25 per call) | |
| fields | No | compact omits provision_text | |
| offset | No | Skip this many obligations (for paging) | |
| risk_tier | No | Filter by risk tier; "all" = no filter. Synonyms accepted. |
| Name | Required | Description |
|---|---|---|
| role | Yes | |
| count | Yes | |
| total | No | |
| source | No | |
| risk_tier | No | |
| obligations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that filtering is optional and does not mention paging behavior or the result shape, which the output schema covers anyway.
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?
A single front-loaded sentence that states verb, resource, required scope, and the optional filter with zero filler.
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?
Output schema and rich annotations carry return values and safety, and the schema documents nearly all parameters. The description is sufficient for correct invocation, missing only explicit sibling routing.
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?
With 80% schema coverage and enum-typed role, fields, and risk_tier, the schema already documents limit, offset, fields, and the risk-tier synonyms. The description adds only the notion that risk_tier is a filter and optional, so baseline 3 is appropriate.
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?
Specific verb (List) plus resource (obligations) scoped to a role under the EU AI Act, with an optional risk-tier filter. This clearly distinguishes it from data-lookup siblings like get_article or get_annex, though it never names an alternative explicitly.
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 phrase 'for a role' and 'optionally filtered by risk tier' imply when to reach for it, but there is no explicit when-to-use guidance, no exclusions, and no routing to assess_compliance or get_article for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full text of one recital of the EU AI Act.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Recital number |
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| number | Yes | |
| permalink | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without description help. The description adds one useful behavioral detail — that it returns the *full text* rather than a snippet or summary — but says nothing about missing/invalid recital numbers or error behavior. With output schema present, return structure needs no explanation.
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?
One sentence, front-loaded with the verb and resource, zero padding. Every word 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 single-parameter, read-only lookup with full schema coverage, annotations, and an output schema, the description covers the essential contract. It could optionally mention what happens for out-of-range recital numbers or that numbering follows the Act's official sequence, but nothing critical is missing.
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% and the single parameter 'number' is already documented as 'Recital number'. The description adds no format, range, or validity constraints beyond what the schema provides, so baseline 3 applies.
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?
States a specific verb (get) and resource (full text of one recital of the EU AI Act), which is enough to separate it from get_article, get_annex, and get_definition by resource type alone. It stops short of explicitly contrasting itself with those siblings, so an agent must infer the distinction from the noun.
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?
No explicit when-to-use or when-not-to-use guidance, and no alternatives named. The intent is implied by the resource name (recital vs article vs annex), which is enough for basic routing but leaves the agent to infer which resource a given query maps to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search over articles, recitals and annexes of the EU AI Act. Returns ranked matches with snippets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 5, hard cap 25) | |
| query | Yes | ||
| scope | No | Defaults to all |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| scope | No | |
| results | Yes | |
| total_matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description usefully adds that results are ranked and include snippets, but says nothing about ranking behavior, snippet length or empty-result handling.
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, zero waste, with the searchable corpus named first and the return shape second. Nothing redundant.
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?
With annotations covering safety, an output schema covering returns, and the description naming the corpus, an agent has nearly everything needed. Only query syntax and choice among sibling retrieval tools remain unspecified.
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 coverage is 67% — limit and scope are documented in the schema, while the required 'query' has no description in either place. The description adds no detail on query syntax (keywords, phrases, boolean operators), so it does not compensate for the gap.
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?
States a specific verb+resource: full-text search over the EU AI Act's articles, recitals and annexes. The scope makes it distinguishable from sibling retrieval tools like get_article and get_recital, though those siblings are not named.
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 term 'full-text search' implies keyword lookup rather than exact-article retrieval, but the description never says when to prefer this over get_article/get_recital or assess_compliance. Usage is only inferable from the resource description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell the maintainer what is wrong, what is missing, or what worked well (a wrong text, a missing amendment, a broken answer, or that this server helped you). One-way: no reply is sent.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | Optional: which tool the feedback is about | |
| client | No | Optional: self-declared client name | |
| message | Yes | What is wrong, missing, or helpful. Max 1,000 characters. | |
| category | Yes | error = something factually wrong; content_gap = correct request for missing material; useful = this server helped - say what worked; other = anything else |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| message | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a genuinely new behavioral fact not present in the annotations: 'One-way: no reply is sent.' That tells the agent not to expect a response loop, which annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false, idempotentHint=false) do not convey. Rate limiting or throttling behavior is not mentioned, keeping it short of a 5.
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 short sentences, zero filler, with the core action and the qualifying content stated first and the one-way caveat second. Every clause 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?
All four parameters are documented in the schema, an output schema exists, and annotations cover the safety profile, so the description only needs to add the directionality and intent — which it does. Only a note on whether submissions are anonymous or how they are acknowledged would push this higher.
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%, including a fully spelled-out enum for 'category', so the schema already carries the semantic load. The description's examples ('a wrong text, a missing amendment, a broken answer') loosely reinforce the category values but add no format, length, or placement guidance beyond the schema's 'Max 1,000 characters'. Baseline 3 applies.
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 names a specific action (tell the maintainer) and enumerates the exact content classes that qualify — wrong text, missing amendment, broken answer, or praise. This is clearly distinguishable from every sibling, which are all read-only regulatory lookup tools (get_article, search_text, etc.).
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?
It concretely lists triggering situations (a wrong text, a missing amendment, a broken answer, or that the server helped), which is strong when-to-use guidance. It does not state when-not to use it, but no competing alternative exists among the siblings, so the gap is minor.
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.
send_feedback3 fields changedInput schema / properties / category / descriptionPrevious value: -"error = something factually wrong; content_gap = correct request for missing material; other"New value: +"error = something factually wrong; content_gap = correct request for missing material; useful = this server helped - say what worked; other = anything else"Input schema / properties / category / enumPrevious value: -[
- "error",
- "content_gap",
- "other"
-]New value: +[
+ "error",
+ "content_gap",
+ "useful",
+ "other"
+]Input schema / properties / message / descriptionPrevious value: -"What is wrong or missing. Max 1,000 characters."New value: +"What is wrong, missing, or helpful. Max 1,000 characters."assess_complianceget_annex1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "number": {
+ "type": "string"
+ },
+ "permalink": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "text",
+ "permalink"
+ ],
+ "type": "object"
+}get_definition1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "permalink": {
+ "type": "string"
+ },
+ "reference": {
+ "type": "string"
+ },
+ "term": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "term",
+ "text",
+ "permalink"
+ ],
+ "type": "object"
+}get_obligations2 fields changedInput schema / properties / risk_tier / descriptionAdded value: +"Filter by risk tier; \"all\" = no filter. Synonyms accepted."Input schema / properties / risk_tier / enumPrevious value: -[
- "unacceptable",
- "high",
- "transparency",
- "minimal"
-]New value: +[
+ "unacceptable",
+ "prohibited",
+ "high",
+ "high-risk",
+ "high_risk",
+ "transparency",
+ "limited",
+ "minimal",
+ "all"
+]get_recital1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "number": {
+ "type": "integer"
+ },
+ "permalink": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "text",
+ "permalink"
+ ],
+ "type": "object"
+}search_text2 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Max results to return (default 5, hard cap 25)",
+ "type": "integer"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "query": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "permalink": {
+ "type": "string"
+ },
+ "snippet": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "snippet",
+ "permalink"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "total_matches": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "query",
+ "total_matches",
+ "results"
+ ],
+ "type": "object"
+}send_feedback1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok"
+ ],
+ "type": "object"
+}get_article1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "effective_date": {
+ "type": "string"
+ },
+ "eurlex": {
+ "type": "string"
+ },
+ "number": {
+ "type": "string"
+ },
+ "permalink": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "title",
+ "text",
+ "permalink"
+ ],
+ "type": "object"
+}get_deadlines1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "as_of": {
+ "type": "string"
+ },
+ "phases": {
+ "items": {
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "in_force": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "date",
+ "in_force"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "as_of",
+ "phases"
+ ],
+ "type": "object"
+}get_obligations4 fields changedInput schema / properties / fieldsAdded value: +{
+ "description": "compact omits provision_text",
+ "enum": [
+ "full",
+ "compact"
+ ],
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "description": "Max obligations to return (default all, hard cap 25 per call)",
+ "type": "integer"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Skip this many obligations (for paging)",
+ "type": "integer"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "obligations": {
+ "items": {
+ "properties": {
+ "actor": {
+ "type": "string"
+ },
+ "applies_from": {
+ "type": "string"
+ },
+ "clause": {
+ "type": "string"
+ },
+ "guidance_note": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "matrix_permalink": {
+ "type": "string"
+ },
+ "official_title": {
+ "type": "string"
+ },
+ "permalink": {
+ "type": "string"
+ },
+ "provision_text": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "clause",
+ "applies_from",
+ "permalink"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "risk_tier": {
+ "type": "string"
+ },
+ "role": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "total": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "role",
+ "count",
+ "obligations"
+ ],
+ "type": "object"
+}send_feedbackget_annexget_articleget_deadlinesget_definitionget_obligationsget_recitalsearch_textEU AI Act and GDPR checks with sources: classify an AI system, trace each duty, find the supervisor.
Verified EU law: verbatim, signed provisions with EUR-Lex links. Read-only, not legal advice.
Read-only EU AI Act tools: Annex III scope, Article 50 check, sourced facts, sha256 verify. Free.
Classify any AI system under the EU AI Act: risk tier + binding Articles, verbatim from the law.
Add one secure layer between your agents and this server.
