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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context beyond that: concept input may be a label or URI, and label resolution automatically falls back across all 24 official EU languages if the request language has no match.

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 the core purpose and then adds the most important semantic detail about concept resolution. It is dense but contains no filler or repetition.

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 complexity, full schema coverage, rich annotations, and an output schema, the description is largely complete for correct invocation. It could add more about EuroVoc concept matching behavior, such as whether narrower concepts are included, but nothing critical 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 baseline is 3. The description adds real meaning for the concept and language parameters, particularly the cross-language label fallback, while limit and resource_type remain adequately documented in the schema.

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: 'Searches EU legal acts by EuroVoc thematic concept.' It also distinguishes the tool from generic keyword search by explaining it is the right tool for 'documents about X' when the term may not appear in the title.

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 clearly states the intended use case: topical searches where the exact term may be absent from the title. It does not explicitly name eurlex_search or other sibling alternatives, nor does it state when not to use this tool, so it falls short of full when/when-not/alternatives 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real behavioral context: the boilerplate title prefix that affects query matching, and that a ruling without a title in the requested language yields no result. It stops short of discussing pagination or rate limits, so a 4 rather than 5.

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 scope statement comes first, then the four lookup modes, then filters and differentiation. It is longer than typical, but each sentence carries selection-relevant information; the return-field listing is the only mildly redundant part given an output schema exists.

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 10-parameter search tool with an output schema and full annotation coverage, the description supplies everything needed to call it correctly: required-input semantics, combinability, filter interactions, and sibling differentiation. Nothing an agent needs for correct invocation 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?

With 100% schema coverage the baseline is 3, but the description adds meaning beyond the schema: it explains query as case-insensitive contiguous phrase matching and warns that party names follow a boilerplate prefix, and clarifies related_celex as act-to-case-law traversal. These are genuine disambiguations not present in 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 and resource ('Finds CJEU case law') and enumerates the document types it covers (JUDG, ORDER, OPIN_AG) across two courts. It explicitly distinguishes itself from eurlex_search, so an agent can route between them without opening either 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?

Gives explicit lookup modes ('four ways (at least one required, combinable)') with concrete examples for each, plus how to narrow with court/type/language/date filters. It also names the sibling alternative and the condition that selects it ('searches legislation by title' vs. case law).

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 that this is a read-only, idempotent, non-destructive, open-world operation. The description adds meaningful behavioral detail beyond that: direction="both" splits the limit evenly, does not back-fill from the richer side, and may return fewer than limit results, with a counts field reporting each side.

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 purpose and relationship types, followed by the non-obvious balanced-split caveat. Both sentences earn their place and there is 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?

Given full schema coverage, annotations covering safety, and an output schema, the description is complete enough to invoke correctly. It additionally explains the subtle result-count behavior that an agent would otherwise miss.

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 all four parameters. The description adds real meaning for direction and its interaction with limit, especially the non-obvious balanced split behavior, though it does not elaborate on celex_id or language beyond the schema.

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: it finds citation relationships for an EU legal act, and it enumerates the relationship types. It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools such as eurlex_fetch or eurlex_search.

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 direction values and the balanced behavior of direction="both", which helps an agent choose parameters. However, it does not explicitly say when to use this tool versus sibling tools or when not to use it, so usage guidance 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description adds one genuine behavioral fact — that amendments are merged into the returned text — but omits the fallback behavior when an act has no consolidated version and says nothing about truncation/pagination despite offset and max_chars existing.

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 what is retrieved, followed by the identification rule and its constraint. No filler, no repetition of enum values or defaults already in 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?

With 8 optional params, three enums, a full schema and an output schema, the description covers the two identification paths and the CELEX restriction well. The remaining gap is behavioral edge cases (no consolidated version available, pagination continuation), which keep it short of 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%, so the baseline is 3; the description adds real value beyond the schema by stating the mutual-exclusivity constraint (exactly one of celex_id vs doc_type + year + number) and by narrowing celex_id to sector-3 secondary-law CELEX with the 3YYYY[R|L|D]NNNN pattern, which the schema pattern alone does not convey.

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 with scope: 'Fetches the latest consolidated (currently in-force) version of an EU legal act via ELI, with all amendments merged in.' The 'consolidated / currently in-force / amendments merged' qualifier implicitly distinguishes it from eurlex_fetch or eurlex_search, but no sibling is named explicitly.

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?

