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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate safety. It adds valuable context about the non-binding nature of sub_items and the legal simplification pathway for SMEs, which goes beyond the annotations. No contradiction with annotations.

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 a single, focused paragraph that front-loads the core purpose and then adds important legal context. It is concise and every sentence adds value, though it could be slightly more structured with explicit headings or bullet points for the nine titles.

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 the tool's moderate complexity (2 optional params, output schema present, read-only annotations), the description covers the essential purpose, legal caveats, and simplification pathway. It doesn't detail the nine titles themselves, but that's likely the tool's output, and the output schema exists. The description is complete enough for an agent to select and invoke it correctly.

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 both parameters (format and sme_simplified) with descriptions. The tool description adds no additional parameter semantics beyond what the schema provides, but the schema is sufficient, 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?

The description clearly states the tool provides the nine titles and descriptions summarising Annex IV, with sub_items as non-binding implementation prompts. It distinguishes itself from siblings by focusing specifically on the Annex IV technical documentation checklist, which is a distinct resource from classification, deadlines, obligations, 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?

The description explains the nature of the content (non-binding prompts) and clarifies the legal context regarding SMEs and SMCs under Article 11(1). It implies when to use this tool (when needing Annex IV documentation guidance) but does not explicitly contrast with alternatives like euaiact_get_article or euaiact_get_obligations, though the specificity of Annex IV makes the use case clear.

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 declare readOnly and idempotent, so the bar is lower. The description adds context by claiming 'best-match answers' and 'article references,' which implies ranking behavior and output structure, beyond annotations.

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 a single, informative sentence that covers function, scope, and output references without excess. Front-loaded with action and resource.

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 simple schema and annotations, the description covers the purpose, scope, and output (references). It could mention limitations or fallback behavior, but it's sufficiently complete for a Q&A 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?

The schema has one parameter with a clear description ('User question about the EU AI Act'). The tool description adds no additional parameter context, but since the schema coverage is 100%, a 3 is acceptable.

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 clearly states the tool's purpose: 'Search frequently asked questions about the EU AI Act and get best-match answers with article references.' It uses a specific verb (search) and resource (FAQ) and differentiates from siblings like get_article by focusing on question-answer style.

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 implicitly indicates when to use this tool (for general FAQ-style questions) by enumerating covered topics, but it does not explicitly contrast it with alternatives like checking specific articles or deadlines. The 'Covers...' list provides usage context but lacks explicit when-not guidance.

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?

The description is transparent about being an assessment/walk-through tool, and does not contradict the read-only annotation. It clearly states that profiling disables the exception, which is a critical behavioral aspect. No conflicts with annotations are present.

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 verbose and largely redundant with the schema, repeating all conditions and legal references. While it is structured, it could be condensed significantly without losing essential information, making it less concise than ideal.

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 description provides important legal context (Art. 6(3), 6(4), 49(2)) and states the documentation and registration requirements. However, it does not explain the tool's output structure or return values, leaving some contextual gaps for a complex assessment 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?

Since the schema provides 100% coverage with detailed per-parameter descriptions, the baseline is 3. The description adds minimal extra nuance, such as the condition for setting 'no_significant_risk', but largely repeats the schema, so it does not elevate the score.

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 clearly states the tool's function: walking through the Art. 6(3) exception for Annex III high-risk AI systems. It specifies the legal basis and the key conditions, making the purpose unambiguous.

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 for assessing whether an Annex III system qualifies for the exception, and mentions documentation requirements. However, it lacks explicit guidance on when to choose this tool over siblings like euaiact_assess_system, and does not provide clear when-not-to-use scenarios.

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?

Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint=false), the description adds meaningful behavior: 'Sparse inputs fail closed' and 'Impact never changes legal classification, and classification never implies implementation readiness.' It also describes output composition and provenance, matching the read-only assessment nature without contradicting annotations.

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?

