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

Annotations already declare read-only, open-world, and non-destructive behavior. The description adds a meaningful coverage caveat that only Niederösterreich, Oberösterreich, Tirol, Vorarlberg, Burgenland, and Steiermark publish here, which affects how the agent should 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 description is short and front-loaded, with the core purpose in the first sentence. There is minor redundancy between the lead sentence and the 'Use this tool...' sentence, but the state-coverage note and examples earn their 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 an 11-parameter search tool with full schema coverage and an output schema, the description supplies the key missing context: what it searches, which states actually publish there, and example queries. It could be stronger by explicitly routing among sibling RIS tools, but it is largely 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%, so the schema already documents all 11 parameters, including enums, limits, dates, and field meanings. The description's examples show combinations like bundesland plus suchworte, but largely echo values already present in the schema.

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

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

The description states a specific verb and resource: 'Search Austrian district administrative authority announcements (Kundmachungen der Bezirksverwaltungsbehörden).' It clearly describes the domain, but it does not explicitly differentiate this tool from sibling RIS sources such as ris_verordnungen or ris_gemeinden.

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 intended use: 'Use this tool to find announcements and ordinances from district administrative authorities,' and provides example queries. However, it does not state when not to use it or name alternative sibling tools for overlapping legal-source searches.

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

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

Annotations already cover read-only, open-world and non-destructive behavior, so the bar is lower. The description adds that these are official publications of a defined scope, but says nothing about coverage/backfile limits (only hinted at inside the applikation enum) or result-shape behavior, and payload/pagination behavior lives entirely in 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?

Front-loaded one-line purpose, then a usage sentence, then compact examples — no filler. A small amount of space could be reclaimed, but the structure makes the routing information easy to scan.

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

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

An output schema exists, so return values need not be explained, and all nine parameters are documented in-schema. The remaining gap is disambiguation from ris_bundesrecht/ris_verordnungen and the 1945–2003 vs. 2004+ split, which is only visible by reading the applikation enum.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The examples go beyond per-parameter docs by showing how filters combine for an exact gazette lookup (`bgblnummer` + `jahrgang` + `teil`) versus a keyword-only search, which is genuine added 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?

States a concrete verb and resource ("Search Austrian Federal Law Gazettes") and clarifies the corpus (federal laws, ordinances, treaties). It does not, however, distinguish itself from close siblings like ris_bundesrecht, ris_verordnungen or ris_landesgesetzblatt, even though its stated contents overlap with 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?

Gives a clear use context ("historical research and tracking when laws were enacted") and two worked example queries that show exact-lookup vs. full-text search. It stops short of stating exclusions or naming which sibling to use instead for consolidated federal law or ordinances.

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 read-only/open-world annotations, it discloses important behavioral traits: suchworte results are ordered alphabetically by law title rather than relevance, paragraph is ignored for Erv English translations, and Austrian law often splits a topic across multiple statutes. These details materially affect how an agent should search and 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 description is front-loaded with purpose, then strategy, then examples. Each sentence carries practical value: the search-strategy paragraph and examples directly affect query construction rather than restating schema text.

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 9-parameter, optional-parameter search tool with a rich schema and output schema, the description provides the missing strategic context: when to prefer each search mode, how parameters interact, and representative query patterns. Return-value details are correctly left to the output 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?

Although schema coverage is already 100%, the description adds strategic semantics beyond the field definitions: titel and paragraph are precise entry points, suchworte is broad and non-relevance-ranked, paragraph is ignored for Erv, and abschnitt_typ must be Artikel for article-based laws such as the B-VG. The example queries concretely demonstrate how parameters combine.

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: search Austrian federal laws (Bundesrecht), with concrete examples such as ABGB, StGB, and UGB. It also distinguishes the federal-law scope from sibling tools like ris_landesrecht and ris_judikatur by naming exactly what body of law it covers.

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 search guidance: use titel and paragraph as precise entry points, use suchworte only for broad full-text search, and be aware of alphabetical rather than relevance ordering. It does not explicitly compare itself against sibling tools such as ris_landesrecht or ris_judikatur, but the federal-law scope makes the intended use 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?

Annotations already provide readOnlyHint and destructiveHint, so the base safety profile is clear. The description adds valuable behavior: content may be truncated for long documents, and the tool is intended for post-search retrieval. 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?

