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

The description adds useful behavioral context beyond annotations, such as the note that only certain states publish here (Niederösterreich, Oberösterreich, Tirol, Vorarlberg, Burgenland, Steiermark). Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It does not contradict 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 concise and front-loaded: the first sentence states the main purpose, followed by usage guidance, a caveat, and examples. The structure is efficient with no redundancy, though it could be slightly tighter by merging the first two sentences.

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 there are 11 optional parameters, a full schema, an output schema, and annotations, the description provides sufficient context: the tool's scope, the limitation on participating states, and example queries. It does not need to explain return values because the output schema exists.

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 schema already provides detailed descriptions for all 11 parameters (e.g., 'Results per page: 10, 20, 50, or 100 (default: 20)'). The description's example queries demonstrate parameter usage but do not add new semantic meaning beyond what the schema already defines.

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's purpose: 'Search Austrian district administrative authority announcements (Kundmachungen der Bezirksverwaltungsbehörden).' The verb 'search' combined with the specific resource (district administrative authority announcements) distinguishes it from sibling RIS tools like ris_bundesrecht or ris_judikatur.

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

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

The description provides clear context on when to use the tool ('find announcements and ordinances from district administrative authorities') and includes example queries. However, it does not explicitly state when not to use it or mention alternative tools for other RIS content, so it misses the 'explicit when-not' criterion for a 5.

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

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

Annotations already cover readOnlyHint and destructiveHint, lowering the bar. The description adds context about the corpus (official publications) but doesn't disclose behavioral traits like pagination, rate limits, or response format. Even though the schema covers some of these, the description adds no additional behavioral context beyond what annotations already imply.

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

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

The description is front-loaded with the main purpose, followed by a clear usage directive and valuable example queries. It contains no fluff or redundant information, making it highly concise and well-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?

With 9 optional parameters, an output schema, and strong annotations, the description sufficiently covers what the tool does, when to use it, and how parameters can be combined. The example queries provide practical invocation guidance, making the tool easy to select and use correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description provides example queries (e.g., bgblnummer='120', jahrgang='2023', teil='1' and suchworte='Klimaschutz') that illustrate how parameters combine for specific use cases, adding meaningful semantic guidance beyond the raw 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 states 'Search Austrian Federal Law Gazettes (Bundesgesetzblatt)', identifying the specific resource and action. It also notes the gazette contains official publications of federal laws, ordinances, and treaties, distinguishing it from sibling tools like ris_bundesrecht or ris_judikatur.

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 directs when to use the tool: 'Use this tool for historical research and tracking when laws were enacted.' It also gives concrete example queries for common use cases. However, it does not mention alternatives or when not to use it, so it stops short of a 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?

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses crucial behavioral quirks: 'suchworte' results are ordered alphabetically by law title; 'paragraph' is ignored for applikation='Erv'; and 'fassung_vom' retrieves the law as it stood on a specific date. These add significant operational context that the annotations do not cover, making API behavior predictable.

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 structured with a clear opening, a 'Search strategy' section, and a bulleted 'Example queries' list. Every sentence adds value: the strategy section explains when to use which parameter, and the examples cover diverse use cases. Despite its length, it is densely informative and well-organized, not wasteful.

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 9 parameters, an output schema, and annotations, the description covers the essential search scenarios, edge cases (Erv ignoring paragraph, alphabetical sorting), and concrete examples. It addresses the main risks (buried results, article-based laws, versioned texts) without needing to duplicate schema details. Given the tool's complexity, this is a complete and self-sufficient guide.

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 the schema already has 100% parameter coverage, the description adds substantial meaning: it explains that 'titel' and 'paragraph' are precise for known laws, that 'suchworte' is a broad but poorly ordered fallback, that 'abschnitt_typ' is required for article-based laws like B-VG, and that 'paragraph' is ignored for 'Erv'. The example queries further illustrate combinations. This enriches the schema beyond mere parameter names.

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 'Search Austrian federal laws (Bundesrecht)' and follows with 'Use this tool to find Austrian federal legislation like ABGB, StGB, UGB, etc.' This is a specific verb+resource statement. It clearly distinguishes from siblings like ris_landesrecht (state law) and ris_judikatur (case law) by explicitly stating the federal law scope.

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

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

