eu-ai-act

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

No annotations are provided, so the description carries the full burden and does well: it states the method is deterministic, rule-based keyword screening with no LLM, discloses that output is Danish, lists the returned fields, and adds a 'not legal advice' disclaimer. It still omits permission/auth needs and any accuracy or coverage caveats beyond the disclaimer.

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?

Dense but front-loaded: scope and method come first, output and disclaimer last. The trailing parenthetical English gloss is slightly redundant with the Danish text, but it usefully anchors the tool for non-Danish agents, so it 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?

There is no output schema, yet the description enumerates the return contents (assessment, reasoning, relevant articles, deadlines, source links), which is what the agent needs to interpret results. Combined with the method and language disclosures, the definition is nearly complete for a 3-parameter screening 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% for all three parameters, so the schema already documents each field, its optionality and its length limits. The description adds nothing about parameter formats or how sector/purpose influence the screening, 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?

Names a specific verb (screening) and resource (AI system/use-case) and enumerates the exact scope it covers: Annex III, Art 5, Art 50. It is clearly distinguishable from verify_deliverable and eu_ai_act_facts, though it does not explicitly contrast itself with the overlapping sibling art50_transparency_check.

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 says what is screened but never says when to choose this tool over the alternatives, nor when not to. With art50_transparency_check as a sibling covering one of the same articles, an explicit routing rule is exactly what is missing here.

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

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

With no annotations the description carries the full burden, and it delivers strong behavioural context: deterministic, no LLM, plus exactly what the output contains (konkrete krav, frister, tjekliste, kildelinks). It stops short of stating side effects or permission needs, but that is minor for a stateless checker.

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 front-loaded sentences with the scope first, then output, then the deterministic/no-LLM caveat. Dense but every clause earns its place; the parenthetical language note is a small tail that could be trimmed.

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?

No output schema exists, so the description correctly summarises the return (requirements, deadlines with specific dates, checklist, source links) and flags that output is Danish. Inputs are fully covered by the schema. Only the exact output format (structured vs prose) remains 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 description coverage is 100%, so all four parameters are already documented in Danish, and the description merely mirrors the same category list. Baseline 3 applies since the schema does the heavy lifting and the description adds no extra syntax or semantics.

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 precise verb+resource: a check of which EU AI Act Article 50 transparency requirements apply, and enumerates the four covered surfaces (chatbot/AI-assistent, AI-genereret indhold, deepfake-risiko, emotion/biometri). The Article 50 scoping makes it clearly distinguishable from ai_act_scope_check and eu_ai_act_facts even without naming them.

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 by the listed input surfaces (if you have a chatbot, run this), but there is no explicit when-to-use statement, no when-not, and no routing to sibling tools such as ai_act_scope_check for broader scope questions. Adequate but leaves the agent to infer selection.

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

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

With no annotations, the description carries the full behavioral burden; it usefully discloses that only status=verified rows are returned and that each row carries a source URL and verification date. It says nothing about authentication, rate limits, pagination, or empty-result behavior, so a mutation-free read tool's operational profile is only partially covered.

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 core purpose is front-loaded in the first clause, followed by the verified-rows guarantee and then input examples, so an agent gets the essentials immediately. The bilingual repetition (full Danish text plus an English parenthetical) is mildly redundant but earns its place for cross-language comprehension.

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 no output schema, the description covers what it retrieves, the data-quality filter (verified only), and the key returned fields (source URL, verification date). It does not explain result volume or pagination, but nothing essential for calling 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 baseline is 3, but the description goes beyond the schema's generic 'Emne eller nøgleord at søge efter' by supplying realistic example queries that demonstrate the expected granularity and format (article references, act nicknames, annex references). That added interpretation of the single parameter justifies a step above baseline.

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 gives a specific verb (look up) and a clearly scoped resource (verified EU AI Act/NIS2/Digital Omnibus facts in PowerQuant's sourced fact base), which an agent can readily distinguish from sibling checks such as ai_act_scope_check and art50_transparency_check. It stops short of naming those siblings explicitly, so the differentiation is implicit rather than stated.

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 through concrete input examples ('art 50', 'omnibus', 'annex iii', 'nis2') and the constraint that only status=verified rows are returned, which tells the agent what this tool is for. There is no explicit when-not-to-use or routing guidance versus the sibling verification/check tools, so the agent must infer the boundary.

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

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

With no annotations, the description carries the full burden and does well: it declares the operation read-only, asserts no personal data is involved, and defines the not-found behavior (found:false for unknown hashes). This is meaningful behavioral context beyond the schema, though auth requirements, rate limits, and latency are unstated.

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 English sentence is front-loaded with the action and then the input, which is good structure. However, the appended Danish parenthetical is a verbatim translation that adds no new information for an agent reading the English text, so not 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?

There is no output schema, yet the description enumerates the returned fields (signature, issue date, reviewer, regulatory-change flag, found:false), so an agent knows what to expect. For a single-parameter verification tool this is nearly complete, with only provenance/error specifics left implicit.

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% for the single parameter, so the schema already documents the 64-hex sha256 and its source. The description largely restates that (footer or link), so it adds little beyond the schema — the baseline 3 for full schema coverage 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 (verify) and resource (a PowerQuant deliverable), and enumerates exactly what is checked: signature, issue date, reviewer, and regulatory-change impact. The subject domain (PowerQuant deliverables, powerquant.dk) clearly distinguishes it from the ai_act/art50 sibling tools.

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 tells the agent precisely what input is needed and where to obtain it (the 64-hex sha256 in the document footer or the /verify/<sha> link), which effectively defines the trigger condition. It does not state when not to use it or name an alternative, but no sibling performs verification, 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.