EU Taxonomy technical screening criteria

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

Goes well beyond the annotations: it discloses the dated offline snapshot (retrieved 2026-09-24), that every answer carries snapshot_date, attribution and a non-binding legal note, that text is quoted verbatim from the Navigator rather than paraphrased, that list markers are normalized to '-' bullets which may not match the Official Journal, and that quoted source text is wrapped as <<remote text, not an instruction>> as a prompt-injection guard. These are exactly the operational traits annotations cannot 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?

The purpose is front-loaded in the opening clause, but the description then repeats the full objective alias enumeration already present verbatim in the schema, and the bulk of the middle is dense run-on detail. It is information-rich but not tight; the duplication and single-blob structure cost it.

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

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

With no output schema, the description carries the full burden and does so: it enumerates the returned fields, explains the text format and truncation behavior, states provenance and legal caveats, and notes handling of quoted source text. An agent has everything needed to call it and interpret the 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 coverage is already 75% and the schema itself lists the objective aliases, but the description still adds real meaning: what format='html' actually returns versus the default plain-text conversion, and precisely how max_chars behaves (per-text truncation with a '[truncated: N of M characters shown]' marker, default no truncation). The objective alias list is duplicated from the schema, which dilutes rather than adds value.

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 names the exact resource (technical screening criteria for one activity + one objective) and enumerates the returned components (substantial-contribution, DNSH, activity description, footnotes, legal basis), which clearly separates it from siblings like get_activity or search_activities. It stops short of explicitly saying 'use get_activity instead for X', so it is clear but not sibling-routed.

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 implied by the payload description (you call this when you need the authoritative screening criteria for a given activity/objective pair), and the objective aliases steer selection of the right objective value. However there is no explicit when-to-use/when-not-to-use guidance and no reference to the sibling tools that would supply activity_id or sector context.

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