The description provides explicit search-strategy guidance: 'titel and paragraph are the precise entry points — prefer them whenever the law or the section is known' and warns that 'suchworte' returns hits ordered alphabetically, not by relevance. It does not explicitly name sibling tools or state when to prefer this tool over them, but the federal-law scope is clear from the title and description. This is strong context with no explicit exclusions, so a 4 is 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?

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?

The description adds valuable behavioral context beyond the annotations by stating the tool operates on a document 'already open in the RIS document viewer,' implying a stateful prerequisite. Annotations already cover read-only and non-destructive traits, and the description does not contradict them.

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 only two sentences, front-loaded with the core purpose and followed by usage context. Every word earns its place, with no redundancy or fluff.

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

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

Given the tool's simplicity and the existence of a rich schema and output schema, the description covers the essential context: what it does, when it's intended, and an alternative. It could mention which parameter to use for document identification, but the schema descriptions handle that, so completeness is solid.

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 itself does not elaborate on parameter relationships or usage; it relies entirely on the schema, which sufficiently documents each parameter. No additional semantic value is provided.

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 an already-open document, with a specific verb ('Return') and resource ('one section of a document'). It also explicitly distinguishes from the sibling ris_dokument by noting that ris_dokument is for full text, making the purpose 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?

It provides explicit usage guidance: intended for the viewer widget and not for direct use, with a clear alternative for full-text retrieval ('use ris_dokument'). This precisely tells the agent when to use this tool and when not to.

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, covering safety. The description adds behavioral context by defining the Gr and GrA applications and providing example query structures. However, it doesn't disclose pagination or rate limits, but those are not essential given the annotations and 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 description is moderately sized with clear sections for purpose, usage, applications, and examples. It is front-loaded with the core purpose. The examples add length but are directly useful. Some repetition of schema info could be trimmed, but overall it is 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?

With 19 optional parameters, a complete search tool description needs examples and guidance, which are provided. The output schema exists so return values need not be described. The description covers the main use cases and variant applications, though it could mention how results are sorted/paginated. Overall it is adequate for the complexity.

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 all 19 parameters have descriptions. The description adds value through example queries that show parameter combinations (e.g., gemeinde='Graz', suchworte='Parkgebuehren') and clarifies which parameters belong to Gr vs GrA (though some of that is already in schema descriptions). This goes beyond the baseline of 3.

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

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

The description clearly states 'Search Austrian municipal law (Gemeinderecht)' with a specific verb and resource, and further clarifies 'municipal regulations and local ordinances.' This distinguishes it from sibling tools for federal law (ris_bundesrecht), state law (ris_landesrecht), and case law (ris_judikatur).

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 this tool to find municipal regulations and local ordinances,' providing clear context. It also explains the Gr/GrA application variants and gives example queries, but does not explicitly state when to prefer an alternative tool or exclude other RIS tools. This is slightly less explicit than the 'search_calls_extensive' alternative example.

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 annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds context about tracking creation/modification/deletion events. It does not disclose pagination behavior or result size limits, but the annotations cover the safety profile, so a mid-range score is appropriate.

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

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

The description is front-loaded with purpose, then usage, then a well-organized list of applications, and ends with concrete examples. It is somewhat long due to the app list, but the structure and examples make it readable and each section earns its place. Minor duplication with the schema's enum is acceptable.

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

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

The description covers purpose, usage, applications, and provides two example queries, which is sufficient for a read-only search tool with an output schema and good parameter descriptions. Slight concern: the description claims '30 total' applications while the schema enum provides 36, creating a minor inconsistency, but overall the tool is well-specified.

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 each parameter already described in detail. The tool description adds example queries showing combinations of applikation and date range, but these examples reinforce, rather than add new meaning, to the parameter semantics. Thus baseline 3 is warranted.

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

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

