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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds that the tool returns a JSON with all attributes and a direct link to GISOS documentation, which provides some behavioral context but does not go 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 moderately sized with two paragraphs. The main purpose is front-loaded in the first sentence. The Args/Returns section provides structured detail. Minor redundancy in restating the feature_id description. Overall, every sentence contributes 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?

The description is complete for a simple tool with one required parameter. It explains input source, return format, and key attributes. The output schema exists (not shown but noted true) and is supplemented by the description. Sibling tools are listed, providing context. No gaps evident.

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 only one parameter (params) containing one property (feature_id), the description explains where the feature_id comes from and what the return fields include. This compensates for the schema's minimal description (0% coverage). The description adds meaningful guidance beyond the schema structure.

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 the tool's purpose: retrieving complete details of an ISOS Ortbild using a feature ID. It uses a specific verb ('ruft ab') and resource ('vollständige Details eines ISOS-Ortsbildes'), clearly distinguishing it from siblings like bak_search_isos (search) and bak_isos_by_kanton (list by canton).

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

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

The description provides a clear usage guideline by specifying that the feature_id comes from results of bak_search_isos or bak_isos_by_kanton. This tells the agent how to obtain the required input. However, it does not explicitly state when not to use the tool or mention alternatives within the same family.

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 indicate readOnlyHint=true and openWorldHint=true. The description adds behavioral context by explaining the combination of RSS and structured data, and the output JSON structure. No contradictions.

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 with bullet points but contains redundant information (e.g., repeating parameter details already in schema). It could be more concise without losing clarity.

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

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

Given the read-only nature and no output schema provided, the description sufficiently covers inputs and output structure. Missing error handling details, but acceptable for a simple retrieval 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?

The schema has high coverage for 'limit' and 'sparte', but the description adds clarity on the purpose of 'sparte' (e.g., filtering categories like 'Film', 'Literatur') and the default/max for 'limit'. This adds value 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 states the tool retrieves Swiss culture prizes, combining current winners from an RSS feed with structured info. It lists specific prizes and distinguishes itself from sibling tools that focus on ISOS, news, or traditions.

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

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

The description explains what the tool does but does not explicitly state when to use it versus alternatives, nor does it provide exclusions or prerequisites. Usage context is implied but not directly guided.

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. Description adds that it fetches from an RSS feed and returns structured JSON. Does not mention rate limits or auth, but incremental value 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?

Description is well-structured with purpose first, then data source, topics, and structured Args/Returns. Each sentence adds value; no 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?

Covers purpose, data source, topics, input parameters, and output structure. For a read-only news tool with annotations, it 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?

Input schema has 0% description coverage per context signal, but description compensates by explaining limit (default 10, max 50) and keyword with examples (e.g., 'Filmpreis'). Adds meaning beyond 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?

Description clearly states the tool retrieves current press releases from BAK, specifies data source (RSS feed), and lists covered topics (culture prizes, cultural policy, etc.). Distinguishes from sibling tools that focus on ISOS, traditions, or open data.

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?

Implies usage for general BAK news, and sibling names suggest other specialized data (e.g., kulturpreise, isos). No explicit when-not-to-use or alternatives, but context 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 indicate readOnlyHint and idempotentHint, confirming safe read behavior. The description adds that it returns metadata with formats and download URLs, providing more detail than annotations 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 with 'Args' and 'Returns' sections, front-loading the main purpose. It is concise but could be slightly shorter without losing clarity.

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

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

Given the output schema exists, the description still provides a clear return structure and use cases. It covers purpose, parameters, and return format comprehensively for a read-only query 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?

The parameter 'query' is documented in both the schema and the description with a clear description. The description outlines the return structure, adding value beyond the schema, though schema coverage is actually good.

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 it lists open data datasets from the Federal Office of Culture on opendata.swiss, including metadata and download URLs. This distinguishes it from sibling tools that focus on ISOS or other categories.

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 mentions relevance for GIS integration and data analysis, implying usage context but does not explicitly state when to use or not use this tool versus alternatives. No exclusions are provided.

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 idempotent, read-only, and non-destructive behavior. The description adds transparency by detailing the output fields (titel, beschreibung, kantone_mention, url) and the source of the data, which complements the annotations well.

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 into clear sections: action, source, slug retrieval, examples, and input/output. It is slightly verbose but every sentence adds value, and the structure aids 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?

Given the simple interface (one parameter, with output schema) and the annotations, the description comprehensively covers what the tool does, how to use it, and what to expect in the response. No obvious gaps.

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

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

