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 adds real value beyond that: it is deterministic with no language model, returns findings carrying severity, span, expected/found values and sources, and explicitly disclaims certification of compliance. It does not mention rate limits or text-size limits, but it is a batch read with nothing destructive to disclose.

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 operation and scope are front-loaded in the first clause, followed by the output shape and the legal caveat. The prose is dense and every clause carries information, though the long parenthetical enumerations make single sentences heavier than necessary.

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 no output schema, the description carries the return-value burden and does so: it names the finding fields (severity, span, expected, found, sources). Combined with the deterministic/no-LLM note, the disclaimer, and the parameter semantics already in the schema, an agent has everything needed to call and interpret it.

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. The description still adds meaning by explaining that as_of selects the version of the Act in force and that the text may be any length, framing what the checker actually inspects. It adds marginal rather than decisive detail over the schema, so it sits just 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?

States a specific verb and resource (checks a text against the AI Act) and enumerates the three concrete check classes: outdated application dates, citations to removed/nonexistent provisions, and altered quotations. It is clear enough to separate from siblings by scope (whole document vs. a single citation), but it never names a sibling such as aiact_verify_citation to make the boundary 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?

The description implies usage by listing accepted inputs (policy, provider answer, slides, AI-generated answer) and adds a clear caveat that results are orientation only and never certify compliance. However, it gives no explicit when-to-use or when-to-prefer-an-alternative guidance relative to aiact_verify_citation or aiact_obligations, leaving routing to inference.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds genuinely useful behavior detail the annotations cannot: the exact baseline and target versions being compared, the role of the Omnibus amending act, and that changes are reported as a word-level diff.

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 dense sentence with the compared-version identifiers front-loaded and the result taxonomy trailing after the colon. Every clause carries information, though the parenthetical version identifiers make it heavier than strictly necessary.

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 no output schema, the description usefully names the possible return categories and flags the word-diff modality. It does not describe the shape of the diff payload or how 'moved' is represented, but for a read-only two-parameter tool this is largely sufficient.

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 'id' (node id or citation) and the en/de 'lang' enum are already documented in the schema. The description adds no syntax, format, or defaulting detail beyond what the schema provides, 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?

The description states a specific verb (diff/what happened), a specific resource (a provision), and pins the two compared versions by their exact identifiers (32024R1689 vs 02024R1689-20260727) plus the amending act. It also enumerates the outcome space (unchanged, changed with word diff, added, removed, moved), which cleanly separates it from aiact_get_provision.

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 comparison intent strongly implies when to use it (to see version-to-version changes rather than fetch content), but there is no explicit when-to-use/when-not statement and no sibling is named as an alternative. The guidance is inferable rather than stated.

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?

Annotations already declare a safe read-only, idempotent profile, and the description adds genuinely new behavior: the version-selection rule tied to as_of, the recitals-only-in-OJ limitation and the found=false fallback, plus an applicability flag derived from the deadline table. This is well beyond what the annotations and schema convey.

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?

Front-loads the core purpose in the first clause and keeps every subsequent sentence informational, with no filler. It is a dense, semicolon-chained paragraph though, and the parameter mechanics could be split from the return-value notes for easier scanning.

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 no output schema, the description carries the return-value burden and does so: the applicability field, the neighbouring-provisions list (including amendment-inserted items like paragraph 6a), and the found=false case. An agent knows both what it gets back and how to interpret it.

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%, so the baseline is 3, but the description goes further by explaining the interaction between as_of and version (explicit version wins over as_of), the date that flips the default corpus, and the consequence of requesting a recital under the consolidated version. It adds real semantics on top of the schema text it partially echoes.

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 and resource: returns exactly one provision by id or citation, with all descendants, and gives concrete id/citation examples. The singular, identifier-driven retrieval is naturally distinct from aiact_search, but no sibling is named, so the 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?

Offers useful in-tool guidance (when to pass version vs as_of, precedence rules, and the warning to inspect neighbouring provisions before concluding nothing more exists), but never says when to reach for this tool instead of aiact_search, aiact_verify_citation, or aiact_diff. Usage relative to alternatives must be inferred.

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?