The description states a specific verb+resource: 'Search document change history' and explains it tracks changes to legal documents over time, showing when documents were created, modified, or deleted. It clearly distinguishes from sibling tools by focusing on the historical view across multiple applications, rather than specific 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 this tool to track changes to legal documents over time,' giving clear context for when to apply it. However, it does not mention alternatives or when not to use it, so it stops short of full when/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 and destructiveHint=false, which the description aligns with. The description adds valuable behavioral context beyond annotations, such as the distinction between Rechtssatz and Entscheidungstext, the default behavior of searching both, and the note that the RIS API otherwise searches only Rechtssätze. It also discloses the requirement that fachgebiet only matches full decision texts, which is not apparent from the schema alone.

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 well-structured: a one-line summary, a concise explanation of document kinds, and a bullet-like list of example queries. Each section earns its place, with the most important information front-loaded and examples at the end. It is thorough without being bloated, achieving excellent readability for an AI agent.

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 complex tool with 16 parameters and no required fields, the description provides ample context to invoke it correctly. It covers key dimensions: scope, document types, jurisdiction selection, parameter constraints, and example queries. It also notes historical data collections that remain searchable. The presence of an output schema and rich parameter descriptions means the description does not need to explain return formats, making this level of completeness ideal.

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%, with every parameter having a description, defaults, and enums. The description adds synergy by tying parameters together in examples (e.g., 'gerichtsbarkeit="Justiz", fachgebiet="Arbeitsrecht", sortierung="datum_ab"') and clarifying nuanced behaviors like the interaction between fachgebiet and dokumenttyp. This exceeds the baseline 3 by providing guidance on how to combine parameters effectively.

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).' It clearly distinguishes this tool from siblings by focusing on case law (Judikatur) rather than legislative texts. It further differentiates document kinds (Rechtssatz vs. Entscheidungstext) and gives concrete examples, leaving no ambiguity about what the tool does.

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

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