Three dense sentences, each earning its place: what the tool does, what it returns, and key behavioral caveats. Key points are front-loaded, with no filler or repetition of schema details.

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 complex tool with 15 parameters and nested objects, the description covers the core purpose, output structure, fail-closed behavior, and logical independence of results. The presence of a rich input schema and output schema lowers the burden, though it doesn't mention how to construct the profile or the required profile_version.

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 0% and the description does not explain individual parameters like profile_version, identity, gpai, or annex_iii. The phrase 'one normalized EU AI Act system profile' gives only a general sense of the top-level object; with 15 nested parameters this is insufficient compensation for missing schema descriptions.

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 'Assess' with a clear resource: 'one normalized EU AI Act system profile against the pinned sealed corpus.' It distinguishes from siblings by promising 'separate legal-classification, impact, and implementation-readiness blocks,' which differentiates it from euaiact_classify_system and other narrower assess_* 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 context is clear: use this when you have a normalized profile and want a broad assessment with classification, impact, and readiness in one call. However, it never names sibling alternatives or provides explicit when-not-to-use guidance, so it doesn't reach the highest standard.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral detail: input to Art. 99 penalty framework, the SME lower-of rule, the narrower SMC rule, the exclusion of SMC caps for Art. 5 fines, and the comparative-return block. It also does not contradict the annotations.

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 a complete one-sentence summary, followed by a dense but useful legal-behavior sentence and one return-value sentence. There is no filler, repetition, or unnecessary detail.

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 legal-calculation tool with four parameters, the description covers the calculation inputs, the exact provisions implemented, the important exceptions, and the output purpose. It is sufficiently complete for an agent to select and invoke the tool correctly, especially given the rich schema and output-schema context.

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?

Input schema already covers 100% of parameters with solid descriptions and an enum, so the baseline is 3. The tool description adds value by explaining how these parameters combine under specific legal provisions, especially SME/SMC treatment and the returned comparative result, above the schema-level definitions.

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 first sentence states a specific action and resource: 'Calculates the maximum possible fine for an EU AI Act violation' and names the exact inputs. This clearly distinguishes the tool from sibling tools about classification, deadlines, obligations, and article lookup.

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 makes the intended use-case obvious: penalty calculation for EU AI Act violations using turnover and SME/SMC status. It does not contain explicit 'when not to use' wording or name alternatives, but none of the sibling tools compete for the same job, so the context is clear.

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 readOnly=true, idempotent=true, and openWorld=false, giving the agent safety confidence. The description goes further by disclosing versioning behavior ('always reflects the operative law'), the source-status labeling of the omnibus pack, and the crucial legal caution that 'non-enacted content must not be treated as current law.' This is exactly the kind of consequential behavior (legislative state accuracy) an agent needs disclosed.

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 filler, front-loaded with the core purpose. The second sentence is dense, but the density reflects the legal nuance being communicated. Code-formatted parameters and a well-placed 'important' caution after the parameter description make it scannable. The density is justified by the high-stakes legal context.

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 compliance-relevant legal tool, the description covers versioning ('operative law'), pending-legislation safety, and parameter default behavior, even addressing how an output schema exists. Minor gaps like timezone for 'days remaining' or error behavior are not material enough to detract from what is otherwise a complete picture.

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 100% schema coverage, baseline is 3. The description adds value by clarifying the default behavior ('OFF by default: the milestone timeline always reflects the operative law only') and connecting the `include_pending_omnibus` output to its `status` and `enacted` fields, which helps the agent reason about conditional response validation.

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 'Returns key implementation milestones and deadlines for the EU AI Act with days remaining, a `next_milestone` shortcut, and a summary of the Digital Omnibus' — a specific verb+resource+scope statement that clearly distinguishes it from siblings like euaiact_get_obligations or euaiact_calculate_penalty. The mention of the `next_milestone` shortcut and the Digital Omnibus summary adds distinctive detail beyond a generic 'check deadlines' description.

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 when to use the tool — for operative-law-accurate milestone lookups — but never explicitly names alternatives or states when NOT to use it. The phrase 'The milestone timeline always reflects the operative law' gives clear context for trust boundaries, but there's no cross-reference to siblings like 'use get_obligations for obligations' or 'use answer_question for interpretive questions.'

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 provide readOnlyHint: true and idempotentHint: true. The description adds critical behavioral context: the specific 10^25 FLOPs threshold ('adjudicated conservative boundary'), that it 'returns' specific obligations (Art. 53, 55, 52 notification duty), and that it can abstain when training_flops is omitted. This meaningfully enriches the safety profile beyond what annotations declare.

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?