Gives a strong usage rule for the input forms ('provide exactly one of the two'), but that is parameter-level guidance rather than tool-selection guidance. It never says when to prefer this over eurlex_fetch, eurlex_search, or eurlex_structure, nor what to do if no consolidated version exists.

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/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral detail beyond them: the one-of-three identifier rule (with implicit Cellar resolution) and the offset/next_offset continuation loop that terminates when next_offset is null. It doesn't mention failure modes such as an unresolvable identifier or a language with no available text.

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, no filler: purpose first, then the identifier options, then pagination. Front-loaded and every clause carries an actionable instruction.

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-value explanation is unnecessary; the description instead covers the two things the schema cannot — which identifiers are acceptable and how to loop over pages. For a 7-parameter, fully documented read tool, 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 coverage is 100%, so the baseline is 3; the description earns above baseline by giving concrete identifier examples and, more importantly, the cross-parameter pagination workflow (pass the previous response's next_offset until null) that is not expressed in any single schema field. The format/language/max_chars semantics are left entirely to the schema, which is reasonable.

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 ("Fetches the full text of an EU legal act") that is immediately distinguishable from siblings like eurlex_search, eurlex_metadata, eurlex_structure and eurlex_summary. The three accepted identifier forms are named inline, so an agent knows it can address the resource three different ways.

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?

"Provide exactly one" of celex_id/eli/oj_ref gives an explicit invocation constraint, and the pagination sentence tells the agent how to continue reading a long act. It stops short of naming alternatives (e.g. eurlex_structure or eurlex_summary for non-full-text needs), so sibling 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 cover readOnly, idempotent, non-destructive, and open-world, so the bar is lower. The description still adds real domain behavior: that eli/oj_ref are resolved to a CELEX ID, the distinction between date_entry_into_force and date_application (with the GDPR example), and that dates_effect lists effect dates by type. It does not say what happens on resolution failure or ambiguous input, but with annotations and an output schema this is solid.

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 verb and resource, then the returned fields, then the identifier options. Three sentences, no filler; the GDPR parenthesis earns its place by disambiguating two easily confused date fields.

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 simple read-only metadata lookup, the description plus annotations, full parameter coverage, and an output schema leave nothing an agent needs in order to call it correctly; it even clarifies the entry-into-force vs application-date semantics that would otherwise be a common mistake.

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 every parameter including the exactly-one-of constraint and the language enum with its default. The description's identifier examples and the GDPR date illustration add little beyond what is in the schema; 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?

States a specific verb (fetches) and resource (metadata for an EU legal act) and enumerates the exact fields returned: dates, in-force status, authors, legal basis, EuroVoc descriptors, directory codes. This clearly distinguishes it from siblings like eurlex_fetch (full text), eurlex_summary, or eurlex_search.

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 field enumeration makes the use case clear (you want dates/status/authors, not text), and the identifier rules ('provide exactly one' of celex_id, eli, oj_ref) constrain invocation. However, it never explicitly names a sibling or says when NOT to use this tool versus eurlex_fetch or eurlex_consolidated.

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/openWorld/idempotent/non-destructive, so the bar is lower. The description still adds real operational context: broad single-word terms can be slow, and results are newest-first only within the fetched sample rather than globally newest — a caveat that materially affects how an agent interprets results.

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 core verb and matching model come first, then alternatives, then performance and ordering caveats. Every sentence carries information, though the single paragraph is close to overloaded for one breath.

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 6-parameter filtered search with a full output schema, the description covers the matching semantics, language pairing, performance expectations, and result-ordering limits. Nothing an agent needs to call 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 coverage is 100%, so baseline is 3; the description goes beyond it by clarifying that query is a contiguous phrase rather than tokenized full-text, and by warning that the language code must match the query term — a non-obvious constraint not stated in the schema.

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 ('Searches EU legal acts by title substring') and immediately qualifies the matching model (contiguous phrase, case-insensitive, not tokenized). It is clearly distinguishable from eurlex_by_eurovoc, which is named as the topic-discovery sibling.

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 routes topic-based discovery to eurlex_by_eurovoc and gives concrete narrowing levers (resource_type, date_from/date_to) for slow broad terms. The when-to-use and when-to-use-something-else conditions are both present.

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 destructiveHint=false, but the description adds substantial operational context beyond them. It discloses automatic LIMIT 50 appending, rejection of top-level LIMIT above 100, SPARQL JSON response shape, row_count and truncated behavior, and the ~40k character truncation rule.

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, and the remaining sentences each carry operational value: prerequisites, allowed query types, limit behavior, response format, literal typing, and a concrete example. It is dense but not redundant for a complex expert tool.

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 complexity and the single free-form query parameter, the description is complete enough to call correctly. An output schema exists, and the description still explains response shape and truncation, while also covering safety constraints, query limits, and ontology prerequisites.

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 schema already documents the single query parameter and many constraints. The description still adds useful query-building semantics, especially the CDM ontology guide reference and the caveat that CELEX/ELI literals are typed xsd:string and should be matched with FILTER(STR(?x) = ...).

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: run a raw, read-only SPARQL 1.1 query against the EU Publications Office Cellar endpoint. It explicitly distinguishes itself from named higher-level siblings and frames itself as an expert escape hatch for cases they cannot express.

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 says when to use this tool versus alternatives: only when eurlex_search, eurlex_metadata, eurlex_citations, and others cannot express the need. It also gives prerequisites and exclusions, including reading the eurlex_guide prompt first and disallowing SPARQL Update or federated SERVICE clauses.

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/openWorld, and the description adds substantial behavior beyond them: a hard cap of 300 headings with a truncated=true flag, offsets being language- and format-specific, heading recognition limited to ENG/DEU/FRA, and paragraph-level outlining for CELEX sector 6 case-law that works in any language. These are exactly the non-obvious traits an agent needs to avoid misuse.

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 purpose and the recommended call pattern before detail, and each sentence carries information (offsets, cap, language coupling, case-law paragraphs). It is on the long side and repeats some language-matching guidance already present in the schema, costing a point.

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?

Despite an output schema existing, the description covers the return shape (level, label, title, offset, total_headings, truncated), the truncation edge case, cross-language offset pitfalls, and case-law paragraph exceptions. An agent has everything needed to call it and consume the result 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%, so baseline would be 3, but the description adds real semantics: heading recognition is only reliable for English, German and French documents, and offsets are tied to the language passed here, which must be reused on the follow-up fetch. Much of the 'provide exactly one of celex_id, eli, oj_ref' wording duplicates the schema, keeping this from a 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?

Opens with a specific verb+resource: returns the outline (table of contents) of an EU legal act, enumerating chapters, sections, articles and annexes with character offsets. This is clearly distinguishable from siblings like eurlex_fetch and eurlex_search, and the tool's role as a navigation map is stated outright.

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?

Gives an explicit workflow: read an article's offset from the outline, then call eurlex_fetch(celex_id, format:"plain", offset, max_chars) to jump straight in 'instead of paging from the top of a long act'. It names the alternative tool and the precise condition that selects it, plus the constraint to reuse the same language and format.

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 destructiveHint=false, but the description adds substantial behavioral context beyond those flags. It discloses the output fields, the obsolete flag, other_summaries handling, the clear 'no summary' outcome, and pagination behavior via max_chars/offset and next_offset.

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 the core purpose and then efficiently covers scope, parameters, pagination, missing summaries, and alternatives. Every sentence contributes operational information without 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?

An output schema exists, so the description need not carry the full return-value explanation, but it still provides enough context about returned fields and pagination. Combined with clear alternatives and edge-case handling, the definition is complete for correct 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?

Schema description coverage is 100%, so the schema already documents celex_id, language, max_chars, and offset. The description still adds useful semantics by giving concrete celex_id examples, noting language availability across the 24 official EU languages, and explaining pagination continuation via next_offset.

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: it returns the EU's official plain-language LEGISSUM summary of a legal act. It explicitly distinguishes this from the binding legal text and names eurlex_fetch and eurlex_metadata as alternatives, so an agent can identify the tool's role without inspecting 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?

It explains when to use this tool versus alternatives: use eurlex_fetch for full legal text and eurlex_metadata for structured metadata. It also covers edge cases, including acts with no summary and acts with multiple summaries where the most current non-obsolete one is returned.

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 destructiveHint=false, so safety is covered. The description adds non-obvious behavioral details: results are capped at limit while total_found reports the full count, and national measure titles are returned in the member state's own official language and are not translated. It does not discuss rate limits or pagination beyond the cap, so it falls short of a 5.

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 the core purpose and then moves through examples, filtering, and return semantics. It is dense and informative, though fairly long; nearly every sentence adds value, but it could be tightened slightly without losing meaning.

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?

Even though an output schema exists, the description explains the key return fields (member state, national measure title, date, sector-7 NIM CELEX, EUR-Lex URL) and the total_found/limit relationship. Combined with the annotations and full schema coverage, an agent has everything needed to invoke and interpret the tool 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 all four parameters. The description still adds useful meaning: it explains that celex_id must be a sector-3 directive CELEX with examples (NIS2, Data Protection Directive), clarifies the country code convention, and emphasizes that language only affects the eurlex_url locale, not NIM titles.

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 gives a specific verb and resource: it lists national implementing measures enacted to transpose a given EU directive. It also explicitly distinguishes this from eurlex_fetch/eurlex_metadata and notes that regulations and decisions have no NIMs, so an agent can tell exactly what this tool is for.

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 states the use case (transposition and compliance tracking), names the sibling tools to use for the directive itself, and explicitly excludes regulations and decisions. It also explains the optional country filter and says to omit it to return all member states.

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