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?

Adds substantial behavioral context beyond the readOnly/idempotent/openWorld annotations: 'Sparse inputs fail closed', 'Impact never changes legal classification', and 'classification never implies implementation readiness'. It also discloses how missing facts are returned ('missing_facts with the question to ask') and that output includes provenance, warnings, and recommended follow-up calls. 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 long but well-structured: purpose and outputs first, then behavioral traits, then a clearly marked profile-building section. Every sentence carries useful information, and the length is justified by the 0% schema coverage, though the minimum-profile list is dense and could be slightly tightened.

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, nested objects, and no schema descriptions, the description covers the essential workflow: what the tool returns, fail-closed behavior, minimum required facts, and how missing facts surface. An output schema exists, so return-value details need not be spelled out. Some advanced optional sections are unaddressed, but the 'supply only facts you were given' guidance mitigates that gap.

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%, so the description carries the full burden. It compensates well by defining the fact-object shape (fact_id, value, origin, verification, evidence_reference_ids), prescribing origin/verification values, listing a useful minimum profile, and giving guidance on annex_iii usage. However, several top-level sections (e.g., article_5_prohibitions, controls_and_evidence) receive no parameter-level explanation, so coverage is not exhaustive.

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 ('Assess one normalized EU AI Act system profile against the pinned sealed corpus') and enumerates the three output blocks (legal-classification, impact, implementation-readiness). The scope is clear, but it never explicitly names or contrasts sibling tools like euaiact_classify_system, so differentiation is only implicit.

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 'HOW TO BUILD THE PROFILE' section gives detailed input-construction guidance, which is useful for invoking this tool, but there is no explicit statement of when to choose this tool over siblings, nor any 'use classify_system instead when...' exclusion. Usage context is implied 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?

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?

Annotations already indicate readOnlyHint and idempotentHint, and the description adds important behavioral context beyond those: classification is deterministic on signals, free text alone often returns insufficient_information, missing decisive signals are returned as missing_signals with questions to relay, and Art. 6(3) exceptions cannot be auto-applied. This gives the agent an accurate model of how the tool behaves.

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 dense but every sentence earns its place: purpose, calling convention, signal-setting rules, failure behavior, return contents, and an exception routing note. The critical HOW TO CALL guidance is front-loaded, and no filler or redundant restatement is present.

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 complex nested signals schema, the annotations, and the presence of an output schema, the description is complete enough for an agent to call the tool correctly. It covers the workflow, the main error case (insufficient_information), what to do about missing signals, and what the response contains, while the schema covers the individual parameter 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?

With schema description coverage at 50%, the description compensates strongly. It explains how to construct the central signals object, warns against guessing, clarifies that signals.domain must not be inferred from sector, and directs the agent to read the field description. It also explains the role of description as insufficient on its own, which is not obvious from the schema alone.

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: classify an AI system's risk level under the EU AI Act (Regulation 2024/1689). It also clarifies the deterministic signal-based behavior and the exact outputs returned, making it clear what this tool does and distinguishing it from a generic assessment tool.

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 explicit how-to-call instructions: derive structured signals from the user's description, pass them with description, set signals only when supported, never guess, and ask follow-up questions before calling again. It also names a specific sibling (euaiact_assess_art6_3_exception) for the Art. 6(3) case, which is a clear alternative-selection rule.

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 and idempotentHint, and the description does not contradict these. However, the description adds little behavioral detail beyond what annotations provide—it doesn't mention pagination, filtering nuances, or conditional parameter behaviors. The bar is lower with annotations, so a 3 is appropriate.

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, well-structured sentence that front-loads the core purpose. It contains no filler or redundant information, making it highly concise and easy to parse.

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 an output schema and rich input schema, the description covers the essential context. It could mention conditional parameter relationships (e.g., high_risk_source relevant only for high-risk), but the schema handles those details. Overall, the description is adequate for agent 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?

The input schema provides 100% coverage with descriptions for all 6 parameters, including complex ones like gpai_model_placed_on_market_before_2025_08_02. The tool description adds no extra parameter semantics beyond the schema, so baseline 3 is warranted.

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'), the resource ('specific compliance obligations'), and the scope ('for providers or deployers based on AI system risk level'). It distinguishes this tool from siblings like euaiact_classify_system and euaiact_get_article by focusing on obligations retrieval rather than classification or raw article 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?

The description provides clear context on when to use the tool: when you need obligations for a given role and risk level. It does not explicitly mention alternatives or exclusions, but the input criteria are defined, giving the agent clear guidance on matching user intent to this tool.

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