Three sentences, well-structured, front-loads the core purpose in sentence one, then details the threshold and return values. No filler. Loses a point for the potential 10^25 vs 1e25 notational discrepancy that could cost a reader a second to reconcile.

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 the output schema exists, the description need not list return types. For a legal determination tool with three optional params, it covers the test logic, edge case (abstain on unknown), and obligations scoping well. The slight ambiguity around what happens with conflicting inputs (e.g., high FLOPs but commission_designated: false) keeps it from a 5.

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% with rich parameter descriptions already documenting the default abstain behavior on training_flops and the commission_designated flag semantics. The description adds the overall threshold (10^25) that complements but doesn't conflict with the schema's 1e25 mention—actually introducing a slight inconsistency: description says 'at or above 10^25' while schema says 'at or above 1e25' (which are the same, but described with different significant figures, potentially confusing). Moderate value added beyond schema, which is already strong.

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 ('Determine') and names the exact resource (general-purpose AI model systemic risk classification under Art. 51). It clearly distinguishes from siblings like euaiact_assess_system (which assesses broader system risk) and names the specific Art. 52/53/55 obligations returned, making its scope unmistakable.

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 when to use this tool versus alternatives by specificity ('GPAI model with systemic risk under Art. 51') and names the sibling alternative implicitly through distinct scope (e.g., it's not about penalties or deadlines). It lacks explicit 'use instead of X' language but provides clear context for models versus systems, distinguishing it from euaiact_assess_system and euaiact_classify_system without naming them.

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?

Beyond the readOnly and idempotent annotations, the description discloses deterministic signal precedence, the output contents, and a hard limitation: Art. 6(3) exceptions cannot be auto-applied. There is no contradiction with the annotations.

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 compact and front-loaded, with each sentence serving a purpose: purpose, inputs, precedence, outputs, and exception handling. It avoids repeating annotation or schema details.

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 complex legal classifier with many signal fields and an output schema, this description is remarkably complete. It covers input modes, deterministic behavior, key outputs, and a procedural limitation, while the existing output schema covers the detailed return structure.

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?

The description adds meaning by explaining the relationship and precedence between free-text/use_case inputs and structured signals. However, with only 50% schema coverage, it does not fully describe every parameter such as role, though the schema's detailed nested property descriptions partially compensate.

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 specific verb and resource: 'Classify an AI system's risk level under the EU AI Act,' including the regulation number. It also enumerates concrete outputs and points to a sibling tool for Art. 6(3) exceptions, clearly differentiating its classification scope.

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 acceptable input combinations (free-text, use_case, structured signals) and gives a clear precedence rule for signals over text. It explicitly names a when-not-to-use case (Art. 6(3) exceptions) and directs the agent to euaiact_assess_art6_3_exception.

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?

Beyond the readOnlyHint/idempotentHint annotations, the description reveals critical behavioral details: only a subset of articles is supported, unsupported articles return the EUR-Lex base URL, and the summary is not statutory text requiring verification via the official link. This is exactly the kind of non-obvious context an agent needs to avoid hallucinating that an article was retrieved when it was not.

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?

Three sentences of dense, non-redundant prose. The most important information (what it retrieves) comes first, followed by scope caveats and a legal disclaimer. Every sentence earns its place—no filler or repetition of the schema.

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 read-only lookup tool with an output schema, this description is complete: it covers the return value (summary + URL), scope limits (article subset), failure mode (base URL fallback), and a caution about non-statutory text. Given the presence of a well-defined output schema and annotations, no additional documentation of return values or safety profile is needed.

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% with a well-specified format (case-insensitive, optional 'Art.' prefix). The description adds complementary value by explicitly enumerating the supported article ranges (Art. 3, 4, 5, 6, 9-17, etc.) and the fallback behavior, which directly informs parameter usage without duplicating the schema's format notes.

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+resource structure ('Retrieve an operational summary of a specific article of the EU AI Act (Regulation 2024/1689), plus a stable EUR-Lex URL') that precisely scopes the tool's function. It clearly distinguishes itself from siblings like euaiact_check_deadlines or euaiact_calculate_penalty by focusing on article retrieval, making the domain boundary obvious.

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 context for when to use this tool (retrieving article summaries from a known subset) is clearly implied through the supported-articles list and fallback behavior. However, there is no explicit when-not-to-use guidance, exclusions, or named alternatives from the sibling tools, which would have elevated this dimension.

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=true and idempotentHint=true. The description adds that it returns obligations but does not elaborate on any non-obvious behaviors or constraints beyond what annotations and schema provide.

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 a single sentence with no wasted words. It is front-loaded with the action and resource.

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 the output schema exists, parameter count is manageable, and annotations cover safety, the description is sufficient. It does not need to explain return values or additional context.

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 fully documents each parameter. The tool description adds no new parameter meaning beyond stating that obligations are returned based on role and risk level.

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 clearly states the verb 'returns' and resource 'compliance obligations', and specifies the key parameters (role and risk level). It distinguishes from siblings like euaiact_classify_system and euaiact_get_article.

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 naming the parameters but does not explicitly state when to use this tool vs alternatives, nor when not to use it.

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