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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description adds real value beyond them: it discloses that sub_items are non-binding implementation prompts, are not verbatim Annex IV text, and create no additional legal requirements. That is exactly the kind of content caveat an agent needs to avoid overstating legal authority, though it says nothing about output size or formatting behavior.

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, no fluff, but the structure is inverted for a tool definition: it opens with a caveat about output contents rather than stating what the tool does or returns. Every sentence earns its place on legal accuracy, yet the most important information for selection (the core action) is absent, so front-loading is poor.

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 present, return values need not be described, and both parameters are fully documented in the schema, so nothing an agent needs to invoke it is missing. However, the description never states the core action or when to prefer it over sibling tools, leaving the selection decision weaker than it should be for a nine-sibling tool family.

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 adds legal meaning to sme_simplified by grounding it in Article 11(1) second subparagraph and the requirement to use the Commission form — context the schema's one-line description does not carry. The 'json' vs 'checklist' format parameter gets no added commentary, keeping it 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?

The description implies this returns the Annex IV checklist by referencing 'the nine titles and descriptions' and 'sub_items', but it never states a verb+resource action such as 'returns the Annex IV technical documentation checklist'. It also gives no differentiation from siblings like euaiact_get_article or euaiact_get_obligations, which an agent could plausibly confuse it with for the same legal content.

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?

There is no when-to-use guidance: nothing says to call this when preparing technical documentation under Article 11 or when auditing Annex IV coverage. The Article 11(1) SME sentence is a legal caveat about the domain, not a usage condition selecting this tool over an alternative.

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, idempotentHint=true and openWorldHint=false, so safety and determinism are covered. The description adds that responses are best-match with article references, which is mild but useful output-shaped context. It doesn't disclose matching behavior, ranking, or what happens with unmatched questions.

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, with the core action front-loaded before the topic list. The coverage enumeration is long but earns its place by signalling routing scope. Slightly list-heavy but no wasted framing.

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 present, the description need not explain return values, and it correctly restricts itself to scope. Topic coverage plus the FAQ-vs-article distinction is enough for an agent to call it correctly; only explicit sibling routing 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?

There is a single parameter with 100% schema description coverage ('User question about the EU AI Act'), so the schema carries the semantics. The description adds nothing about phrasing, length, or language of the question. Baseline 3 is appropriate when the schema fully documents the lone parameter.

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 ('Search frequently asked questions about the EU AI Act') plus the return shape ('best-match answers with article references'). The FAQ-search scope cleanly separates it from siblings like euaiact_get_article or euaiact_assess_system, which retrieve article text or run assessments rather than answering questions.

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 topic enumeration (classification, deadlines, documentation, penalties, GPAI, FRIA, etc.) implicitly tells the agent when this tool applies, but no explicit when-to-use rule or alternative is named. It does not say, e.g., to prefer this over get_article for quick answers. Usage is implied rather than directed.

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 establish readOnly, idempotent, non-open-world behaviour, and the description adds real substance beyond them: the hard profiling exclusion, the documentation duty, and the registration duty that survive a successful exception. It stops short of describing how the assessment is returned, but the output schema carries that.

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: the walkthrough, the four conditions, the CRITICAL exclusion, and the collateral duties appear in logical order with no filler sentences. Length is justified by regulatory complexity.

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?

Covers the exception's logic, its disqualifier, and the provider's follow-on duties, which is what an agent needs for a read-only assessment tool with a rich output schema. The only gap is the absence of guidance on prerequisite or alternative sibling tools.

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 when to set no_significant_risk_to_health_safety_fundamental_rights=true and by flagging performs_profiling as an overriding gate. That is meaningful semantic guidance beyond the schema text.

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 (assess) tied to a precise regulatory provision (Art. 6(3) exception) and enumerates the four conditions (a)-(d), so the scope is unambiguous. It is distinguishable by article number from most siblings, though it never explicitly contrasts itself with close neighbours like euaiact_classify_system or euaiact_assess_system.

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?

Provides clear conditions for invoking the exception and an explicit disqualifier (profiling under the third subparagraph), plus downstream obligations (Art. 6(4) documentation, Art. 49(2) registration). It does not state when to reach for this tool versus the classification/assessment siblings, so routing is left 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 readOnly/idempotent/closed-world, and the description layers on real behavioral disclosure: what each returned block contains (field-level facts, decisive missing facts, finding provenance, warnings, recommended follow-up calls), the fail-closed behavior on sparse inputs, and the invariant that impact never changes classification. This is context an agent cannot get from the structured fields.

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?