Three sentences: purpose, usage context, and truncation caution. Each sentence adds distinct value, no waste, and the most important information is front-loaded.

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 (3 optional params, output schema present), and annotations cover safety. The description covers what it does, when to use it, and warns about truncation. No significant gaps remain.

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 does not add details beyond the schema, but it does reinforce that parameters come from search results. This meets the baseline for full 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 clearly states 'Retrieve full text of a legal document' with a specific verb and resource. It distinguishes this retrieval tool from sibling search tools by positioning it as the post-search step ('Use this after searching').

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 explicit context: 'Use this after searching to load the complete text of a specific law or decision.' It also includes a caution about truncation. However, it does not name alternative tools for sections or searches, so differentiation is implied rather than explicit.

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

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

Annotations already declare `readOnlyHint: true` and `destructiveHint: false`, so the safety profile is known. The description adds valuable behavioral context by stating the prerequisite that the document must already be open in the RIS document viewer, and it clarifies that this tool is not for standalone use. This goes beyond the basic annotation coverage.

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 two sentences, front-loaded with the core purpose, and every sentence adds value: the first states the function, the second provides usage guidance and an alternative. There is no redundancy or wasted 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?

The tool has an output schema, so return values are already structured. The description covers the essential operational context: what it does, when to use it (viewer widget), the prerequisite (open document), and the alternative for full text. Given the tool's simplicity and rich schema, the description 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?

The input schema provides 100% parameter description coverage (all three parameters have clear descriptions, including the `offset` semantics). The tool description itself does not add further parameter details, but it does not need to since the schema is exhaustive. This matches the baseline of 3 for high 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 clearly states the tool returns "one section of a document already open in the RIS document viewer," specifying the verb, resource, and context. It distinguishes itself from the sibling `ris_dokument` by explicitly noting that the full text should use `ris_dokument` instead.

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 the tool is "intended for the viewer widget, not for direct use" and directs users to `ris_dokument` for the full text. This provides clear when-to-use guidance and an explicit alternative, making it easy for an agent to choose correctly.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful semantics about the Gr/GrA corpora (GrA being cross-border/Amtsblätter), but says nothing about how filters combine, what happens with zero filters, or result behavior beyond what the schema and output schema already carry.

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

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

Front-loaded with a one-line purpose, then a compact application key and four short example queries. The Applications section mildly overlaps the applikation enum in the schema, but it earns its place by explaining GrA's meaning; nothing else is padded.

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 19-parameter, all-optional search tool with an output schema and full annotation coverage, the description supplies the missing operational framing: which corpus to pick and how to compose filters. It stops short of explaining how multiple filters intersect or how empty-query behavior works, which would be the remaining 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 a 3 is the baseline. The description exceeds that by pairing parameters in concrete examples (gemeinde + suchworte, bundesland + titel, applikation + index, applikation=GrA + bezirk), which demonstrates realistic filter combinations an agent would not derive from the field list alone.

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 ("Search Austrian municipal law (Gemeinderecht)") and narrows scope to municipal regulations and local ordinances, which is distinguishable from siblings like ris_bundesrecht or ris_landesrecht by subject matter. It never names an alternative tool explicitly, so the differentiation is inferred rather than stated.

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 this tool to find municipal regulations and local ordinances" gives a clear usage context, and the Gr vs GrA distinction tells the agent which corpus applies. However, it offers no exclusions or hand-offs (e.g., use ris_landesrecht for state-level law), so the agent must infer boundaries from sibling names.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that results reflect create/modify/delete events and that deleted documents can be excluded, but says nothing about coverage limits of the history, auth, or rate behavior beyond what the limit parameter doc already states.

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

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

Front-loaded with a one-line purpose followed by usage context, then a categorized application list and examples. The 30-entry enumeration is bulky but serves as an at-a-glance selector; no sentence is pure filler.

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

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

With an output schema, full parameter descriptions and annotations present, the description carries only the remaining burden of purpose and app selection, which it does. The stale application list ('30 total' vs 36 enum values) is the one gap that could cause an agent to miss valid applications.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the example queries materially add semantics by showing realistic applikation + aenderungen_von/bis combinations, including one with an open-ended range. It does not explain interactions such as include_deleted with paging or the limit override behavior in the description itself.

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 definition uses a specific verb+resource ('Search document change history') and explains that it tracks when documents were created, modified, or deleted, which distinguishes it from document-retrieval siblings like ris_dokument. The main flaw is the application inventory: it claims '30 total' and omits several enum values (Verg, Upts, Uvs, Ubas, Umse, Bks), leaving a mild contradiction against the schema.

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

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