The schema provides a description for the slug parameter, and the description supplements it with practical examples of known slugs, adding value 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 states it fetches the detail description of a living tradition from the BAK inventory, specifies the source (lebendige-traditionen.ch), and distinguishes from siblings like bak_list_traditions by explaining how to obtain the slug.

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 mentions that the slug can be obtained from bak_list_traditions or as a known short name, guiding the user on when to use this tool. It does not explicitly state when not to use, but the context is 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds meaningful context: it explains that the count field counts ISOS numbers, not features, and highlights that a source can return multiple features per site (up to 51 in GR). This clarifies a potential misinterpretation, which is valuable beyond 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 description is well-structured, front-loaded with the core purpose, and contains detailed but necessary information about parameters and return format. It uses clear German language with a logical flow from purpose, to parameters, to return values. No 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 (1 parameter, annotated as read-only) and the existence of an output schema, the description is complete. It explains the counting nuance and the return structure, leaving nothing critical for an agent to infer. The notes about source behavior (multiple features per site) are essential for correct interpretation of results.

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 provides minimal descriptions for parameters, but the description compensates by detailing the 'kanton' format (uppercase, examples) and explaining the 'limit' parameter's default and maximum, as well as the implications of limiting. Given that schema description coverage is 0%, the description effectively covers the 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?

The description clearly states the verb 'listet auf' (lists) and the resource 'ISOS-Ortsbilder eines Schweizer Kantons'. It provides the unique context of Swiss cantons and differentiates from siblings by focusing on canton-based listing. The scope is specific and unambiguous.

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

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

The description explains that it lists all ISOS sites for a canton and specifies the input format ('ZH', 'BE', 'GR etc.'). Although it does not explicitly mention when not to use it, the tool's purpose is clearly stated, and sibling differentiation is implied by the tool's name and focused resource. The return format and limit behavior are also clearly explained.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds context about return format (JSON string) and parameter defaults (limit: 50). It is consistent and provides additional useful behavioral details beyond 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 with a clear structure: purpose sentence, explanation, then Args and Returns sections. Every sentence adds value with 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?

Given the output schema exists (not shown), the description adequately covers input parameters and return format. It could provide more detail about the returned JSON structure, but with output schema this is acceptable.

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 explains each parameter (kategorie, kanton, limit) with their meanings, defaults, and valid values for kategorie. The schema already has descriptions for some parameters, but the description adds clarity like default limit and optionality of kanton.

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 filters ISOS townscapes by settlement category, optionally with canton. It lists the valid categories and distinguishes from siblings like bak_isos_by_kanton by focusing on category filtering.

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 usage context (filtering by category) but does not explicitly state when to use this tool versus alternatives like bak_isos_by_kanton or bak_search_isos. No when-not-to-use guidance is provided.

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, idempotent, and non-destructive. The description adds valuable context: the returned counts are estimated and based on a representative sample, which informs the agent about data accuracy.

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 concise: two short paragraphs. The first gives a clear purpose, and the second outlines the return structure. Every sentence is necessary 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?

With no parameters and good annotations, the description provides a complete picture of what the tool does and what it returns. The output structure is described in detail, covering the JSON keys and their meaning.

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

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

There are no parameters, so the schema has 100% coverage. The description adds no parameter information, but none is needed. Baseline of 4 is appropriate for zero-parameter tools.

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 it returns overview statistics of the ISOS inventory, with specific details like number of objects per canton. It is distinct from sibling tools such as bak_search_isos (search) and bak_isos_by_kanton (list by canton).

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 it is useful for a quick overview of the inventory scope, implying when to use it. It does not explicitly mention when not to use it or list alternatives, but the context is clear given the sibling tool 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 indicate read-only, idempotent, and non-destructive behavior. The description adds context about the return format (JSON with name, slug, url) and the scope (228 entries). No contradictions.

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 with a main sentence, context, and clear Args/Returns sections. It is slightly verbose but front-loaded 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?

Given the simple tool (1 parameter, read-only list), the description adequately explains the input and output. An output schema exists but is not shown; the description fills in the return structure.

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 single parameter buchstabe is described in the input schema, but the tool description repeats its purpose and adds context about filtering. The description adds value 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 states it lists living traditions from the official BAK inventory, with details on content and optional filtering. It is distinct from sibling tools like bak_get_tradition_detail which retrieves a single tradition.

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 does not explicitly state when to use this tool versus alternatives, but the optional filter parameter implies it is for broad listing. No guidance on when not to use.

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 readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context by explaining the search operation, data source (BAK via geo.admin.ch), and return format. It does not contradict annotations and provides sufficient transparency for a safe read-only query.

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 with a clear introduction, background context, and formatted Args/Returns sections. It is slightly verbose (e.g., the ISOS background), but every part serves a purpose. The front-loading of the main purpose is effective.

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 an output schema, the description does not need to explain return values exhaustively, but it does list key fields. The tool's input and output are well-covered. However, it lacks comparison with siblings and could mention query constraints (e.g., minimum length, which is in schema but not in description).

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 lists both parameters (query and limit) with their types and meanings, adding a default value for limit (20) and an example query value. While the schema also provides descriptions, the tool description's structured 'Args' section adds clarity and compensates for the 0% schema coverage signal.

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 that the tool searches for ISOS townscapes by place name. It specifies the resource (ISOS-Ortsbilder) and the action (search). Compared to siblings like 'bak_isos_by_kanton' (filter by canton) and 'bak_get_isos_detail' (get detail), this tool's purpose of searching by name is distinct and well-defined.

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 does not provide any guidance on when to use this tool versus alternatives. It neither mentions conditions for use nor advises when to use other tools like 'bak_isos_by_kanton' for canton-based filtering. The user must infer usage context from the tool's name alone.

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