Assess an AI System Under the EU AI Act

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.