Long but front-loaded: purpose and return-shape first, then the invariant sentences, then a clearly delimited HOW TO BUILD THE PROFILE block. Nearly every sentence carries information, though the profile-construction paragraph is dense enough that it could be tightened without loss.

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 an output schema exists, the description need not explain return values, and it still characterizes the returned blocks and their invariants. For a 15-parameter, deeply nested, closed-world assessment tool, an agent has enough to build a valid profile and interpret a fail-closed result.

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 must carry the load, and it does: it fully specifies the fact object shape {fact_id, value, origin, verification, evidence_reference_ids}, the origin/verification values for caller-stated facts, and a concrete minimum fact set. It does not document every top-level section (annex_i, gpai, transparency, controls_and_evidence), so it falls short of complete compensation.

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 a pinned sealed corpus, and enumerates what it returns (legal-classification, impact, implementation-readiness blocks). It carves out its own niche versus euaiact_classify_system by insisting classification never implies readiness, but it never names the sibling tool or explicitly routes to it.

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?

Rich operational guidance: when to set annex_iii.domain/point ('only when the system itself performs a use Annex III lists... never because it operates in that sector'), 'supply only facts you were given', and the fail-closed behavior. It lacks explicit when-to-use-this-vs-sibling routing, but the input-construction rules are unusually actionable.

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 only cover the safety profile (readOnly, idempotent, not openWorld). The description adds substantial domain behavior: which articles govern which tiers, that SMC relief applies only to 99(4)-(5) and not to Art. 5 or Art. 101, and that output includes a comparative block. This is well beyond what the annotations 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?

Three sentences, front-loaded with the core action before the legal detail. Dense EU-legalese, but every clause maps to behavior the agent needs; nothing is redundant 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What remains — the governing legal tiers, the SME/SMC lower-of logic, and the comparative output — is all supplied, so nothing an agent needs to call this 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 per-field meaning is already documented, making 3 the baseline. The description nevertheless adds semantic value by explaining how the parameters interact — that SME status spans tiers 3-5 while SMC status is narrower — which clarifies the rule engine behind the enum and booleans.

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 ('Calculates the maximum possible fine for an EU AI Act violation') and enumerates the inputs it depends on (violation type, turnover, SME/SMC status). No sibling tool performs penalty calculation, so it is trivially distinguished from the classify/obligations/deadlines 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?

Usage is clear from the statement that it implements the Art. 99 framework and returns a comparative block for showing the SME reduction. There are no competing siblings for penalty math, but the description never explicitly states when to reach for this tool versus answering via euaiact_answer_question or euaiact_get_article.

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, and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: the milestone timeline 'always reflects the operative law', and the omnibus pack items are source-status labelled with `status`/`enacted` carrying legislative state. It does not discuss pagination or result volume, but read-only status is well established.

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 return payload in the first sentence, then behavior and option semantics. Four sentences, each carrying information, though the omnibus caveat is repeated in the schema and could be tighter. 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?

With an output schema present, the description needn't explain return values, and annotations cover the safety profile; the remaining burden (operative-law semantics, pending omnibus labelling, option effects) is addressed. Only the `area` filter's behavior is left entirely to the schema, a minor gap for a fully documented read 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%, so the schema already documents area, only_upcoming, and include_pending_omnibus, and the schema's own include_pending_omnibus text already states the operative-law default. The description largely restates this, adding marginal semantics, so the baseline of 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 states a precise verb and resource ('Returns key implementation milestones and deadlines for the EU AI Act') and enumerates the payload contents (days remaining, `next_milestone`, Digital Omnibus summary). This clearly distinguishes it from siblings like euaiact_get_obligations or euaiact_calculate_penalty, which serve different intents.

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 gives clear conditional guidance for the options ('Set `include_pending_omnibus: true` to also receive...', 'Use `only_upcoming: true` to drop past milestones'), which is effectively when-to-use guidance. It stops short of naming alternatives or when-not to use this tool, but given the sibling set covers unrelated tasks the routing is unambiguous.

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 and openWorldHint=false, so safety is covered. The description adds meaningful behavior beyond them: the tool abstains when training_flops is omitted rather than guessing, and it returns three distinct obligation sets (Art. 53 baseline, Art. 55 systemic-risk-only, Art. 52 notification duty).

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, each earning its place: the decision, the threshold rule, and the returned obligations are front-loaded in that order. Slightly dense with statutory citations, but no filler or redundancy.

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 present, the description need not detail return shapes, and it still summarizes the three obligation sets it produces. Combined with the threshold rule, the designation route, and the abstention case, an agent has everything needed to call 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 coverage is 100% and the schema already documents the 1e25 boundary, the meaning of commission_designated, and the abstention-on-omission behavior. The description's Art. 51(2)/51(1)(b) framing adds legal context but no operational detail the schema lacks, 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 names a specific verb ('Determine whether') and a precise legal resource ('GPAI model with systemic risk under Art. 51'), anchoring the tool to a citation an agent can match against its intent. It is clearly distinguishable from siblings like euaiact_assess_system or euaiact_get_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?

