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?

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?

Read-only annotation already covers the safety profile, and the description adds a useful behavioral hint that the returned record 'may carry more' than the declared dimensions. Still, it says nothing about pagination, error behavior, or language handling, leaving gaps not covered by 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 brief and mostly front-loaded, which is good, but the cryptic trailing 'norm.' adds confusion rather than value. It is terse to the point of under-specification.

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 four parameters, no output schema, and multiple sibling tools, the description omits return shape, parameter roles, and any relationship to similar tools. It only offers a minimal use-case sentence, which is not enough for an agent to invoke it confidently in all expected scenarios.

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 'cube' documented. The description does not explain 'lang', 'limit', or 'offset', and the mention of 'filters' doesn't map clearly to these parameters. It fails to compensate for the sparse 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 a specific verb ('Show') and resource ('cube'), and names the content ('declared dimensions and profile'). It conveys the core function clearly, though it doesn't explicitly differentiate from the similarly named sibling lindas.describe.

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 practical use case ('use to learn the filters a question needs'), which implies context for when to call it. However, it doesn't mention alternatives or state when not to use this tool, so the guidance remains somewhat implicit.

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?

The description's 'Read' is consistent with the readOnlyHint annotation and implies no side effects. It does not add further behavioral details such as pagination, error behavior, or authentication requirements, but none contradict 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 mostly to the point, but the parenthetical filter list and the stray 'norm.' are awkward and reduce clarity. A cleaner sentence separating examples from the core instruction would improve 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 read operation, the description plus schema gives enough context to attempt a call, but it is missing details about the shape of returned rows, default limits, and how filters combine. The lack of an output schema or return description leaves some ambiguity.

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 describes filters and dimensions, but cube, lang, limit, and offset are undocumented in the schema, and the tool description only lists example filter dimensions without explaining the required cube parameter or the pagination/language parameters. With only 33% schema description coverage, the description does not sufficiently compensate.

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 ('Read') and object ('a cube's rows'), and indicates it returns observation figures. The parenthetical filter examples and trailing 'norm.' add noise but do 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 phrase 'use for the figures themselves' gives some implied guidance that this tool returns observation data rather than metadata, but it does not explicitly compare with sibling tools such as lindas.describe_cube or lindas.dimension_values, nor 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 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?

The readOnlyHint annotation already establishes the read-only nature. The description adds meaningful behavioral context beyond annotations: missing entries produce a not-found error carrying the E21 admission rule. This is useful, though the E21 rule itself is unexplained and success behavior is not described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loads the core function in the first sentence. The second sentence adds a specific error behavior without redundancy. The phrasing is slightly awkward ('While no entries exist') and 'E21 admission rule' is cryptic, but overall it is compact and efficient.

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 tool, the description is mostly adequate. However, there is no output schema and the description does not explain what a manifest contains or what the successful response looks like. Terms like 'manifest' and 'E21 admission rule' are domain-specific and left unexplained, which could hinder 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%, and the slug parameter is already documented in the schema as 'Entry slug (filename = @id slug, oh-validate-enforced)'. The description adds little beyond confirming the manifest is accessed by slug, so it does not go beyond the schema 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 the operation clearly: retrieve one entry's manifest by slug. It does not use an explicit verb, but the tool name 'manifest.get' plus 'by slug' conveys the action. It narrows scope with 'one entry', though it does not explicitly distinguish itself from sibling 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?

There is no explicit guidance on when to use this tool versus alternatives. The description implies the caller should use it when they have a slug and want a manifest, but it names no sibling alternatives or exclusion conditions. The not-found behavior is mentioned, but not as usage 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 establishes the safe read-only nature. The description adds value beyond that by explaining that the returned capability IDs correspond to tool names on this server and that coverage is per-client, which helps an agent interpret results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire description is a single concise sentence that front-loads the core concept and adds one clarifying clause about capability IDs. Every part of the sentence contributes meaningful 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 simple, read-only, no-parameter meta endpoint, the description is adequate: it explains the resource, the per-client scope, and how capability IDs relate to tool names. It stops short of detailing the exact response shape, but the lack of an output schema and the low complexity make this 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?

The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add about parameters. The baseline for a no-parameter tool is 4, and the description appropriately says nothing misleading about arguments.

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 platform capability register with per-client coverage, and clarifies that tool names on the server serve as capability IDs. This provides a clear resource and distinguishes it from sibling meta-tools like meta.schemas and meta.tools, though it lacks an explicit verb like 'list' or '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?

The description implies that this tool is used to discover published capabilities and their per-client coverage, which is useful context. It does not explicitly state when to prefer this over meta.tools or meta.schemas, but the naming and emphasis on 'capability ids' give reasonable situational clarity.

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 useful behavior beyond annotations: schemas are byte-identical to tools/list, and unknown ids are refused by name rather than silently dropped. These are concrete, agent-relevant behavioral guarantees.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, with the core purpose front-loaded and no filler. The consistency guarantee and error behavior each earn their place in the second sentence.

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 discovery tool with one well-documented parameter, the description covers the workflow position, return content, consistency property, and error handling. Nothing essential is missing 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 already documents the single `names` parameter with 100% coverage, including that these are capability ids from stage one. The description reinforces 'named tools' but does not add significant new parameter-level meaning.

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 the exact action and resource: returning the full input schemas for named tools. Positioning it as 'stage two of two-stage discovery' immediately distinguishes it from stage-one listing tools, so an agent can tell what it is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly says this is the second stage of discovery, implying it should be used after a stage-one listing. It does not explicitly name an alternative tool to use instead, but the stage framing and schema requirement make the intended context clear.

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

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

Beyond the readOnlyHint annotation, the description discloses that the tool returns no input schemas, which is a key behavioral constraint that prevents the agent from expecting full tool details. It also explains the context-economy rationale, adding useful context 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 compact and front-loaded with the most important information: this is stage one of two-stage discovery. The rationale sentence about context economy is slightly philosophical but still earns its place by explaining why the tool deliberately omits schemas. No redundancy.

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

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

For a zero-parameter discovery tool with no output schema, the description is complete: it explains what the output contains, what it deliberately excludes, and how to proceed next. An agent has everything needed to call this tool correctly and know what to expect.

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 the schema is an empty object, so parameter semantics are not a concern. The description correctly implies no inputs are needed, matching the empty schema. The baseline of 4 applies because nothing is missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it lists every mounted tool with its capability id, domain, one-line summary and budget weight. It also explicitly distinguishes this from the schema-retrieval step by naming meta.schemas, so an agent can tell them apart.

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 explicit when-to-use guidance: ask this first to learn what exists, then pull schemas for the few tools you intend to call via meta.schemas. The two-stage workflow is clearly described, leaving no ambiguity about ordering or 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?

The readOnlyHint annotation covers safety, but the description adds little behavioral clarity. It hints at 'three E21/E13 routes plus the honest interim state' without explaining what the tool returns, whether it simply describes paths, or what an agent should do with this information. No contradiction exists, but the behavior remains opaque.

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 brief and front-loaded, which is good, but it sacrifices clarity for brevity. The unexplained domain terms reduce the value of the sentence, so it is concise without being optimally informative.

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

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

With no parameters, no output schema, and only a readOnlyHint annotation, the description carries the full burden of explaining what this tool is for. It is too cryptic to let an agent confidently use it or interpret its results, especially given the large sibling toolset.

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, so there is nothing for the description to document about arguments. The baseline of 4 is appropriate because no parameter semantics are needed.

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 conveys a general purpose ('the publishing path', 'the only way into the directory') but never states a concrete verb or outcome. The phrases 'three E21/E13 routes' and 'honest interim state' are unexplained jargon that leaves the tool's actual function vague, though it avoids being a pure tautology.

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 an implicit usage hint ('only way into the directory'), but no explicit statement of when to invoke this tool versus any sibling. No alternatives, exclusions, or prerequisites are mentioned, so an agent gets little decision support.

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 that this is a safe read operation. The description adds useful context by calling the register 'sealed' and indicating that it includes both draft and published statuses, which suggests immutability and completeness. However, it does not describe output format, ordering, or any additional constraints.

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 entire description is a single dense sentence with no filler. It front-loads the core subject ('manifest standard's sealed artifact register') and then lists the distinguishing data fields efficiently.

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 parameterless read-only tool, the description is largely complete: it names the resource and specifies the main fields returned. Since there is no output schema, it would be slightly stronger if it explicitly stated that the tool returns a list or map of artifacts, but the word 'register' implies this sufficiently.

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 accepts zero parameters, so there are no parameter semantics to confuse an agent. The description's mention of the returned fields provides enough context for what the tool exposes, and with no parameters, the baseline 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 identifies the tool as a register of the manifest standard's artifacts and enumerates the specific fields returned: path, canonical IRI, draft/published status, and SHA-256 per contract file. This goes well beyond the tool name and makes the tool's subject clear, though it does not explicitly state a verb like 'returns' or 'lists'.

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 guidance about when to use this tool versus alternatives such as manifest.get, directory.get, or facts.latest. The description implies it is the artifact register, but it does not state when an agent should select it or when it should prefer another sibling tool.

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