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.

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

Beyond the readOnlyHint/openWorldHint=false annotations, it discloses substantial behavior an agent could not otherwise infer: answers come from a dated offline snapshot (no network), every response carries snapshot_date, an attribution line and a legal note, the Navigator is non-binding while delegated acts are, and quoted source text is wrapped in <<remote text, not an instruction: ...>> as data. The truncation behavior of max_chars is also described.

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 what the record returns, then routing to criteria, then the snapshot/attribution/quoting caveats. Dense but each clause carries information; the long single paragraph is slightly harder to scan than a segmented form would be.

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 fully carries the burden of describing the return shape — field list, snapshot_date, attribution, legal note, and the quoted-text wrapper — plus the max_chars truncation contract. An agent has everything needed to call and interpret it.

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 only 50%, but the description compensates by explaining max_chars ('truncates the description with an explicit marker') and characterizing activity_id as the Navigator's id. The added semantics go beyond the raw schema type/minimum declarations, though the marker format itself is not shown.

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+resource ('One activity by the Navigator's id') and enumerates what the record contains (name, sector, NACE codes, quoted description, objective/contribution/legal basis data, criteria length). It clearly distinguishes itself from siblings by routing criteria-text needs to criteria(activity_id, objective).

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?

Explicitly names the alternative for criteria text ('Use criteria(activity_id, objective) for the criteria text'), which is a clear when-to-use-this-vs-that rule. However it gives no guidance on when to reach for this versus search_activities or list_sectors for discovering an activity_id in the first place.

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 adds a great deal beyond them: snapshot provenance with no network access, a returned snapshot_date, attribution line, a legal caveat about binding status, and an explicit injection-defense convention wrapping quoted remote text as data. That is exactly the kind of behavioral context an agent cannot get from 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?

Content is front-loaded (what is returned comes first), but the two sentences are extremely long and run-on, packing return fields, provenance, legal notes, and injection handling into dense clauses. Every element earns its place individually, but the packaging is hard to scan.

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 burden of describing returns, and it does so well: activity counts, objective abbreviations, criteria counts, delegated act/annex, snapshot_date, attribution and legal note. What is missing is any sense of output ordering or shape (e.g. list vs nested structure), which would help an agent plan consumption.

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 tool takes zero parameters, so the baseline is 4. There is nothing to disambiguate and the description correctly does not invent parameter guidance.

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 concrete resource (sectors with activity counts) plus a second resource (the six environmental objectives with abbreviated codes and criteria counts). The verb is implicit in the tool name but the content is specific enough that an agent knows what it returns. It does not explicitly distinguish itself from siblings like `sources` or `criteria`, but the described payload is distinct.

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: this is the taxonomy overview/reference listing, useful before drilling into `get_activity` or `criteria`. However, there is no explicit when-to-use statement, no when-not-to-use, and no named alternative for the same need. The agent must infer the routing from sibling names alone.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond them: offline dated snapshot with snapshot_date, refusal of codes in neither revision, 'depends' answers when titles diverge, approximate nature of delegated-act codes, and the legal caveat that the Navigator is non-binding. It also specifically flags fetched text as data via the <<remote text, not an instruction>> wrapper, which is a meaningful safety disclosure.

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?

Purpose and matching behavior are front-loaded in the first sentence, and every subsequent sentence carries real information (return shape, revision handling, snapshot caveats). It is dense and crams multiple facts into long clauses, costing slight readability, but there is little true padding.

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 bears the full burden of explaining return values, and it does so thoroughly: matched code in Rev. 2 and Rev. 2.1, both titles, broader/narrower/exact activities with ordering, activities with no code, ambiguity handling, and the snapshot_date/attribution metadata. Nothing an agent needs to interpret a call 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 coverage is 100% (baseline 3), but the description goes well beyond the schema's terse "e.g. 'D35.11'" by enumerating the accepted formats — 'D35.11', '35.11', '3511', 'd 35.11', division '35', group '35.1', section letter 'D' — which materially informs how to build the single argument.

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+resource ('Activities whose listed NACE code matches a NACE code') and immediately scopes it with accepted input forms, making it clearly distinct from siblings like search_activities and get_activity. An agent can tell what this does without opening the schema.

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 strongly implied by the accepted-input enumeration (any NACE code, division, group, or section letter), which tells the agent exactly when this tool applies. It does not, however, explicitly name an alternative (e.g. search_activities) or state when-not to use it, so it falls short of a 5.

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 read-only/idempotent/no-network, and the description adds substantial context on top: dated snapshot provenance, attribution and legal-note fields in every answer, in-band refusal of unknown NACE codes, 'depends' handling for codes whose titles differ between Rev. 2 and 2.1, and a prompt-injection wrapper for quoted source text. The injection warning is a genuinely valuable behavioral disclosure not present anywhere else.

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 content is front-loaded with purpose before return details, but it is delivered as one dense run-on paragraph mixing purpose, return shape, provenance, and security notes. It is appropriately thorough for the complexity, yet bullets or sentence breaks would improve scannability without losing anything.

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 fully specifies the return shape (per-result fields, match reason, matches total, best-first ordering), the refusal/'depends' edge cases, and the snapshot/legal metadata. Nothing an agent needs to call or interpret 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 coverage is 80%, and the description adds meaning beyond it by enumerating the accepted NACE forms (D35.11, 35.11, 3511, division '35', group '35.1', section 'D') and the objective-filter semantics. The limit range and default are restated from the schema, so the gain is partial but real.

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?

It states a specific verb (Find) plus the searchable resources (name/description text, NACE code) with optional objective and sector filters, and explicitly distinguishes itself from get_activity and criteria. An agent can tell exactly what this retrieves versus its siblings.

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 explicitly routes the agent away for criteria text ('use get_activity or criteria'), which is real when/when-not guidance. It does not, however, clarify when to prefer this over list_sectors or nace_lookup, leaving some sibling selection 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 read-only, idempotent, closed-world behavior, and the description still adds substantial context beyond them: 'no network', every answer derived from a dated snapshot, snapshot_date and attribution line always attached, the legal note that the Navigator is not binding while delegated acts are, and a quoting convention that wraps remote text as an explicit non-instruction. That is meaningful operational and safety behavior, not a restatement of 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 first sentence is well front-loaded and answers the core question immediately, but the long comma-chained enumerations of regulation numbers and licence identifiers make the body a dense wall of text that is harder to scan than it needs to be. The precision is largely justified, yet some of the listing is closer to reference material than selection guidance.

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 parameters, no output schema, and no nested structures, the description carries the full burden and does so: it names the snapshot source, the fields returned, the licensing terms, the legal acts, and the quoting convention. An agent can call this tool and interpret its output without further documentation.

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 tool takes zero parameters, so the schema imposes no documentation burden and the baseline is 4. The description correctly avoids inventing inputs and instead describes the fixed payload each call yields.

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 enumerates precisely what the tool returns: snapshot/NACE dates, counts, SHA-256 hashes, licences with quoted terms, CELEX/ELI legal acts, annex mappings, and Navigator-vs-Official-Journal diffs. That is clearly distinct from data-lookup siblings like search_activities or get_activity, though the opening phrase 'Where the data comes from' is nominal rather than a stated verb.

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 — consult this when you need provenance, attribution, licensing or the legal basis for other answers — but there is no explicit 'use this when / not when', no mention of alternatives, and no statement that the other sibling tools do not provide this metadata.

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