It states the purpose context ('use this tool to track changes to legal documents over time') and provides two concrete example invocations showing how to combine applikation with date ranges. It stops short of naming which sibling tool to use instead when the goal is fetching document content rather than history.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description's added value is the RIS-specific behavior: that the API by default searches only Rechtssätze and 'beide' widens to full texts, which prevents a silent under-retrieval. It does not add rate-limit, cost, or result-set-size information in the prose (the payload-budget note lives only in the schema), so it is strong but not exhaustive.

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?

Well structured: purpose sentence, a selection hint, a two-bullet explanation of the document kinds, then worked examples. Most sentences carry weight, but the second sentence ('Use this tool to find court decisions from Austrian courts') largely restates the first and could be dropped without loss.

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 16 optional parameters, an output schema and full annotation coverage, the description supplies what structured fields cannot: the semantic distinction between document kinds and realistic query shapes. Remaining gaps are minor — no note on pagination behavior across the large result sets implied by openWorldHint, and no pointer to ris_dokument for fetching a known decision.

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 schema description coverage at 100% the baseline is 3, and the description does add real meaning beyond the schema for 'dokumenttyp' (headnote vs. full text including Begruendung) and demonstrates 'norm', 'gericht' and 'fachgebiet' in context. However it does not clarify the cross-parameter dependencies (fachgebiet only works for Justiz and only against full texts) or the interaction between the 16 parameters, so it does not fully exceed 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 opens with a specific verb+resource ('Search Austrian court decisions (Judikatur)') and immediately narrows the resource by explaining the two RIS document kinds (Rechtssatz vs. Entscheidungstext) and how 'dokumenttyp' selects them. That is much stronger than the title alone. It stops short of a 5 because it never explicitly contrasts itself with the sibling retrieval tools (e.g. ris_dokument), so an agent that already has a case number has to infer which tool to use.

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 context is stated directly ('Use this tool to find court decisions from Austrian courts') and backed by four concrete example queries that demonstrate when to reach for gerichtsbarkeit, gericht, norm, fachgebiet and sortierung. There is no explicit when-not-to-use guidance or reference to the sibling tools that handle legislation and single-document retrieval, so the agent must infer the boundaries.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scope information (all 9 federal states) and examples, but does not add deeper behavioral context such as result contents, paging behavior, or source coverage beyond what annotations and schema provide.

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: purpose first, then scope, then examples. Every sentence and example adds practical value without repetition.

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

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

Given the rich schema, output schema, and annotations, the description is mostly complete for calling the tool correctly. It establishes the domain and gives examples, though it could better distinguish this gazette search from adjacent RIS tools.

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 parameters are documented in the schema itself. The description's example queries reinforce how lgblnummer, jahrgang, bundesland, and suchworte can be combined, but add little 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?

States a specific verb and resource: search Austrian State Law Gazettes (Landesgesetzblatt). It clarifies the scope as state/provincial official publications and all 9 federal states, but does not explicitly distinguish it from siblings such as ris_bundesgesetzblatt or ris_landesrecht.

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: finding official publications of state/provincial laws. Example queries demonstrate typical invocations, but there is no explicit guidance on when to prefer this over related siblings like ris_landesrecht or ris_bundesgesetzblatt.

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, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious backend behavior: RIS returns full-text hits alphabetically by law title rather than by relevance, so common terms bury the target. It does not cover the payload-budget/page-size degradation behavior, but that is documented in the schema instead.

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

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

Front-loaded definition followed by strategy guidance and three illustrative queries, all of which earn their place. It runs slightly long and repeats the alphabetical-ordering caveat that the suchworte parameter description already states.

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 11 optional parameters and an output schema present, the description supplies the missing piece — search strategy and the federal/state routing decision — which is exactly what the structured fields cannot express. Return-value format is left to the output schema, appropriately.

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 still adds value by explaining how titel, paragraph and bundesland compose into a precise lookup and by showing three worked examples that demonstrate date-pinning with fassung_vom and section typing. It stops short of covering gesetzesnummer or response_format, but the schema handles those.

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?