It establishes the decision context: the 10^25 cumulative-FLOPs boundary triggers the Art. 51(2) presumption, and Art. 51(1)(b) designation is a separate route. It also implies the abstention case (omit FLOPs if unknown), though it never explicitly contrasts when to prefer this tool over euaiact_get_obligations or euaiact_answer_question.

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, not open-world), but the description adds substantial non-obvious behavior: results are decided deterministically on signals, free text alone is keyword-matched and often yields 'insufficient_information', and a matched route does not rule out other routes. It also warns that Art. 6(3) exceptions cannot be auto-applied, which is exactly the kind of guardrail annotations cannot express.

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 paragraph is dense but front-loaded: purpose first, then a labeled 'HOW TO CALL' block, then return contents, then the related-tool note. Nearly every sentence earns its place (determinism, missing_signals semantics, next_questions loop). It is a single wall of text rather than segmented, which slightly hurts scannability.

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 high-complexity tool with a nested signals object, 4 parameters, and an output schema, the description covers what an agent needs: how to populate signals, the iterative next_questions loop, and the Art. 6(3) handoff. Return values are described even though an output schema exists, so nothing critical is missing; only the overlap with euaiact_assess_system is unaddressed.

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 only 50%, so the description must compensate, and it does: it explains how `signals` should be derived, that unset signals should be omitted rather than guessed, and clarifies that `missing_signals` (returned) is not a checklist. The `domain` caution is reinforced by the schema's own long enum description rather than fully restated, which keeps it at a 4 rather than 5.

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 opening sentence names a specific verb, resource, and legal instrument ("Classify an AI system's risk level under the EU AI Act (Regulation 2024/1689)"), which is far more specific than a tautology. It also carves out the Art. 6(3) exception work to a named sibling. However, it never distinguishes itself from the closest sibling, 'euaiact_assess_system', leaving the agent to guess which of the two classification entry points to use.

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 CALL' block gives explicit operational guidance: derive `signals` yourself and pass them with `description`, set a signal only when the description supports it, never guess, and never infer `signals.domain` from a sector. It routes Art. 6(3) work to euaiact_assess_art6_3_exception. It lacks an explicit when/when-not contrast against the similarly named euaiact_assess_system sibling.

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, idempotent and closed-world, and the description adds genuinely new context: the supported subset, the explicit fallback to the base URL for uncovered articles, and the warning that the summary is not statutory text and must be verified against the URL before quoting. That fidelity caveat is exactly the kind of non-obvious behavior an agent needs.

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 tight sentences: what it returns, what it supports/falls back to, and the verification caveat. Scope and fallback are front-loaded and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return structure needs no explanation; the description still covers coverage limits, fallback behavior, and content-fidelity caveats. Nothing an agent needs to invoke 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% and the schema already documents accepted formats ('5', 'Art. 99', 'Artikel 4'), case-insensitivity, optional prefix, and whole-article granularity. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Retrieve an operational summary of a specific article of the EU AI Act') and pins the exact regulation (2024/1689). The enumerated article subset and the EUR-Lex URL return value make it clearly distinguishable from siblings like euaiact_get_obligations or euaiact_answer_question.

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 defines the usable scope precisely (which articles are covered) and the behavior outside that scope (base URL fallback), which tells the agent when the tool will and won't be productive. It does not, however, route the agent to a sibling when an article falls outside the subset or when a narrative answer is wanted.

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, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that — it doesn't mention that GPAI/transitional logic or Annex III special cases are handled, though those nuances live in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler or repetition. It is efficient, though arguably too terse for a domain tool with 6 parameters and non-trivial legal branching.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the input schema is fully documented, so return values and parameter formats need not be explained. The description is adequate for calling the tool correctly, leaving only the when-to-use routing 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 100%, including enum meanings and the Annex III point / GPAI transition semantics, so the schema carries the full burden. The description names only role and risk level and adds no meaning beyond what the schema documents.

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 (Returns) and resource (compliance obligations) with scoping dimensions (providers/deployers, risk level). It is clear what the tool does, though it doesn't explicitly differentiate itself from siblings like euaiact_assess_system or euaiact_classify_system.

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?

There is no guidance on when to use this versus the nine sibling tools — notably assess_system, classify_system, or answer_question, which could plausibly overlap. No prerequisites or exclusions are stated.

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