The description provides clear when-to-use guidance through multiple example queries (e.g., 'gerichtsbarkeit="Vfgh", suchworte="Grundrecht"' and 'norm="1295 ABGB"'). It explains applicable jurisdictions and parameter constraints, such as fachgebiet only applying to Justiz and requiring dokumenttyp 'entscheidungstext' or 'beide'. It stops short of explicitly naming alternative sibling tools, but the context strongly implies when this tool is 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds behavioral context by stating the geographic coverage (all 9 states) and providing example queries that show how parameters combine. This goes beyond the annotations, though it does not describe edge cases or response format (not needed due to 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 description is concise and front-loaded with the main purpose. It includes two example queries that are highly informative without being verbose. Every sentence contributes value, and there is no redundant repetition of schema details.

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 complexity (9 parameters, output schema provided, rich annotations), the description is sufficiently complete. It clarifies the tool's domain, scope, and usage with examples. The only minor gap is not explicitly differentiating from ris_landesrecht, but the name and description make the gazette focus clear.

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%, which already explains all 9 parameters. The description adds value with example queries that demonstrate how to use specific parameters like lgblnummer, jahrgang, bundesland, and suchworte together. This enriches the parameter semantics beyond the schema's isolated definitions.

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 explicitly states 'Search Austrian State Law Gazettes (Landesgesetzblatt)' with a specific verb and resource. It adds that it covers all 9 federal states, which distinguishes it from sibling tools like ris_bundesgesetzblatt or ris_landesrecht. The purpose is 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 says 'Use this tool to find official publications of state/provincial laws,' providing clear context for when to use it. It does not explicitly name alternatives or state when not to use it, but the scope (state gazettes) is clear enough to guide tool 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 indicate read-only and open-world behavior, but the description adds valuable behavioral details: suchworte results are ordered alphabetically not by relevance, and Austrian legal topics are often split across federal/state laws. These traits aren't obvious from annotations and help the agent anticipate search outcomes.

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 well-structured: it opens with a clear one-sentence purpose, then provides usage strategy, and ends with example queries. Every sentence carries useful information, and the length is appropriate for the tool's complexity.

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

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

Given the tool has 11 parameters and an output schema, the description provides sufficient context for correct selection and invocation. It covers purpose, alternative tools, search strategies, and concrete examples, making it complete for real usage.

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 covers all parameters, but the description adds strategic meaning beyond the field descriptions. It explains how parameters like 'titel', 'paragraph', and 'suchworte' should be used together, provides example queries, and warns about the suchworte behavior (which is repeated in the schema but reinforced with examples).

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 searches Austrian state/provincial laws (Landesrecht) and explicitly distinguishes it from ris_bundesrecht for federal laws. It uses a specific verb and resource, making the tool's purpose unambiguous and differentiated from 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 provides explicit when-to-use guidance: it recommends using 'titel' and 'paragraph' for precise searches, warns against 'suchworte' due to alphabetical ordering, and directs users to ris_bundesrecht for federal law topics. This goes beyond general context and gives concrete decision rules.

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=true and destructiveHint=false, so the safety profile is known. The description adds content context ('Contains government proposals submitted to parliament') and demonstrates search patterns, but does not disclose behaviors like result language, pagination limits, or API-specific quirks. With annotations covering the critical safety aspects, this is adequate but not exceptional.

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 well-structured: a clear one-line purpose, a usage sentence, a content sentence, and three examples. It is not overly verbose, and every section serves a purpose. It loses a point for slight redundancy in the first two sentences, both of which emphasize the bill topic, but overall it is tight and 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?

Given the presence of a rich output schema, exhaustive parameter descriptions, and readOnly annotations, the description does not need to explain return values or safety. It adequately covers what the tool searches, when to use it, and how to formulate queries. It is complete for the average agent, though a note about German-language results or the 'openWorldHint' could push it to a 5.

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

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

The schema has 100% description coverage, so the baseline is 3. The description goes beyond by providing concrete example queries that map to parameters (suchworte, einbringende_stelle, beschlussdatum_von/bis), clarifying how to combine them and what the expected outcome is (e.g., bills from 2024). This adds practical meaning beyond the raw 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 'Search Austrian Government Bills (Regierungsvorlagen)', a specific verb+resource statement that clearly distinguishes this tool from siblings like ris_bundesrecht or ris_judikatur. It further narrows scope with 'government proposals submitted to parliament', eliminating ambiguity.

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

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

Explicitly states 'Use this tool for legislative history and parliamentary materials', giving a clear when-to-use context. It does not name alternatives, but the domain is distinct enough from siblings (laws, court decisions, ordinances) to imply exclusions. Example queries further illustrate realistic use cases.

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. The description adds behavioral context by listing the collection codes (PruefGewO, Avsv, Spg, etc.) and showing example queries, which clarifies the tool's scope beyond the safety flags. No contradictions 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 well-structured: an opening purpose statement, a usage note, a bulleted list of applications, and five example queries. Despite the tool's complexity, every section is purposeful and front-loaded. The content is dense but not verbose, earning 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?

This is a complex tool with 32 parameters, but the description covers its purpose, usage context, all application codes, and practical examples. The output schema and 100% schema description coverage handle parameter details and return values. For a search tool of this complexity, 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value by including concrete example queries that demonstrate how parameters combine (e.g., applikation='Mrp', suchworte='Budget', einbringer='BMF...'). This practical illustration exceeds what the schema alone provides, raising the score to 4.

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: 'Search miscellaneous Austrian legal collections (Sonstige).' It then enumerates the eight collections, making the scope concrete. However, it does not explicitly differentiate from sibling tools by naming a 'use X instead' alternative, so it falls short of 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?

The description clearly states 'Use this tool for specialized legal documents and historical materials,' giving an explicit context for when to use it. It also provides example queries per application, which is practical guidance. It does not mention sibling alternatives or exclusion criteria, keeping it at a 4.

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 clear. The description adds a key behavioral limitation: 'Currently only Tirol data is available (since January 1, 2022). Other federal states have not yet published their ordinance gazettes in RIS.' This is not captured in annotations and helps set expectations. The example queries also illustrate search semantics.

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 well-structured: an opening line, a usage sentence, a brief note on data availability, and a bulleted list of example queries. Every sentence contributes useful information and there is no fluff. It is slightly longer than the minimal example but remains focused 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?

Given the tool has 9 optional parameters and an output schema, the description covers the primary search dimensions and the critical Tirol-only limitation. It provides examples for the main parameters (full-text, title, state, publication number, date range). Pagination and response format are handled by schema and output schema, so the description is sufficiently complete for a well-documented 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% – every parameter already has a descriptive label and meaning. The description's examples (suchworte, titel, bundesland, kundmachungsnummer, kundmachungsdatum_von/bis) essentially mirror the schema descriptions, adding only a combined date-range example but no new parameter syntax or deeper 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 'Search Austrian state ordinance gazettes (Verordnungsblaetter der Laender)' which is a specific verb+resource, and clarifies 'state/provincial ordinances' distinguishing it from federal legal databases. The title 'Verordnungsblätter durchsuchen' reinforces this. This is distinct from siblings like ris_landesrecht or ris_landesgesetzblatt by focusing on ordinances specifically.

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 an explicit usage statement: 'Use this tool to find official publications of state/provincial ordinances.' It also gives concrete example queries for common scenarios, which helps the agent understand when to apply it. However, it does not explicitly mention alternatives for federal law or other contexts, stopping 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.