Starts with a specific verb and resource ("Search Austrian state/provincial laws") and immediately scopes it to laws enacted by the Bundeslaender, which cleanly separates it from the federal-law sibling. An agent can tell ris_landesrecht from ris_bundesrecht without opening either schema.

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

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

Explicitly ranks the parameter strategies ("titel" and "paragraph" with "bundesland" are the precise entry points; "suchworte" is the fallback) and names the alternative tool for the federal case with a concrete example (VGG / §§ 922 ff ABGB). The when-not guidance is unusually concrete.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds domain scope but says nothing about pagination payload behavior or result shape beyond what the schema and output schema already provide.

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

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

Front-loaded purpose sentence, then a one-line scope note, then three tight examples. No filler, and every example illustrates a distinct query pattern.

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 an output schema present, annotations covering safety, and 100% schema coverage on 11 parameters, the description is nearly complete. A brief note on result ordering defaults or the distinction from ris_dokument would have closed the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the example queries add genuine value by showing how suchworte, einbringende_stelle (with full ministry string) and the beschlussdatum pair are actually combined. The other parameters (limit, seite, sortierung_*, response_format) are left to 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 and resource ("Search Austrian Government Bills (Regierungsvorlagen)") and clarifies the content domain ("government proposals submitted to parliament"), which implicitly separates it from siblings like ris_judikatur or ris_bundesrecht. It lacks an explicit contrast with those siblings, keeping it below a 5.

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 to use it "for legislative history and parliamentary materials" and backs that with three concrete example queries showing full-text, ministry, and date-range usage. It gives no when-not-to-use guidance or named alternatives among the many ris_* 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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds little beyond that: it does not mention that applikation is mandatory and governs which other filters are meaningful, nor does it discuss result volume, pagination or what happens when filters irrelevant to the chosen collection are supplied.

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

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

Purpose is front-loaded in a single sentence, followed by a scannable collection list and then examples; every bullet maps to a real enum value. The five examples are slightly redundant with the bullet glosses, but they carry the extra value of showing valid filter pairings, so nothing is pure filler.

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

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

For a 32-parameter tool this description does the essential job of partitioning the parameter space by collection, and the output schema plus annotations relieve it of explaining return values and safety. The remaining gap is that it never warns that parameters are collection-scoped, which is the main way an agent would misuse 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?

With 100% schema description coverage the baseline is 3, but the description earns an increment by mapping each applikation to the filters that apply (einbringer/gesetzgebungsperiode for Mrp, partei for Upts, kmger_typ for KmGer, bundesministerium for Erlaesse) and demonstrating combinations in the example queries — knowledge the per-parameter schema text states only in isolation.

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 and resource ("Search miscellaneous Austrian legal collections") and then enumerates all eight sub-collections with parenthetical plain-language glosses, which effectively delimits this tool from siblings such as ris_bundesrecht, ris_judikatur and ris_landesrecht. An agent can immediately tell that Mrp, Erlaesse, Upts, Avsv and the rest live here and nowhere else.

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 this tool for specialized legal documents and historical materials" plus the collection inventory gives a clear selection context, and the five example queries show realistic filter combinations per collection. It does not explicitly state exclusions (e.g. "do not use for consolidated federal law — use ris_bundesrecht"), so it stops short of full when-not 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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds important behavioral context beyond annotations: only Tirol data is currently available and coverage begins January 1, 2022, preventing false assumptions about nationwide 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 description is front-loaded with purpose, followed by a critical availability note and concrete examples. It is appropriately sized, though some example queries largely restate schema-documented parameters.

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 output schema and detailed input schema, the description covers what an agent most needs: the resource scope and the major data-availability limitation. It is nearly complete, with the main gap being explicit routing guidance versus related RIS sibling tools.

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 parameters such as suchworte, titel, bundesland, and date ranges. The description reinforces parameter meaning through example queries, but adds little beyond the already-detailed schema.

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

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

The description states a specific verb and resource: searching Austrian state ordinance gazettes (Verordnungsblaetter der Laender). It clearly scopes the tool to official publications of state/provincial ordinances, though it does not explicitly distinguish it from close siblings such as ris_landesgesetzblatt or ris_landesrecht.

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 direct usage instruction ('Use this tool to find official publications of state/provincial ordinances') and useful example queries, but it does not explain when to prefer or avoid this tool relative to sibling RIS tools. The Tirol-only availability note helps set expectations but is not an alternative-selection guideline.

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