Annotations already cover read-only/idempotent safety, and the description adds substantial non-obvious behavior: deterministic with 'no language model,' coverage of the consolidated text from 2026-07-27, dates derived from Article 113 plus the Annex I/III classification route, the applies_from_literal caveat when the literal rule diverges, and an explicit boundary that it flags but does not perform legal assessments.

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 definition is front-loaded with the core behavior in sentence one, and each subsequent sentence earns its place (classification route, caveat handling, coverage date, determinism, legal boundary). It is dense with legal/technical terms but appropriately sized with no 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?

Given a 4-parameter tool with a deeply nested profile object and no output schema, the description helpfully enumerates what the response carries (citation, verbatim quotation, application date on as_of, legal-assessment notes) and the conditional applies_from_literal field. It stops short of describing response structure or error/edge behavior in detail, but is largely complete 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%, so the parameters and every nested profile field are already documented in the schema, establishing the baseline of 3. The description adds only light framing ('application date on as_of', the classification route affecting dates) and does not deepen the enumerated profile flags.

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 opens with a precise verb+resource+input: 'For a company profile, returns the applicable and upcoming obligations of the AI Act with citation, verbatim quotation, application date.' This is clearly distinguishable from siblings like aiact_get_provision or aiact_search, which do not take a company profile and map it to obligations.

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?

'For a company profile' implies the usage context, but the description never states when to prefer this over siblings such as aiact_get_provision or aiact_search, nor any when-not conditions. The 'Orientation only, not legal advice' line is a scope disclaimer rather than routing guidance, leaving alternatives to inference.

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?

Annotations already declare readOnlyHint/idempotentHint, so the safety profile is covered. The description adds genuinely non-obvious behavior: the searched corpus switches at 2026-07-27 (32024R1689 with recitals vs consolidated 02024R1689-20260727), and per-result applicability is derived from the deadline table. It does not mention pagination or ranking caveats, which keeps it below 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?

Front-loaded with the core operation and result shape, then the version-selection rule, then the negative scoping clause. Dense but every clause is load-bearing; slightly long as a single paragraph where the version-switch detail could be tighter.

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 no output schema, the description still enumerates the returned fields (citation, heading, snippet, score, applicability) and explains the version-dependent corpus, so an agent knows both what it gets back and why results vary by as_of. Nothing needed 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 coverage is 100%, so the baseline is 3, and the description goes further by explaining that as_of selects the version searched and that results carry applicability on that date – semantics not conveyed by the pattern description alone. query and limit semantics are left to the schema.

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 and resource ('Full-text search (BM25) over the AI Act') plus the exact return contents, and explicitly contrasts itself with interpretation/obligation tools ('Finds provisions by wording; it does not interpret them or say which one applies to a system'). An agent can distinguish this from aiact_obligations and aiact_get_provision without opening any 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?

Gives a clear usage boundary: use it to find provisions by wording, not to interpret them or determine applicability to a system. It stops short of naming the alternative sibling tool (e.g. aiact_obligations) that should be used instead for interpretation, so the routing is implied rather than explicit.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the semantic limit disclosure: support_checked is always false and compliance is never certified. That is genuinely useful guardrail context a caller must not assume, though auth, rate limits, and the exact result shape remain undisclosed.

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 dense sentences, front-loaded with the core action, and the negative guarantees are packed into a single clause with no filler. Every clause carries 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?

With no output schema, the description is responsible for return context, and it partially delivers by naming the V0/V1/V2 check layers and one always-false response field (support_checked). It still leaves the overall response structure (found/applicable results, per-layer outcomes) to inference, which is the main remaining gap for a verification 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 coverage is 100%, so the baseline is 3, but the description maps the parameters to check tiers — as_of drives applicability (V1), lang drives the language check (V2), and the pinpoint (claimed_ref) participation in the V0 text match. That mapping is interpretive value the schema alone does not provide.

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 verb and resource ('Checks that a quotation exists in the AI Act text') and decomposes it into three precise sub-checks (verbatim presence with pinpoint, applicability at a reference date, language). This is clearly distinguishable from retrieval/search/diff siblings, which do not verify quotations.

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 states what the tool does NOT do ('never checks that the text supports a claim... never certifies compliance'), which is meaningful when-not guidance for a verification tool. It does not, however, point to a sibling for the adjacent task (finding a quote via aiact_search) or give a positive 'use this when' trigger.

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