OpenHelvetia Gateway

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

The readOnlyHint annotation already covers the safety profile. The description adds meaningful behavioral detail beyond the annotation: results contain real entries only, empty lists are honest states, and results are never padded. This is useful context, though it could be more explicit about what an 'envelope' contains.

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 a single dense sentence with the resource name front-loaded and every clause carrying semantic weight. It is concise, but the unexplained parentheticals and domain-specific references reduce immediate readability.

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?

There is no output schema, so the description should carry the burden of explaining what the tool returns. It vaguely promises a 'directory envelope' with real entries but does not define the entry shape, fields, or relationship to manifest.get, and 'E21' is left unexplained. For a parameterless tool this is less severe, but an agent still lacks enough detail to interpret the result confidently.

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 has zero parameters and an empty input schema, so the parameter-semantics burden is minimal; the baseline for zero-parameter tools is 4. The description correctly avoids inventing parameter details where none exist.

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 resource ('directory envelope') and a key guarantee ('real entries only'), so it is not a pure tautology. However, it never states the operation in plain terms such as 'returns the directory of admitted data sources,' and jargon like 'v0.2, authority: manifest' and 'E21' obscures the basic purpose. It only partially distinguishes itself from sibling tools like manifest.get.

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 explicit guidance on when to use this tool versus alternatives. The description hints at the manifest as an authority but never points to manifest.get or explains how directory.get differs from other read-only listing tools, leaving the agent to guess at the appropriate selection 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?

Annotations already mark the tool as read-only. The description adds two useful behavioral details beyond that: the empty-record rendering ('«no facts» in grey') and the precision guarantee ('never rounded up'). It does not mention auth or rate limits, but the read-only annotation lowers the burden.

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 a single front-loaded sentence. It states the endpoint type, the scope, and both edge-case behaviors without waste.

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 badge endpoint, the description plus annotations cover the core return type and safety profile. However, the missing domain semantics and lack of usage guidance leave an agent uncertain how to construct valid calls. Thus it is minimally complete but not robust.

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 schema documents only 'subject' with an example; 'domain' has no description and the tool description does not explain it either. The phrase 'one subject' does not clarify what domain values are valid or how subjects are keyed beyond the schema example. With only 50% schema coverage, the description should compensate but does not.

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 identifies the tool as a shields.io endpoint that returns JSON for one subject from the fact table, so an agent knows the deliverable. It does not use an explicit verb such as 'returns' or 'gets', and it does not explicitly contrast with facts.latest, though 'one subject' helps scope 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?

No guidance is given about when to choose this tool over facts.latest or other siblings. 'Derived from the fact table' is context but not an explicit when-to-use statement. Prerequisites and exclusions are absent.

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 declare readOnlyHint=true, so the safety profile is already known. The description adds meaningful behavioral context: the as_of cutoff is exposed, and an absent store returns an honest empty view rather than an error. This helps an agent anticipate edge-case behavior beyond what annotations supply.

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 a single sentence, front-loaded with the core purpose, and every clause adds information about behavior or semantics. There is no filler or redundant restatement of the tool name.

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 only two parameters, one of them optional, and a readOnly annotation, the description covers the main concerns: what is returned, the temporal cutoff, and the empty-store case. Without an output schema, it leaves some return-shape detail implicit, but the tool is simple enough that this is a minor 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%, so the schema already documents both parameters. The description reinforces the role of as_of through the bitemporal wording, but it does not add substantial new parameter-level meaning 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 clearly identifies the resource ('versioned fact table') and the specific result ('latest effective facts per subject+metric'). It does not explicitly name a sibling differentiator, but the bitemporal and fact-table framing makes its role distinct from the other listed 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 implied rather than stated: an agent can infer this is the tool for retrieving current or as-of effective facts, especially when bitemporal cutoff matters. However, there is no explicit guidance about when to prefer an alternative tool or exclude this one.

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?

Besides readOnlyHint, the description adds an important behavioral trait: false is a valid answer and never an error. This prevents the agent from misinterpreting a negative result as a failed call.

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 core sentence is compact and front-loaded, but the trailing 'norm.' is cryptic and uninformative. It adds noise to an otherwise efficient definition.

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 two-parameter read-only boolean check the description provides the essential semantics: what is checked, the date, and how to interpret false. Without an output schema, the return-value behavior is sufficiently implied, though invalid-input behavior is not covered.

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 schema already documents as_of as an ISO date, and the description's 'on a date' adds little. The required eli parameter is not explained in either the schema or description, so the agent is left guessing what identifier to provide.

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 uses a specific verb ('Check whether') and a clear resource/scope ('an act was in force on a date'), which distinguishes it from the many fedlex lookup and search siblings. The German use-case phrase makes its intent concrete.

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 targets «gilt das noch?» questions and clarifies that a false result is legitimate rather than an error. It does not name alternative tools, but the intended context is clear enough for routing.

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?

The annotation readOnlyHint=true already covers the safety profile, so the description only needs to add context beyond that. It explains that the tool verifies wording against one element and serves as evidence in the citation chain. It does not describe return values or edge-case behavior, but the annotation lowers the burden.

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 core guidance is concise and front-loaded: check a quote against one element, use before citing. However, the trailing fragment 'norm.' appears to be a stray or incomplete word that adds confusion without earning its place.

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 read-only tool with four fully documented parameters, the description provides sufficient workflow context and scope. It omits return-format details, but no output schema exists and the purpose statement makes the intended outcome inferable. Minor gaps such as language defaults are already covered by the parameter schema.

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 each parameter is already well documented (eli_version, eid, quote, lang). The description adds only the 'one element' scope and the citation-proof purpose, so it does not need to compensate for missing schema semantics.

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 ('Check a quote') against a specific resource ('the norm text of one element'), and further clarifies its role in the workflow: 'use before citing, to prove the wording is in what was read.' This clearly distinguishes it from related tools like fedlex.cite or fedlex.read_article.

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 explicitly tells the agent when to use the tool: before citing, to verify that a quote is supported by the source read. It does not enumerate exclusions or name alternative tools, but the intended usage context is clear enough for an agent to select it correctly among siblings.

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, and the description is consistent with that. It adds the canonical-citation output concept and the Belegkette use case, but does not disclose the exact return shape, language default behavior, or error cases. This is adequate but not rich.

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 main sentence is compact and front-loaded with purpose and an example. However, the trailing 'norm.' fragment is unclear and appears vestigial, which weakens the overall structure.

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 should define the return value more explicitly; it implies a canonical Fundstelle string via the example, which helps. It omits language handling and failure behavior, though the read-only annotation and complete parameter schema cover some ground.

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 repeats eli_version and eId as inputs but adds no syntax or behavioral detail beyond the schema; the lang parameter is only 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 ('Cite'), a specific resource ('an element'), and the result ('canonical Fundstelle'), with the required inputs named. It is distinguishable from sibling tools like parse_reference by direction (structured inputs to canonical label), though it does not explicitly name that 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?

It gives a concrete when-to-use context: labeling a read place in the Belegkette. It does not state when not to use it or explicitly compare alternatives, so it falls short of full 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?

With readOnlyHint=true already conveying the safety profile, the description adds meaningful behavioral detail: the comparison result includes added, removed, and changed paragraphs with wording, and defaults to every article unless an eid scopes it. This tells the agent what kind of output to expect without relying solely on the annotation.

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 main content is a compact, front-loaded sentence that states the action, scope, and result format. The final 'norm.' appears to be a stray token or typo and is the only real distraction. Overall, the description is efficient and readable.

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 phrase 'added, removed, changed paragraphs with wording' gives a minimal but sufficient expectation of the return. The description, together with the fully covered schema, covers the important choices: optional element scope, older/newer version parameters, and language default. It could say more about output structure or version resolution, but the tool is safely invocable from this definition alone.

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 all five parameters. The description reinforces that eid is optional and that default behavior is 'every article', but it adds little beyond what the schema property descriptions already state. A baseline 3 is appropriate here.

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 operation (compare), a specific resource (two Fassungen of an act), and a clear scope (an element or every article). It also states the expected outcome — added, removed, and changed paragraphs with wording — which makes it easy to distinguish from reading or listing tools. The trailing 'norm.' is cryptic, but it does not obscure the core purpose.

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 gives an explicit trigger intent: use for «was hat sich geändert?», meaning 'what changed?'. This is practical guidance for an agent deciding when to invoke this tool. It stops short of naming alternatives or stating when not to use it, so it does not reach the full 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 mark the tool readOnlyHint=true, and the description adds the behavioral nuance that this is a pre-flight check for content that text tools hide. It discloses the detection categories rather than just repeating the read-only signal.

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 compact and front-loaded with the action and target, and every clause adds information. The trailing 'norm.' is cryptic and unexplained, which prevents a perfect conciseness score.

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 read-only detection tool with a documented schema, the description gives enough context to invoke it, but with no output schema it does not describe the shape of the detection result. The unexplained 'norm.' also leaves a small gap in what the agent should do with the output.

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%: both lang and eli_version are already documented, including the eli_version format. The description adds no new parameter-level semantics beyond the general notion of xml:lang, 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 ('Detect'), a specific resource ('Fassung'), and concrete artifacts it surfaces ('sections in another language (xml:lang)' and '<foreign> islands'). This makes the tool's niche clear and distinguishes it from the read_document/read_article text tools without needing to inspect schemas.

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?

'Use before quoting' is an explicit, actionable trigger telling an agent when to call this tool. It does not name alternatives or state when not to use it, but the context is clear enough for selection among the fedlex siblings.

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. The description adds behavioral context beyond that: edges are returned in both directions and are capped, and the result is diagnostic rather than authoritative. This helps the agent understand the tool's intent and limitations.

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 sentence conveys the operation, scope, cap behavior, intended use, and an important caveat. There is no filler or repetition of schema content.

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?

The tool is simple, read-only, and its purpose is well described. There is no output schema, but the description already explains that the result contains predicates and neighbours in both directions, capped. Minor details about the exact response shape are not essential for selecting and invoking this 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 fully documents both 'iri' and 'limit'. The description adds graph-oriented context but does not need to repeat parameter details. 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 ('explore'), a precise resource ('a JOLux node's edges'), and the exact scope: predicates and neighbours, both directions, capped. This clearly distinguishes it from sibling getter tools that retrieve specific documents or metadata.

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 it: 'use to debug what the graph holds about an IRI'. It also gives a clear exclusion, 'never as proof', which prevents misuse. It does not name a specific alternative tool, but the use case is clear enough.

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?

The readOnlyHint annotation already covers the safety profile. The description adds meaningful behavioral detail: it extracts tables, can scope to a single element such as an annex, and returns data as header and rows. There is no annotation contradiction.

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 compact and front-loaded with the core action and resource. The only flaw is the trailing 'norm.' fragment, which appears to be a stray word and slightly weakens an otherwise tightly written definition.

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 read-only annotation, the fully described parameters, and the simple table-extraction behavior, the description covers the essential selection and invocation context. The absence of an output schema is partially compensated by the 'header and rows' return description, though more detail about how multiple tables are returned would make it fully complete.

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 value by explaining that the eid scope can target annex limit values or tariffs and that eli_version refers to a consolidation, which enriches the schema's dry parameter descriptions.

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 action ('Extract the tables'), a specific target ('a consolidation or of one element'), and the output form ('as header and rows'). It also clarifies the intended use case ('use when a norm is a table, not prose'), which distinguishes it from prose-reading siblings like fedlex.read_document.

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 gives an explicit usage cue: use it when a norm is a table rather than prose. It does not name a specific alternative tool, but the when/when-not distinction is clear enough for an agent to decide between tabular extraction and ordinary text reading.

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?

The readOnlyHint annotation already covers the safety profile, so the bar for the description is lower. The description adds useful context with 'candidates only', indicating the results are non-authoritative suggestions, but it does not describe output shape, ordering, or how the taxonomy relation is computed. No contradiction with 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 description is compact and mostly information-dense, front-loading the core purpose. The trailing 'hint.' is cryptic and slightly undermines clarity, but overall the description avoids unnecessary words.

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 lookup tool, the description covers the core input and purpose. However, with no output schema, the absence of any description of the return shape or candidate format is a noticeable gap, even though 'candidates only' gives a partial hint.

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 parameter semantics are already well documented in the schema. The description restates the ELI-or-SR entry options but adds little beyond what the schema descriptions already provide.

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 clearly identifies the action: find acts in the same field of law via the legal taxonomy, using ELI or SR as entry points. It is specific about the resource and operation, though it does not explicitly differentiate itself from similar taxonomy-related sibling tools like fedlex.explore_node or fedlex.get_taxonomy.

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 includes an explicit use directive ('use to discover neighbouring Erlasse'), which conveys intent, but it gives no when-not-to-use guidance or named alternatives among the many fedlex siblings. The routing decision is left mostly 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?

The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful domain context ('Staatsverträge') and the workflow hint about get_treaty_info, but it does not disclose return shape, pagination behavior, or any search limitations. Given the annotation coverage, this is acceptable but not particularly rich.

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 compact and front-loaded with the core purpose and search dimensions. However, the trailing 'hint.' fragment is an unclear artifact that adds no value and slightly weakens the overall polish.

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 search tool with no output schema, the description does not explain what the returned results look like or how an agent should use them beyond naming get_treaty_info as the next step. It is sufficient for tool selection but leaves the agent without expected return structure or edge-case behavior.

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 parameters are already fully documented at the schema level. The description loosely mirrors query, country, and bilateral but adds no meaningful detail beyond the schema, and it does not mention the limit parameter. 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?

The description states a specific action ('Find'), a specific resource ('treaty processes (Staatsverträge)'), and the supported search criteria ('title word, partner country IRI or bilaterality'). It also distinguishes itself from the closely related get_treaty_info by positioning itself as the location step before that tool, though it does not explicitly contrast with search_law or search_text.

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 gives a clear usage context: use this tool to locate a treaty before calling get_treaty_info. This explicitly names one alternative and the workflow position, which is strong guidance. It does not mention when to prefer search_law or other search tools, so it stops short of full exclusion criteria.

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?

The readOnlyHint annotation already covers the safety profile, so the description does not need to restate that. It adds useful behavioral context by stating that the tool returns historical amendment and consolidation information with dates. It does not describe the response structure, but the core behavior is transparent enough for a read-only query tool.

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 a single front-loaded sentence that states the behavior and the intended question in a compact way. The trailing '. norm.' adds minor noise and slightly weakens the structure, but overall the description is tight and useful.

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 two well-documented parameters and no output schema, the description provides enough context: it tells the agent what the tool traces, what entity it operates on, and what kind of information (amendments, consolidations, dates) the result contains. It does not enumerate specific return fields, but for a history-tracing tool this is adequate.

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%, with both eid and eli clearly documented in the input schema. The description reinforces that eid identifies 'one Artikel' and that eli refers to an act, but it does not add meaningful parameter-level details beyond 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?

The description uses a specific verb, "Trace," and names the exact resource: amendments and consolidations that changed one Artikel (eId) of an act, including dates. This clearly communicates the tool's function. It does not explicitly differentiate it from close siblings like fedlex.get_modifications or fedlex.compare_versions, but the intent is still clear.

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 gives an explicit use case: «seit wann gilt Art. X so?» (since when does Art. X read this way?), which tells an agent when to invoke the tool. It does not mention when not to use it or name alternative tools, so it falls short of a perfect score.

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?

The annotations already declare readOnlyHint=true, and the description adds useful behavioral context by separating act-level formal citations from the foreseen-impact graph and noting that in|out are mostly consultation drafts. It does not describe output shape or pagination, but for a read-only listing tool the annotation lowers the bar.

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 compact and front-loaded with the core operation before listing direction options and usage. It is efficient and avoids fluff, though the wording around 'X. norm.' is slightly awkward and could be clearer.

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 two-parameter read-only tool, the description adequately covers the purpose and direction semantics. However, since there is no output schema, the lack of any description of return values or eli expectations leaves some uncertainty about how to 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?

The schema fully documents the direction parameter, but the eli parameter has no schema description and the tool description only implies it identifies an act ('an act's relations'). With 50% schema coverage, the description should compensate for the undocumented eli parameter but does not explain its format or expected content.

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 uses a specific verb ('List') with a clear resource ('an act's relations') and distinguishes the four supported directions: cites|cited_by for formal citations and in|out for foreseen impacts. This is specific enough to separate the tool from generic relation-list 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?

The description gives an explicit intended use: 'use to see who cites X. norm.' However, it does not mention when not to use this tool or compare it with similar siblings like fedlex.get_references or fedlex.explore_node, so alternative selection guidance is absent.

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?

The readOnlyHint annotation already establishes the read-only safety profile, and the description adds a little context by framing this as reading the 'genesis record.' However, it does not disclose return shape, empty-result behavior, or error handling, so the added behavioral transparency is limited.

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 main instruction is front-loaded and compact, but the trailing 'norm.' appears to be unexplained noise, and 'genesis record' is vague. This prevents the description from being as clean and purposeful as it could 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?

Given the single required parameter, complete schema coverage, and readOnlyHint annotation, the description provides enough context for a simple list operation. It identifies the input source, the output category, and the workflow position, though an output schema or a bit more detail on results would make it fully complete.

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 parameter description already says 'The consultation IRI (from get_consultations).' The tool description reinforces 'one consultation IRI' but does not add meaningful new detail 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 clearly identifies the action ('List') and the resource ('position statements and result reports of one consultation IRI'). It also distinguishes this from the related get_consultations flow by specifying that it operates on a single consultation IRI.

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 explicitly says 'use after get_consultations', giving the agent a clear workflow trigger. It does not name alternatives or state when not to use the tool, so it falls just short of full 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?

The readOnlyHint annotation already communicates that this is a safe read operation, and the description's 'List' wording aligns with that. The description adds some useful context about the use case, but beyond that it discloses no additional behavioral traits such as pagination behavior or how eli vs. draft is prioritized.

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 a single sentence that front-loads the core action and resource, then adds important usage context. The trailing word 'hint.' adds no value and is slightly confusing, preventing a perfect score.

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 list-style read-only tool with four fully documented parameters, the description gives enough orientation: it identifies the resource, the output flavor ('status and dates'), and the intended use case. There is no output schema, so a bit more detail about the exact response structure would be helpful, but the description is adequate 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 coverage is 100%, so the schema already documents eli, draft, limit, and status. The description adds the high-level relationship between 'act's drafts' and 'one draft', but it doesn't enrich individual parameter semantics beyond what the schema already provides. 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?

The description clearly states a specific verb ('List') and resource ('consultations of an act's drafts or of one draft'), and it distinguishes the tool by adding 'with status and dates' and 'never for law in force.' This makes it easy for an agent to tell it apart from similar Fedlex tools like get_consultation_documents.

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 gives explicit guidance on when to use it ('use for the genesis') and when not to ('never for law in force'). It doesn't name alternative tools explicitly, which keeps it slightly below a 5, but the context is clear enough for selection.

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?

The description is consistent with the readOnlyHint annotation, and it adds useful context: the tool traces an act back to its originating drafts and surfaces the Curia Vista number. It does not disclose return shape, pagination, or error behavior, but for a read-only single-ELI lookup the annotations already cover the safety profile.

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 main sentence is short and front-loaded with the key action. However, the orphaned 'norm.' at the end is an unexplained fragment that does not earn its place and makes the description feel structurally incomplete.

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 one-parameter, read-only tool without an output schema, the description provides enough to invoke it correctly: what it lists, the input concept, and its intended role as a starting point for consultations and materials. It could be more explicit about the response format, but the tool's simplicity keeps this from being a major 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% and the only parameter, eli, is already described as 'Fedlex ELI of the consolidation abstract.' The description adds only a small hint that drafts use 'eli/proj' identifiers, but it does not meaningfully extend the parameter semantics 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 action and resource: it lists the legislative drafts (Entwürfe, eli/proj) that an act originated from, and includes the Curia Vista number as a visible output feature. This clearly distinguishes it from the many other fedlex retrieval tools focused on consultations, references, or versions. The trailing 'norm.' is noise, but the core purpose remains unambiguous.

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 explicitly says to use this tool 'as the entry to consultations and materials,' which gives clear contextual guidance on when it is valuable. It does not name alternatives or state when not to use it, so it stops short of the full 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 declare readOnlyHint=true, so the safe read-only nature is covered. The description adds useful context about what kind of documents are returned (genesis materials, with genre and date) but does not disclose details like output format, pagination, or behavior on invalid ELIs. This is acceptable given the read-only annotation, but not rich.

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 a single sentence with the main action and resource front-loaded, followed by useful examples and usage guidance. However, the trailing '. norm.' fragment is unclear and slightly detracts from the otherwise clean structure.

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 one-parameter, read-only listing tool, the description covers the core intent, the material types, the returned fields, and the critical exclusion (law in force). While there is no output schema, the description's mention of 'genre and date' partially compensates. Remaining gaps such as exact response structure are minor for this tool's simplicity.

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 schema already provides 100% coverage for the single parameter 'eli,' describing it as a Fedlex ELI of the consolidation abstract. The description reinforces that the ELI should refer to an act whose genesis documents are wanted, but it does not add further parameter-level detail beyond the schema's 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 states a specific verb ('List'), a precise resource ('Federal Gazette (BBl) documents of an act's genesis'), and even names the content types ('Botschaft, reports') and output fields ('genre and date'). It makes the tool's scope immediately distinguishable from siblings that deal with law in force or other document types.

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 explicitly says 'use for materials, never for law in force,' giving the agent a clear when-to-use and when-not-to-use rule. This is particularly valuable given the large sibling set and the conceptual overlap between genesis documents and current legal texts.

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?

The description's 'Read' aligns with readOnlyHint=true, so there is no contradiction. It adds the fact that this exposes a profile rather than full text, but does not disclose other behavioral details such as response shape, pagination, or error behavior; with the annotation carrying the safety profile, this is adequate but not rich.

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 a single front-loaded sentence with a parenthetical list of returned fields and a clear use case. The trailing 'norm.' fragment adds no signal and prevents a perfect score.

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 with one required parameter and no output schema, the description plus schema covers the invocation: input ELI, optional as_of, expected profile fields, and use case. Minor gaps like defining JOLux are not essential to 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?

The description clarifies the ELI as the lookup key, compensating for the schema's undocumented 'eli' property. The optional 'as_of' parameter is already fully described in the schema, so together the meaning of all parameters is covered.

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 specific verb and resource: 'Read the JOLux profile of an act' for an ELI, and enumerates returned fields (titles de/fr/it, status, dates, identifier). This narrows the tool to a metadata-profile lookup and distinguishes it from sibling tools like read_document or get_modifications that imply broader reads.

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 gives a clear intended use: 'use to confirm a search hit before you cite.' It does not name alternatives or state when not to use it, but the context is sufficiently clear for an agent selecting among the many fedlex siblings.

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?

The read-only hint already covers the safety profile, so the bar is lower. The description adds that the tool lists the memorial issue and its acts, but it does not disclose output shape, ordering, or any behavior beyond 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?

The main sentence is concise and front-loaded with the action and resource. The trailing 'norm.' is unexplained and slightly distracting, preventing a perfect score.

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 read-only lookup tool with one required parameter and a simple optional limit, the description conveys the purpose, the input origin, and the broad output. Without an output schema, a bit more return-format detail would be ideal, but the core information is present.

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%, including the eli provenance and the limit range/default, so the schema does the heavy lifting. The description adds little parameter-specific meaning beyond what the schema already states.

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 ('List') and a specific resource: the AS/BBl issue (memorial) an OC publication appeared in, plus the acts of that issue. It also distinguishes itself from get_oc_act by explicitly positioning it as the follow-up step.

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 instruction 'use after get_oc_act to locate the volume' gives clear sequential usage context. It does not enumerate when-not-to-use or alternative tools, so it stops 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 declare readOnlyHint=true, so the read-only nature is established. The description adds behavioral substance: results are per element of a consolidation and contain amendment notes with AS references. It does not discuss auth or rate limits, but those are less critical for a read-only list operation.

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 core description is one dense, front-loaded sentence followed by a concrete query example. The trailing 'norm.' is unexplained noise and slightly weakens the otherwise tight structure.

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 read-only list tool, the description plus schema covers the required consolidation ELI, optional eid scope, language, and the intended question. There is no output schema, but the nature of the return value ('amendment notes') is clear enough. A small gap is that it does not explicitly mention default behavior for lang, though the schema already covers that.

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 fully documents eli_version, eid, and lang. The description adds only conceptual context ('consolidation', 'per element') without providing new parameter-level syntax or constraints.

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 specific verb and object ('List the amendment notes ... per element of a consolidation') and shows exactly what kind of data is returned ('Fassung gemäss …', AS refs). The quoted use case makes its purpose unmistakable and distinguishes it from related read/history 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?

The description explicitly states when to use it: 'use for «wann und wodurch wurde Art. X geändert?»'. It gives a clear invocation criterion, though it does not mention alternatives or when not to use it.

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?

The readOnlyHint annotation already communicates the safety profile; the description adds the input-to-output transformation (consolidation ELI to binding publication metadata). It does not disclose potential error cases, e.g. when no AS/RO publication exists, or the exact response shape.

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 a compact single sentence that front-loads the action and output. The odd '. norm.' fragment is distracting and should be removed, but otherwise every phrase contributes required context.

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 one-parameter read-only resolver, the description covers the required input, the relationship between input and output, and the output fields, which is sufficient to invoke the tool. A richer description might note missing-publication behavior, but this is a minor gap given the tool's simplicity.

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%: the single `eli` parameter is already described as a Fedlex ELI of the consolidation abstract. The description restates 'consolidation ELI' without adding format details, examples, or acceptance criteria, leaving the schema as the primary documentation.

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 action ('Resolve') on a specific resource (an act's binding AS/RO publication) and names the expected output fields (oc ELI, date, genre, office, memorial), which distinguishes it from generic Fedlex getters. The trailing 'norm.' is unexplained and slightly undermines clarity, but the core purpose is unambiguous.

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?

'Use to cite the Amtliche Sammlung' gives a clear invocation context and tells an agent when this resolution is needed. It does not explicitly name alternatives or exclusion cases, but no direct sibling appears to cover the same AS/RO-binding-publication resolution purpose.

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, so the safety profile is covered. The description adds useful context about ELI inclusion and eId scoping, but it does not describe pagination behavior or the shape of the response beyond 'references with ELI where linked'.

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 one efficient sentence with the core action front-loaded. The only flaw is the trailing 'hint.' token, which is noise and does not contribute 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?

The schema documents every parameter, and the annotation covers the read-only nature, so the description does not need to repeat those. It tells the agent what the tool returns (references with ELI where available) and when to use it. A small gap is the lack of explicit pagination/continuation context, though the offset parameter description partially covers that.

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 parameters are already well documented. The description adds the eId scoping idea, but it mostly restates what the schema already explains; 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 names a specific verb ('List'), a specific resource ('references an act's text makes'), and a key feature ('with ELI where linked, optionally within one eId'). It is distinct enough from siblings like get_citations or parse_reference because it describes outgoing references from an act, and even states the intended use of following cross-references.

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 explicitly says 'use to follow cross-references,' which provides clear usage context. It does not name exclusion criteria or alternatives, but the stated purpose is enough for an agent to understand when this tool fits.

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 mark this as read-only, and the description adds useful context about what the outline includes and how the depth parameter changes the result from a skeleton down to articles versus a full tree down to paragraphs. It does not contradict the readOnlyHint annotation.

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 sentence front-loads the tool's purpose and usage context efficiently. The trailing 'norm.' is unexplained and adds minor noise, preventing a perfect score.

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 read-only outline tool with three well-documented parameters and no output schema, the description supplies enough context: what is returned, the depth variants, and when to use it. The schema covers the remaining input semantics, so the overall package is sufficiently complete.

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 lang, depth, and eli_version in sufficient detail. The description itself does not meaningfully add parameter-level meaning beyond what the schema provides, 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 clearly states a specific verb ('Outline'), a concrete resource ('one consolidation'), and the content delivered ('sections, articles with eId, num and heading'). It also differentiates the tool from article-level lookups by specifying the scenario 'when you know the act but not the article number.'

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 gives an explicit usage trigger: 'use when you know the act but not the article number,' which implies the alternative of a more targeted article-reader when the article number is known. It stops short of naming sibling tools or stating explicit when-not-to-use cases, so it is not a perfect 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 declare readOnlyHint=true, and the description adds meaningful behavioral scope beyond that: it returns only amended elements and functions as a gap catalogue. This clarifies an important non-obvious filter behavior that the schema and annotations do not 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 description is compact and front-loads the core action and scope. However, the trailing 'norm.' is an unexplained stray fragment that does not earn its place and slightly undermines clarity.

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 single-parameter read-only listing tool with no output schema, the description provides enough context to decide when to call it and what to expect: a list of amended subdivisions showing which articles carry amendments. It also names the relevant alternative, so the decision context is complete.

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%: the single 'eli' parameter is already described as a 'Fedlex ELI of the consolidation abstract.' The tool description adds no additional parameter-level details, 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?

The description opens with a specific verb and resource: 'List the subdivisions JOLux knows for an act.' It further clarifies scope with 'amended elements only, a gap catalogue' and explicitly differentiates itself from get_structure by naming it as the outline alternative. This distinguishes the tool clearly from 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?

The description gives an explicit use case: 'use to see which Artikel carry amendments.' It also names the alternative get_structure for outlines, which tells the agent when not to choose this tool. This is direct, actionable 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 declare readOnlyHint=true, lowering the bar for safety disclosure. The description adds useful behavioral context by indicating the tool produces a classification consisting of SR branch chain, notation, and trilingual labels, which is beyond what a bare 'classify' would 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 description is compact and front-loads the core purpose, then gives a concrete usage hint. The trailing 'norm.' is slightly cryptic and could confuse, which prevents a perfect score.

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 only one well-documented parameter and a readOnly annotation, the description covers the essential selection and invocation context. It also notes the return categories enough to set expectations despite lacking an output schema. Minor ambiguity around 'norm.' and exact output format prevents a higher score.

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 'eli' parameter is already described as 'Fedlex ELI of the consolidation abstract.' The tool description does not add further parameter detail, so the schema carries the semantic weight; this meets the 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 states a specific action ('Classify an act in the systematic collection') and clearly identifies the relevant output aspects (SR branch chain, notation, labels de/fr/it). The quoted German question 'zu welchem Rechtsgebiet gehört X?' makes the intended use immediately recognizable and distinguishes it from other Fedlex 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?

It gives an explicit use case via the question 'zu welchem Rechtsgebiet gehört X?', which tells the agent when to invoke this tool. It does not explicitly mention exclusions or alternatives, but the intent is clear enough for selection among many sibling tools.

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?

The readOnlyHint annotation already signals a safe read operation, and the description aligns by saying 'Read.' It adds useful context by naming the profile components returned, such as title, signature, bilateral status, partner countries, and approving decree. It does not detail response formatting, but the annotation lowers the disclosure burden.

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 a single compact sentence with the core purpose and usage context front-loaded. The trailing 'norm.' token appears to be a leftover fragment and adds no value, preventing a perfect structural score.

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 operation with one required parameter, full schema coverage, and readOnlyHint, the description provides enough context: expected input, usage sequence, and the content of the profile. While there is no output schema, the listed fields cover most of what an agent needs to anticipate. A more explicit statement of response shape would be nice but is not critical here.

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 both parameters are already documented there. The description mostly reinforces the eli source guidance already present in the schema and does not add anything about lang. This meets the baseline for schema-covered parameters but adds limited value beyond the structured fields.

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 precise operation ('Read') and resource ('treaty process profile'), and it enumerates the profile fields. It is clearly distinguished from search-oriented siblings like find_treaties, and the meaning is not obscured by the stray 'norm.' suffix.

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 explicitly instructs agents to call this tool after find_treaties, establishing both the data source and the expected input, an eli/treaty IRI. It does not list exclusions or alternative getters, but the sequencing guidance is clear and 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 already declare readOnlyHint=true, so the safety profile is covered. The description adds value beyond that by revealing the output shape (titles and path eIds) and the exact path eId format (annex_u1/…), which an agent needs to proceed to read_article. No contradiction with 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 core sentence is compact and front-loaded with the essential purpose. The only minor blemish is the trailing 'norm.', which appears to be a stray artifact and adds slight noise without contributing 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?

For a simple read-only list operation with two well-documented parameters and no output schema, the description adequately explains the return value and how to use the result. Nothing critical is missing for an agent to call this 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%, with both lang and eli_version already documented meaningfully in the schema. The description does not add significant parameter-level semantics beyond referencing the consolidation, so the baseline score 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?

The description states a specific verb ('List') and resource ('annexes of a consolidation'), and also specifies the returned content ('titles and path eIds'). It is easy to distinguish from siblings like read_article or get_structure because it focuses narrowly on annex listing.

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 explicitly tells the agent when to use this tool: 'use before reading an Anhang with read_article.' This provides useful sequencing context. It does not enumerate when-not-to-use cases or alternatives, but the clear precondition is sufficient for this narrow tool.

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?

The readOnlyHint annotation already communicates safety, and the description adds behavioral value by explaining what the list reveals: available language versions, XML/PDF manifestations, and whether a version is PDF-only. No contradictions or undisclosed side effects are apparent.

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 core purpose is front-loaded in one efficient sentence, followed by a practical usage hint. The stray trailing 'norm.' is minor noise that prevents a perfect score, but overall there is no wasted explanation.

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, one-parameter tool with no output schema, the description supplies enough context: it names what is returned, the scope, and the use-before-reading workflow. It could be slightly richer about the return shape, but the current level is adequate.

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 single parameter eli_version is already described with a clear pattern. The description only restates 'one consolidation' without adding format details or edge-case guidance beyond the schema, so it stays at the 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 begins with a clear action ('List') and exactly specifies the resource ('language versions and manifestations (XML, PDF) of one consolidation'). Scoping to a single consolidation distinguishes it from broader sibling tools like fedlex.list_versions, even without naming them.

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 phrase 'use before reading' gives an explicit when-to-use signal tied to a concrete decision: checking whether a Fassung is PDF-only. It does not name alternatives or when-not-to-use conditions, which keeps it just below 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?

With readOnlyHint=true, the safety profile is already disclosed; the description adds the useful behavioral detail that future consolidations are returned. It does not disclose ordering, pagination, or return shape, which keeps it at an adequate but not rich level.

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 core guidance is one front-loaded sentence with useful context. The trailing 'norm.' is stray and unexplained, which prevents a perfect score, but there is no other waste.

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 single-parameter, read-only listing tool, the description covers what the tool returns, that future versions are included, and how to use the result (pick eli_version). It is complete enough for selection and invocation, though a short note on output items would make it fully robust.

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 input schema describes the single 'eli' parameter and schema description coverage is 100%, so the baseline applies. The description does not add extra detail about the ELI format or the relationship between a consolidation abstract and an act, but it also does not need to because the schema covers the 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?

The description uses a specific verb 'List' with a precise resource ('dated consolidation (Fassung) of an act') and explicitly notes future versions are included. It also ties the purpose to picking an eli_version for reading tools, which distinguishes it from related tools like fedlex.read_document or fedlex.list_expressions.

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 a clear usage context: use this before reading tools to select the eli_version. It does not name alternatives or state when not to use it, but the workflow guidance is explicit enough for most agents.

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 declare readOnlyHint=true, and the description does not contradict that. It adds useful behavioral context by describing the parsed output components and the tool's relationship to read_article, which goes beyond the annotation alone. It does not cover error handling or invalid input behavior, but the read-only safety profile lowers the burden.

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 compact and front-loads the core purpose, with a helpful usage pointer to read_article. The trailing 'hint.' adds no clear value and slightly weakens the otherwise clean structure.

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 single-parameter, read-only parser, the description sufficiently explains what input is expected and what kind of output is produced. With no output schema, naming the output components is important and done here. Minor gaps remain around exact output shape and invalid-citation behavior, but they are not blocking 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?

The schema already provides 100% coverage of the single 'text' parameter with concrete examples and a clear description. The tool description rephrases this as 'a citation' and 'quoted Fundstelle' but does not add meaningful semantic detail 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 names a specific action ('Parse'), a specific resource ('a citation'), and a concrete output ('act, article eId and path proposal'). It also distinguishes itself from the sibling read_article by describing how the parsed output feeds into that tool.

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 explicitly says to use it 'to turn a quoted Fundstelle into what read_article can open', giving a clear when-to-use scenario. It also names read_article as the downstream consumer, but it does not mention alternative tools or explicitly state when not to use this tool.

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?

The readOnlyHint annotation already covers the safety profile. The description adds that the tool targets a single element of a dated consolidation, which is useful scoping. It does not mention return format or failure behavior, so it adds modest value beyond the annotation.

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 short and front-loaded, quickly establishing the resource, addressing mechanism, and intended use. It loses a point for the awkward trailing 'norm. norm.' which reads like a typo and adds no value.

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 no output schema, the description covers what is read, how it is addressed, and why it is used, and the schema covers parameters completely. A note on the return representation would improve completeness, 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's eid examples slightly reinforce the schema's own examples but add no new semantic information about parameter formats or relationships.

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 ('Read'), a specific resource ('one element (Artikel, Absatz, Anhang)'), and a specific addressing mechanism ('by eId'), with concrete examples like art_6 and annex_u1/lvl_u1. This clearly distinguishes it from whole-document reads such as fedlex.read_document.

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 an explicit intended use—'use to quote a norm'—which tells an agent when to invoke this tool. It does not provide exclusions or name alternatives, but the use case is clear enough.

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 mark readOnlyHint=true; the description adds real behavioral detail: the result is capped Markdown, may carry a truncated flag, and supports continuation via offset. It does not contradict the 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 definition is compact and front-loads the core capability in one sentence. The awkward trailing fragment '. norm.' and the dense parenthetical slightly reduce readability but do not waste much space.

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 read-only tool with a fully documented parameter schema and no output schema, the description still conveys the key output behavior (Markdown, truncation, continuation) and usage boundary. Nothing essential for invoking 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% and each parameter already has precise meaning (language default, continuation via next_offset, character budget, dated eli_version). The description only lightly reinforces max_chars/offset behavior and adds no new parameter-level semantics, so 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?

States a specific action ('Read'), a bounded resource ('whole small act or Verordnung'), and an output shape ('capped Markdown'), and explicitly contrasts itself with read_article for quoting. The trailing 'norm.' is confusing but does not obscure the purpose.

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 condition—'use for short acts'—and names the alternative path for quoting ('quote via read_article'). This is enough for an agent to route between the two most relevant siblings without opening their schemas.

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?

The annotations already declare readOnlyHint=true, and the description does not contradict that. It adds useful context about selecting a Fassung for a past or future date, but it does not explain the return shape or behavior when no consolidation exists.

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 short and front-loaded with the action, but it is awkwardly phrased and ends with an incomplete 'norm.' artifact. It is concise but not cleanly structured.

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 two-parameter, read-only resolver, the description is usable and gives the intended workflow. However, with no output schema and no explanation of `eli` or edge cases like invalid dates, an agent may still need additional context to call it confidently.

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%, with `as_of` described but `eli` left undocumented. The description mentions ISO date but does not explain the required `eli` parameter, so it fails to compensate for the missing schema coverage.

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 operation ('Resolve which consolidation (Fassung) of an act') and identifies the key input condition (ISO date). It is clear enough to distinguish from generic read tools, but it does not explicitly contrast with siblings such as fedlex.list_versions or read_document, and the trailing 'norm.' is an artifact.

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 explicitly says when to use it: 'use before reading text for a past or future Stichtag.' This gives an agent a clear invocation context, though it does not name alternatives or exclusion conditions.

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, so the safety profile is covered. The description adds a small behavioral detail ('predecessors stay visible'), which is useful, but it does not explain failure modes, return format, or edge cases. With annotations present, this is adequate but not rich.

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 compact, front-loads the core purpose, and includes a usage trigger and an example. The trailing 'norm.' fragment is unclear and adds little value, preventing a perfect score, but overall the description is efficiently written.

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 single-parameter read-only tool with no output schema, the description covers the key outputs (ELI, titles, in-force status) and gives a usage condition. It is reasonably complete for an agent to decide whether to use it, though the meaning of 'norm.' and the exact response structure remain slightly underspecified.

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 single required parameter 'sr' is already documented with the same example (832.10). The description adds meaning about what the resolution returns, but not significantly more about the parameter itself, so the baseline score 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?

The description uses a specific verb ('Resolve') with a clear resource (SR number) and the main outputs (ELI, titles, in-force status), backed by a concrete example. It does not explicitly differentiate itself from closely related siblings like resolve_consolidation_at or parse_reference, but the purpose is unambiguous.

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 gives an explicit trigger condition: 'use when a question names an SR'. This is clear context for when to invoke the tool. It does not provide exclusions or name alternatives, but the stated use case is sufficient for basic selection.

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, so the safety profile is covered. The description adds the decoding-use context and the label-or-IRI lookup modes, but does not describe return behavior or edge cases. This is adequate but not rich.

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 one focused sentence and is front-loaded with the key purpose. The trailing 'hint.' appears to be a leftover artifact and adds no value, keeping it from a perfect score.

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 lookup tool with fully described parameters and a read-only annotation, the description covers what the tool is for, how it is invoked conceptually, and when it should be used. No critical information 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 parameters are fully documented there. The description adds value by clarifying the intended query style ('by label or IRI') and giving concrete vocabulary examples, going slightly 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?

States a specific verb ('look up'), a specific resource ('Fedlex vocabulary term'), and the method ('by label or IRI'). It also gives concrete vocabulary examples, which clearly separates it from document-reading and search 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?

Provides a clear use case: decode a coded value from another answer. It does not explicitly name alternatives such as lindas.resolve_label or state when not to use it, but the intended context is clear enough for an agent.

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?

The readOnlyHint annotation already covers the safety profile, so the description only needs to add behavioral context beyond that. It adds one useful behavioral detail: in-force acts rank first. It does not disclose result format, pagination, or matching edge cases, earning a solid mid-range score.

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 core sentence is compact, front-loaded, and informative, covering purpose, usage, and ranking behavior efficiently. The trailing standalone word 'hint.' is unexplained noise that slightly reduces clarity and costs the description a higher score.

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 two-parameter read-only search tool, the description is mostly complete: it states the input semantics, the intended use case, and a relevant ranking behavior. Without an output schema, a little more detail about the result shape would be useful, but an agent can confidently call this tool as described.

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 0% schema description coverage, the description must document the query parameter, and it does: it explains that query accepts title keywords or official abbreviations and gives examples. However, the optional 'limit' parameter is never mentioned, so one of the two parameters remains underdocumented.

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 uses a specific verb ('Search') and resource ('acts'), and clarifies that it searches by title keyword or official abbreviation, with concrete examples. This meaningfully distinguishes it from other fedlex tools by describing exactly what kind of lookup it performs.

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 gives an explicit 'use when you know the name but not the SR or ELI' condition, which helps an agent decide when to invoke the tool. However, it does not explicitly name alternatives or say when not to use this tool, so it is just short of full routing 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?

The readOnlyHint annotation already covers the safety profile, lowering the bar. The description adds useful behavioral context by stating that hits contain eId and Artikel, which is essential for chaining into read_article. It does not discuss pagination or auth, but those are less critical given the annotation.

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 commendably short and front-loaded with the core action and purpose, followed by a clear usage pointer. However, the trailing lone word 'hint.' is unexplained and introduces minor ambiguity, preventing a perfect score.

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 read-only search tool with no output schema, the description covers what is searched, what hits contain, and the intended workflow (preceding read_article). Required inputs are documented in the schema, and the only omissions are minor details like pagination behavior, which the schema already addresses through the limit parameter.

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 all four parameters (lang, limit, query, eli_version) are fully documented in the schema. The tool description adds no parameter-level details beyond what the schema already provides, so it remains at the 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 states a specific verb ('Find where a word occurs') on a bounded resource ('inside ONE consolidation') and clarifies the output ('hits with eId and Artikel'). It also distinguishes this tool from sibling read_article by explicitly naming it, making the tool's role unmistakable.

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 gives direct, actionable routing: 'use before read_article when the article is unknown.' The 'ONE consolidation' qualifier further signals that this tool is not for cross-law search, effectively excluding that 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?

The readOnlyHint annotation already indicates a non-destructive operation. The description adds context about distinguishing 'no data' from 'source down' and about using it before retries, which clarifies expected behavior beyond the annotation.

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 short but contains awkward phrasing and an unexplained trailing 'norm.' that seems out of place. The core idea is conveyed, but the structure could be cleaner and more professional.

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 having no output schema, the description provides enough context for an agent to know when and why to invoke the tool: check availability, distinguish no-data from source-down, and use before retrying failed calls. It is sufficient for a simple health-check endpoint.

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 are no parameters, and the schema coverage is complete by default. With zero parameters, there is nothing additional the description could meaningfully add about inputs, so the baseline score of 4 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 clearly states the tool checks whether the I14Y catalogue answers, which identifies it as a health/availability check. It also distinguishes between 'no data' and 'source down' conditions, giving it a specific purpose beyond a generic status check. The wording is somewhat awkward but the core function is identifiable.

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 explicitly advises using this tool 'before retrying a failed call', which gives a clear usage condition. It does not name alternative tools, but the guidance is actionable and contextually relevant for a status-check tool.

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?

The readOnlyHint annotation already establishes that the tool performs a safe read. The description adds useful behavioral detail by naming the fields shown and the preparatory role before reading entries. However, it does not disclose other behavioral aspects such as language handling or error conditions; the trailing 'norm.' is cryptic and unexplained.

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 a single, front-loaded sentence that states the purpose and usage in a compact way. The 'norm.' fragment at the end is unclear and slightly detracts from the otherwise efficient structure.

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 fetch-by-ID tool with no output schema, the description covers the primary purpose and the trigger condition. But it omits any detail about the lang parameter's effect on the returned record, and the meaning of 'norm.' is ambiguous. An agent can invoke it correctly using the schema for concept_id, but the undefined lang behavior leaves a 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 coverage is only 50%: concept_id has a description referencing i14y.list_concepts, but lang has no description. The tool description does not clarify the lang parameter at all, and the field list it provides describes the output, not the parameters. It therefore fails to compensate for the undocumented optional 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?

The description states a specific verb ('Show'), a resource ('one concept's record'), and enumerates the returned fields ('type, value type, version, validity'). This clearly distinguishes it from i14y.list_concepts, which lists many concepts, and i14y.search_codelist_entries, which searches entries.

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 explicitly instructs when to use the tool: 'use before reading a code list's entries.' This gives clear contextual guidance for invocation, though it does not name alternatives or state when not to use the tool. The sibling list_concepts is implicitly the counterpart for discovery.

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?

With `readOnlyHint: true` already indicating a safe read operation, the description adds useful behavioral context by listing the record's contents and stating that the result is meant for reaching the service. It does not cover response shape or authentication, but it is consistent with the annotation and provides value beyond it.

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 short and front-loaded with the core action and return contents. However, the trailing 'norm.' is confusing noise and the phrasing 'use to reach the service' is grammatically awkward, so the structure is acceptable but not polished.

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 get-by-id tool, the description plus annotation covers the main information: what is returned and that the operation is safe. The lack of an output schema, the unexplained `lang` parameter, and the odd 'norm.' fragment leave some ambiguity, so it is not fully complete.

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 schema usefully documents `data_service_id` as the id from `i14y.list_data_services`, but schema description coverage is only 50% and the optional `lang` parameter has no description. The tool description adds nothing about parameters, leaving `lang`'s meaning and format ambiguous.

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 uses a specific verb ('Show') and a singular resource ('one registered interface's record'), and it enumerates what the record contains: endpoints, OpenAPI links, licence, and served datasets. This makes clear it is a single-record lookup rather than a list operation, though it never explicitly names sibling tools and uses 'interface' instead of the tool's 'data_service' term.

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 phrase 'use to reach the service' gives a general use case, and the schema's description of `data_service_id` as coming from `i14y.list_data_services` implies a lookup sequence. However, the description does not explicitly state when not to use this tool or how it compares to alternatives, so the usage guidance remains more implied than explicit.

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, so the safety profile is covered. The description adds useful scope detail about the full record and distribution licensing, but does not disclose behavior like output size, pagination, or error cases. This is adequate but not rich.

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 compact and front-loaded with the core purpose. The trailing 'norm.' is an unnecessary artifact that adds no value, slightly reducing structural quality.

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 get-by-id read tool, the description conveys what the tool returns and when to use it. It is missing any explanation of the lang parameter, but the overall call is straightforward and the output schema absence is mitigated by the explicit field enumeration.

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 50%: dataset_id is well documented in the schema, but lang has no schema description and the tool description does not mention lang at all. The description adds no parameter-level meaning to compensate for the undocumented optional 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?

The description uses a specific verb and resource: 'Show one dataset's full record', and enumerates the contents (contact, coverage, every distribution with licence and download address). This clearly distinguishes it from listing/search siblings and from the narrower get_dataset_distributions.

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 phrase 'use before reuse' gives clear contextual guidance on when to call this tool. It does not explicitly name alternatives or exclusions, but the intended use case is evident.

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, so the read-only nature is known. The description adds value by specifying the returned fields (format, licence, download and access address), which goes beyond the annotation. It does not contradict annotations and adds useful behavioral context about the output content.

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 a single concise sentence, front-loading the action and output. The trailing 'norm.' is cryptic and adds no value, but it does not detract much from overall efficiency. It is appropriately sized with minimal waste.

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 no output schema, the description should explain return structure. It lists some returned attributes but omits details like whether results are paginated or how the lang parameter affects the response. It is adequate for a simple listing tool, but lacks explanation of the optional parameter and exact output shape.

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% (only dataset_id is described). The description does not mention either parameter, leaving the optional 'lang' parameter entirely unexplained. With moderate coverage, the description should compensate for missing parameter details, but it does not. This is a clear gap.

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 action ('List a dataset's distributions') and specifies the content (format, licence, download and access address). It also gives a concrete use case ('where do I get the data'). While it does not explicitly contrast with sibling tools, the verb and resource are distinct and unambiguous.

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 provides a clear contextual trigger: 'use for «where do I get the data»'. This guides the agent on when to invoke the tool. It does not mention alternatives or exclusion criteria, but the use case is specific enough to differentiate from other i14y tools like i14y.get_dataset.

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?

The readOnlyHint annotation already covers the main behavioral trait, so the description does not need to restate it. The description offers no additional behavioral detail, but there is no contradiction with the annotation.

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 short and front-loaded with the main verb and object, but it includes unclear and extraneous content such as 'each one body's collection', the parenthetical examples, and the stray 'norm.', which reduce clarity and polish.

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 listing tool with no output schema, the description gives the basic idea but leaves important context unaddressed: it does not clarify what the returned catalogues look like, how pagination works, what the language parameter affects, or the relationship to publishers/contributors.

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 33% (only 'limit' is described), and the description does not explain 'lang' or 'page' beyond their names. Since lang/page meaning is not fully obvious and no compensation is provided, the description adds little value over 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 uses the specific verb 'List' with the resource 'catalogues' and adds context that they 'feed I14Y', which distinguishes it from closely related i14y list tools such as list_datasets and list_public_services. However, the phrase 'each one body's collection' and the parenthetical examples are slightly fuzzy.

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 a vague use case ('use to see who contributes') but provides no explicit guidance on when to use this tool versus related list/search tools, and no pagination or parameter usage guidance. The trailing 'norm.' appears to be leftover text and adds no usable direction.

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?

The readOnlyHint annotation already indicates a safe read operation, and the description adds no contradictory side effects. It provides no additional behavioral detail beyond listing/finding, but no side-effect disclosure is required here.

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 text is short and front-loaded with the main verb, but the parenthetical '(Konzept, Codeliste, Nomenklatur, Merkmal)' and the dangling 'norm.' do not earn their place and could confuse readers.

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 no output schema and five parameters, the description is too thin: it does not describe what entries the list contains, how pagination works, what registration_status means, or how this relates to get_concept/search_codelist_entries.

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 0% schema description coverage and five parameters, the description must compensate, but it only hints at the 'publisher' parameter. lang, page, limit, and registration_status are left unexplained, and registration_status in particular is not self-explanatory.

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 starts with a specific verb and resource ('List ... harmonised concepts and code lists') and adds a concrete use case ('find a code list by publisher'). However, the parenthetical synonyms and trailing 'norm.' add noise, and it does not fully distinguish from i14y.get_concept or i14y.search_codelist_entries.

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 one explicit use case ('use to find a code list by publisher'), but it does not state when not to use it, mention pagination/registration_status filtering, or point to sibling tools like i14y.search_codelist_entries as alternatives.

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 mark readOnlyHint=true, so the safe, read-only nature is covered. The description adds that the tool returns registered endpoints and is meant for pre-scraper discovery, but it does not disclose pagination, filtering behavior, or output shape. It does not contradict the 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 main clause is concise and front-loaded, stating the action and resource immediately. However, the trailing 'norm.' is a meaningless fragment that violates the standard that every sentence earns its place, and no parameter or return guidance is included.

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 six undocumented parameters, no output schema, and no description of the return format, the tool is under-specified for confident invocation. The usage cue 'use before building a scraper' helps but does not explain how to use the filters or interpret the response. More description is needed to make it complete.

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%, and the description mentions none of the six parameters (lang, page, limit, publisher, access_rights, registration_status). The description does nothing to compensate for the schema's silence, leaving agents to guess the meaning and expected formats of the filters.

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 clear action (List) and a specific resource: registered machine interfaces of Swiss public bodies with their endpoints. The parenthetical '(API, Schnittstelle, Datendienst)' clarifies what counts as a machine interface, and the phrase 'use before building a scraper' reinforces its discovery role. It does not explicitly name sibling alternatives, so differentiation relies mostly on the 'machine interfaces' wording.

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 instruction 'use before building a scraper' provides concrete when-to-use guidance. However, it does not state when not to use this tool or mention relevant alternatives such as i14y.get_data_service or i14y.search_catalog. It is clear context without exclusions.

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?

The description implies a read-only operation ('list the registered datasets') and the readOnlyHint annotation is present. It does not contradict the annotation. The tool description itself lacks explicit side-effect details, but the annotation covers the main concern, so a slightly above baseline score is warranted.

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 contains irrelevant fragments: 'Datensätze, Metadaten, Open Data' in parentheses and a trailing 'norm.' that do not aid understanding. The core sentence is clear, but the extraneous words make it less concise and visually cluttered.

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?

The description covers the main purpose and mentions pagination, but there is no output schema and no details about response structure, sorting, or error conditions. Given the moderate complexity (filtering and pagination), the description is sufficient but not complete. The extra clutter further reduces clarity, though the core information is present.

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 schema descriptions fully cover all six parameters with 100% coverage, and the tool description does not add meaningful semantic detail beyond that. The phrase 'with publisher, themes and access right' loosely mirrors the parameter list but adds no new information. 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?

The description clearly states the tool lists registered datasets with pagination and filter fields (publisher, themes, access right). It also gives a use case ('use for a census or a publisher's list'), though it does not explicitly differentiate from sibling search functions like search_catalog.

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 provides a loose usage suggestion ('use for a census or a publisher's list') but does not explicitly say when to avoid this tool or contrast it with alternatives such as get_dataset or search_catalog. The stray word 'norm.' adds noise rather than 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?

The annotations already declare readOnlyHint=true, so the safety profile is established. The description adds that the list contains registered public services and their channels, which is useful, but it does not disclose return shape, pagination behavior, or default limits. Given the read-only annotation, a 3 is appropriate.

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 core guidance is compact and front-loaded: it states the action, resource, and use case in one efficient sentence. The trailing 'norm.' and the German parenthetical add minor noise, but the main content is concise and well ordered.

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 read-only list operation with all optional parameters, the tool is minimally callable with no arguments, so the description is usable. However, there is no output schema, no return-shape description, and no guidance on pagination defaults or filter semantics, leaving meaningful gaps for an agent deciding how to refine a call.

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%, and the description provides no additional meaning for lang, page, limit, publisher, or registration_status. The parameter names are somewhat self-explanatory, but important values such as allowed registration_status values or publisher format are left undocumented. With low schema coverage, the description should compensate, and it does not.

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 identifies a specific resource ('registered public services') and adds the categories Behördenleistung, Dienstleistung, Verwaltung, which clarifies what kind of objects are listed. It also states the intended use case ('what an authority offers citizens'). It does not explicitly differentiate from sibling tools like i14y.list_data_services, but the resource scope is specific enough to avoid major ambiguity.

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 provides a clear usage context: 'use for what an authority offers citizens,' which helps an agent decide when this tool fits. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for a basic routing decision among the i14y sibling tools.

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?

The readOnlyHint=true annotation already covers the safety profile, so the bar is lower. The description adds some useful context — the result contains identifiers and Swiss UIDs — but discloses nothing about pagination behavior, sorting, or whether the list is exhaustive. It does not contradict the read-only annotation, and the added context is modest rather than rich.

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 brief and front-loaded with the core verb+resource, and it packs purpose, output shape, and use case into one sentence. However, the trailing 'norm.' is a confusing artifact that should have been removed — every token should earn its place, and this one detracts from an otherwise tight definition.

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 list tool with five optional parameters and no output schema, the description covers the essentials: what is listed, what the output contains (identifier and Swiss UID), and the motivating use case. Pagination behavior and the lang parameter are not addressed, but they are minor for a tool of this complexity and partly inferable from the schema.

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 60%, leaving lang and page entirely undocumented in both schema and description. The description adds purpose-level context that indirectly explains why one would pass an identifier ('find a publisher's code for a filter'), and the schema already documents uid, limit, and identifier well. It does not meaningfully compensate for the lang/page gaps, so a mid-range score 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 opens with a specific verb and resource — 'List the bodies that publish into I14Y' — and names the key output fields (identifier and Swiss UID). The parenthetical German terms ('Herausgeber, Bundesamt, Kanton, UID') clarify what a 'publisher' is, and the use case ('find a publisher's code for a filter') helps distinguish it from sibling list tools like list_datasets or list_catalogs. It loses the top score only because of the stray trailing fragment 'norm.', which reads as a truncated or garbled word.

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 explicitly states when to use the tool: 'use to find a publisher's code for a filter.' This is clear context that an agent can act on, and the tool name plus the use case implicitly separate it from the other i14y.list_* siblings. However, it does not name alternatives or give when-not-to-use guidance, so it stops 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 mark the tool as read-only, so the description does not need to repeat that. It adds useful behavioral context beyond the schema by indicating that the tool returns publisher information ('who publishes what') and supports word-based search. No contradictions with 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 description is short and front-loaded with the key action, resource, and usage guidance. The trailing 'hint.' adds minimal noise but does not significantly harm clarity.

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 a fully described schema, a read-only annotation, and no output schema, the description provides enough purpose and usage context to call the tool correctly. It conveys the tool's role in finding publishers, which is the key contextual missing piece.

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 fully documents all seven parameters. The description does not add parameter-level details, but it reinforces the core 'by words' search behavior. This meets the baseline expectation of 3.

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 clearly states a specific verb ('Search'), a concrete resource ('the national data catalogue I14Y'), and the intent ('to find who publishes what'). It also distinguishes itself from sibling listing tools by emphasizing free-text search by words.

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 explicitly says to 'use first' for finding who publishes what, giving clear contextual guidance. It does not explicitly name alternatives or exclusion conditions, but the intended usage is unambiguous enough for an agent to select it appropriately.

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?

The description is consistent with the readOnlyHint=true annotation ('List' matches a read-only operation), and adds useful context: results are paged and include names and validity. However, it does not explain the parenthetical categories or the meaning of 'norm.', and it does not disclose behavior like matching semantics beyond what the schema already states. No contradiction with 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 main clause is front-loaded and efficient ('List the codes of one code-list concept, paged, with names and validity'), which is good. But the parenthetical list and trailing 'norm.' are unexplained noise that could confuse agents, and the description does not follow the conventional shape of stating purpose then usage conditions cleanly.

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 explaining return values, and it does partially ('with names and validity'). However, it leaves two ambiguities unresolved: the meaning of the parenthetical terms and 'norm.', and it does not mention the concept_id prerequisite (that the caller must first have a CodeList concept id from a lookup tool). Moderately complete but with real gaps.

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 80% (4 of 5 params documented), so the baseline is 3. The description adds marginal value by noting the tool is 'paged' (mapping to page/limit) and that results carry 'names and validity', but it adds no syntax, defaults, or format detail beyond the schema. The unexplained parenthetical does not clarify any 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?

The description uses a specific verb+resource pair ('List the codes of one code-list concept') and states a concrete purpose ('use to resolve official codes'), which distinguishes it from sibling i14y.list_concepts (listing concepts vs. entries within one concept). However, the parenthetical '(Code, Codeliste, Kanton, Geschlecht, Nomenklatur)' is unexplained and the trailing 'norm.' is an unclear artifact that slightly muddies an otherwise clear statement.

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 phrase 'use to resolve official codes' implies a use case and gives some contextual guidance. But it does not explicitly state when not to use this tool, nor does it name any alternative among the many siblings (e.g., i14y.list_concepts for finding concepts before resolving their codes). The guidance is implied rather than explicit.

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 declare readOnlyHint=true and the verb 'Show' is consistent with a read operation, so there is no contradiction. The description adds scoping context (single IRI, which entity kinds are addressable) but discloses nothing about result size, pagination, or other behavior of the 'everything' dump. With the safety profile already carried by annotations, the description meets the lower bar but adds only modest behavioral context.

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 that packs in the operation, scope, use case, and examples with no wasted prose. The trailing 'norm.' is unexplained noise that should be removed or translated, which keeps this from a 5.

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?

Adequate for a simple read tool with a readOnly annotation and one required parameter, covering what it does and when to use it. However, with no output schema present, the description should hint at the return shape, and the relationship to the near-identically named sibling lindas.describe_cube is left unclarified.

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 25%; lang, limit, and offset are undocumented in both the schema and the tool description. The entity examples (cube, observation, Kanton) add meaning to the required iri parameter beyond the schema's generic 'Any IRI,' and the schema's note that no host is fetched is helpful, but the description does not compensate for the three undocumented parameters.

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 ('Show everything the holding says about one IRI') with concrete entity examples (cube, observation, Kanton), giving an agent a clear picture of what the tool does. The phrase 'use to follow an address you were handed' signals a lookup-by-IRI operation, implicitly distinct from search/list siblings like lindas.find_cube or lindas.list_cubes. It does not explicitly name a sibling to differentiate from, and the trailing 'norm.' adds noise.

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 when-to-use guidance: follow an address (IRI) you were handed, i.e., when you already hold the identifier. This implies the alternative — search or list tools when you lack the IRI — without naming them or stating exclusions, so the guidance is clear but not exhaustive.

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?

The readOnlyHint annotation already communicates that this is a safe read; the description adds that it shows declared dimensions/profile and that the record may carry more fields, which is useful partial-output context. It does not discuss pagination/localization behavior of lang/limit/offset, but for a read-only metadata tool the annotation lowers the burden.

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 short and mostly front-loaded, but the trailing 'hint.' fragment and the ambiguous clause 'the record may carry more' create structural confusion. It would earn a higher score with a cleaner two-sentence format.

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 read-only metadata tool, the description conveys the core purpose and a practical use case, and readOnlyHint covers side-effect concerns. However, with no output schema and three undocumented optional parameters, the description leaves an agent to guess how lang/limit/offset affect the call and what the response contains beyond 'declared dimensions and profile.'

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 25%, and the description does not compensate: lang, limit, and offset are left with no explanation beyond their field names. The cube parameter is covered by the schema example, and 'dimensions and profile' hints at what is read, but most parameters remain semantically undocumented.

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 specific action and object: 'Show a cube's declared dimensions and profile.' It also indicates the purpose ('use to learn the filters a question needs'), which clarifies what the output is for. It does not explicitly differentiate from sibling lindas tools, but the 'declared dimensions and profile' wording is distinct enough to identify the tool's resource and intent.

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?

'use to learn the filters a question needs' is a clear usage signal: call this when you need to discover required cube filters. It does not name alternatives or give when-not-to-use conditions, but the guidance is explicit rather than merely implied.

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?

The readOnlyHint annotation already signals this is a safe read operation, and the description confirms it lists values. It adds useful context about the IRI-filtering purpose, but it does not describe pagination, language handling, or the shape of the returned values.

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 a single focused sentence with useful examples and a clear usage hint. The trailing 'hint.' adds little value, but overall there is no waste or excessive length.

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 and sparse parameter documentation, the description carries a heavy burden. It clarifies the core use case but omits return value details, cube parameter meaning, and limit/language behavior, making it incomplete for reliable 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 only 25%, with only the 'dimension' parameter documented. The description mentions IRI-based filtering but does not explain the required 'cube' parameter, the optional 'lang', or 'limit' semantics, leaving agents to guess at critical inputs.

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 clear verb and resource: 'List the values one dimension takes', reinforced by concrete examples (Kantone, Abstimmungstypen, Geschäftsstände). It also signals the tool's specific purpose, filtering by IRI rather than text, which distinguishes it from related lookup 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?

The description gives an explicit usage directive: 'use to filter by IRI instead of by text.' This tells an agent when the tool is appropriate, though it does not explicitly name sibling alternatives or state when not to use it.

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?

The readOnlyHint annotation already communicates that this is a safe read operation, and the description adds useful workflow context ('use before reading rows'). However, it does not disclose matching behavior, whether the search is exact or partial, or what the result looks like. This is acceptable but not deeply transparent.

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 very short and front-loads the core purpose in one sentence. The trailing 'hint.' adds little value and reads as noise, but otherwise every part of the sentence contributes to understanding the tool's role.

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?

The core usage is clear enough for a basic call: provide a word of the cube's name. However, there is no output schema and the description does not say what is returned or how the result feeds into later row-reading steps. The phrase 'behind a question' is also slightly ambiguous, and the optional parameters remain unexplained.

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 33%, so the description needs to compensate for the undocumented lang and limit parameters, but it does not. It re-emphasizes that query is a word of the cube's name, which the schema already states, and adds no meaning for limit or lang.

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 action — find the relevant cube — using a word of the cube's name, and immediately distinguishes this lookup from row-reading tools. The examples («Volksinitiative», «Petition», «Parteienregister») make the target resource and usage concrete. It clearly positions itself within the lindas family as a discovery step, not a data-access step.

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 phrase 'use before reading rows' gives explicit workflow guidance about when this tool should be called. It doesn't explicitly name alternative tools such as lindas.list_cubes or lindas.describe_cube, but the timing instruction provides strong contextual direction.

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?

The readOnlyHint annotation already covers safety. The description adds that the tool lists a fixed set of 44 cubes, which is useful, but the trailing 'norm.' is cryptic and does not clearly disclose behavior to an agent. No contradiction with 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 description is short and front-loaded with the core action. The only flaw is the unexplained 'norm.', which adds noise without conveying useful information.

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 read-only list tool with no required parameters, the description covers the primary purpose. However, limit/offset behavior and the meaning of 'norm.' are left undefined, so an agent may not fully understand the tool's edge behavior from this description alone.

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 50%: lang and family are documented in the schema, but limit and offset are not, and the tool description does not compensate for them. It adds no meaning to any parameter, leaving half the parameter surface under-described.

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: 'List the 44 political data cubes of the Confederation', and names concrete categories. This clearly distinguishes it from siblings like lindas.observations or lindas.describe_cube, which act on cubes rather than enumerate them.

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 phrase 'use to see what data exists' gives a clear usage context. However, it does not explicitly mention alternatives or when-not-to-use it, so it stops short of full routing 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?

With readOnlyHint=true already covering safety, the description adds useful behavioral context: versions are not linked from old to new, so an agent must list them explicitly before reading a specific year. This is a meaningful non-obvious trait beyond what the annotation alone conveys. No contradictions with annotations are present.

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 short and front-loaded with the core purpose, which is good. However, the trailing 'norm.' appears to be an unexplained fragment or stray token that does not contribute meaning and should be removed, preventing a higher score.

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?

The tool is simple with one required parameter, and the description covers the key operational context: list versions before reading a year because versions are not linked. There is no output schema, but 'List the versions' reasonably implies the return value, and the description otherwise gives enough context 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%, and the schema already provides a clear example for the 'cube' parameter. The description mentions the cube family years but does not add additional parameter semantics beyond what the schema already documents, so a baseline score 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 uses a specific verb ('List') and identifies the exact resource: versions of a cube family, with Nationalratswahl 2019/2023/2027 as examples. It also clarifies that this operation is a precursor to reading a year, which helps distinguish it from a direct read operation, though it does not explicitly name sibling alternatives.

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 explicitly says 'use before reading a year,' giving an actionable instruction about when to invoke this tool. The clause 'nothing links old to new' explains why listing versions is necessary, but it does not mention when not to use it or point to alternative sibling tools for comparison.

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 declare readOnlyHint=true and the description's 'Read' is consistent, so no contradiction. The description adds that filtering is possible and names relevant dimensions, but does not disclose pagination, response shape, or any other behavioral details; the annotation carries most of the safety profile.

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?

Very short, but the trailing 'norm.' and the phrase 'the figures themselves' are cryptic and under-specified. It is concise in length, but not clearly structured or self-explanatory.

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 six parameters and no output schema, this is a non-trivial tool, yet the description says nothing about cube selection, language, limit behavior, or row shape. It lacks the richness needed 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 only 33% — cube, lang, limit, and offset are undocumented in the schema. The description names a few filter dimensions but omits all other parameters entirely, so it fails to compensate for the coverage gap.

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 clear verb ('Read') and resource ('a cube's rows'), with a list of filter dimensions that hint at the vote-cube domain. It doesn't explicitly contrast with sibling tools like lindas.dimension_values, so it's clear but not sharply differentiated.

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 phrase 'use for the figures themselves' gives some situational context, but no exclusions or alternatives are named (e.g., when to prefer lindas.dimension_values). Guidance is implied rather than explicit.

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?

The readOnlyHint annotation already covers safety; the description adds useful behavior by noting single-language resolution with fallback and limiting the label set to Kanton, Partei, Gremium, Interessenbindung. However, it does not explain the fallback order, output shape, or failure behavior, which is notable without an output 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?

The core sentence is compact and front-loaded, but the trailing 'hint.' is a stray, unexplained fragment that adds noise rather than instruction. The colon-plus-fragments structure makes the definition feel unfinished.

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 moderately simple tool with no output schema, the description gives the main purpose but omits the language identifier format, fallback behavior, and return contract. It also leaves the parenthetical entity list's scope ambiguous relative to the schema's claim that the IRI can be any host.

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 iri parameter is well-documented in the schema, but lang has no schema description; the description's 'one language with a fallback' partially clarifies that lang is the target language and that a fallback occurs. It stops short of giving language codes or explaining the null case, so it only partially compensates for the schema's coverage gap.

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 operation—resolving an IRI to its label—and adds key qualifiers (one language, fallback, specific entity categories) that go beyond the tool name. This is enough to distinguish it from siblings like lindas.describe, which describe resources more broadly.

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?

'use to name a value' is an explicit intended-use instruction: call this when a display label for an IRI is needed. It does not state exclusions or name alternatives, so it falls short of a 5, but the guidance is clear and contextually appropriate.

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?

With readOnlyHint already provided, the description adds meaningful behavioral context: an unknown slug results in a not-found error carrying the E21 admission rule. It does not discuss return format or response details, but for a read-only single-entry lookup this is reasonable.

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 brief sentences carry all the essential information: the operation and key in the first, the error case in the second. There is no filler or redundant restatement of schema or annotation content.

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 tool with one required parameter, a read-only annotation, and no output schema, the description covers the lookup criterion and the expected failure mode. A definition of what a 'manifest' contains would be helpful, but it is not essential 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?

The input schema provides 100% coverage for the sole slug parameter, including its meaning as the entry slug tied to filename/@id and oh-validate enforcement. The description's 'by slug' adds no further semantic detail, 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 specific verb+resource pair: getting 'one entry's manifest' by slug. The 'one entry's' qualifier helps distinguish it from broader tools like directory.get, though it does not explicitly name alternatives.

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 intended use is clear: provide a slug to retrieve that entry's manifest. However, there is no explicit guidance about when not to use this tool or which sibling tool might be more appropriate for directory-level or collection-level lookups.

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