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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context: episodes are returned in chronological descending order and limited to the latest ones. It does not mention pagination limits or response shape, but the output schema partially covers that.

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

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

The description is compact and well-structured: core action, use case, ordering note, and example each appear in a distinct tagged section. There is no redundant filler, 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?

Given the output schema, safety annotations, use case, ordering guarantee, and example, the description is sufficiently complete for a straightforward read-only episode lookup. Minor gaps such as explicit pagination behavior and sibling-tool differentiation prevent a perfect score.

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

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

The example (business_unit='srf', show_id='echo') adds practical meaning by showing how to supply the two required parameters. However, with 0% schema description coverage, the description does not explain page/page_size semantics or enumerate allowed business_unit values, leaving significant parameter meaning to inference.

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

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

The description uses a specific verb ('Ruft ... ab') and resource ('neuesten Episoden einer Radiosendung'), making it clear the tool returns recent podcast/radio episodes. It is distinct from video and livestream siblings via the 'Radiosendung' qualifier, though it does not explicitly name a sibling alternative.

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 use-case tag ('Auffinden konkreter Radiobeiträge oder Podcast-Folgen') implies when the tool should be used. However, it gives no explicit guidance on when not to use it or how it relates to sibling tools like srgssr_audio_get_shows or srgssr_audio_get_livestreams.

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, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: it returns all live stations for a business unit, notes that RTR and SWI have few or no live channels, and explains the relationship to the EPG tool. This goes beyond the structured hints without contradicting 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 compact, front-loaded with the core purpose, and structured into useful sections: use_case, important_notes, and example. Every sentence earns its place and no unnecessary details are included.

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

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

Given a single required parameter with enum values in the schema and an output schema present, the description provides complete guidance for selecting and invoking the tool. It covers purpose, alternatives, edge cases, and a concrete invocation example, leaving no critical gap for an agent.

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

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

The input schema already documents the business_unit parameter with an enum of allowed values and a descriptive German label. The description adds a concrete example (business_unit='srf') and clarifies that the parameter selects a SRG SSR Unternehmenseinheit, which helps an agent invoke it correctly despite the low schema description coverage noted in context.

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: 'Listet alle Live-Radiosender einer SRG SSR Unternehmenseinheit auf.' It also names the sibling alternatives srgssr_video_get_livestreams for live TV and srgssr_audio_get_shows for show directories, so an agent can clearly distinguish this tool from related ones.

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 use_case section explicitly states when to use the tool, including building radio directories and live-stream selection, and notes that it is a prerequisite for srgssr_epg_get_programs. It also gives exclusions and alternatives: use video livestreams for TV and audio shows for show directories.

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, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context: it explains that shows are grouped by initial letter, and that omitting character_filter triggers multiple queries that are merged. This goes beyond the annotations. No contradiction with annotations.

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

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

The description is structured with a main sentence, a use_case block, important_notes, and an example. Each section adds unique value without redundancy. The main sentence is front-loaded. While slightly verbose due to XML tags, the content is purposeful and well-organized.

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 a nested parameter object and an output schema, the description covers the key operational details: required channel_id source, character_filter behavior, and podcast inclusion. Pagination is not explained, but that is a common pattern. The example further clarifies usage. Overall, the description is sufficient for an agent to call the tool correctly.

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

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

Despite the reported schema description coverage of 0%, the nested schema actually contains descriptions for channel_id, business_unit, and character_filter. The tool description reinforces and extends this by explaining the origin of channel_id and the query-count implications of character_filter. It does not detail page/page_size, but these are standard pagination parameters. The description compensates for the schema coverage gap 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 clearly states the action ('Listet Radiosendungen auf') and the resource (SRG SSR radio channel). The use_case provides browsing context, and the title reinforces the purpose. It is distinct from sibling tools like srgssr_audio_get_episodes or srgssr_audio_get_livestreams, though it doesn't explicitly name alternatives.

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

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

The important_notes explicitly state that channel_id is mandatory and must come from srgssr_audio_get_livestreams, and explain the behavior of character_filter (single query vs. 27 combined queries). This gives clear operational guidance. It doesn't explicitly say when not to use this tool, but the use_case implies catalog browsing for radio/podcast formats.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses meaningful runtime behavior: both data sources are fetched in parallel via 'asyncio.gather,' and a failure in one source still returns the other with a 'ToolErrorResponse' in the corresponding field. This graceful-degradation detail is genuinely useful for an agent deciding how robust the output is.

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

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

The description is compact and well structured, with the core purpose up front, then a use-case tag, important notes, and a concrete example. Every sentence adds value: the parallel-fetch note justifies the single-call approach, the degradation note sets expectations, and the example makes parameter formatting concrete.

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 annotations cover return/read-only semantics, the description provides everything needed to invoke the tool correctly: what it combines, when to use it, which business units support EPG, how failures behave, and a full parameter example. No critical operational context is missing.

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

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

The input schema has very low description coverage and the description does not explain each parameter's role explicitly. However, the included example ('business_unit='srf', channel_id='srf-1', date='2026-04-30', latitude=47.3769, longitude=8.5417') conveys the expected shape and realistic values for all required parameters. It also mentions that EPG applies only to certain business units, which helps interpret the business_unit parameter.

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

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

The description clearly states a specific verb and resource: it 'kombiniert die 24-Stunden-Wettervorhersage von SRF Meteo mit dem EPG-Tagesprogramm eines SRG SSR TV- oder Radiosenders.' This differentiates it from the sibling weather and EPG tools by explicitly presenting it as a combined briefing in a single call.

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

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

The description gives a concrete use case ('Abendplanung, redaktionelle Tages-Briefings') and explains the benefit over two sequential roundtrips: 'ein einzelner Tool-Call genügt statt zweier sequentieller Roundtrips.' It also notes an important limitation, that EPG is only available for SRF, RTS, and RSI. However, it does not explicitly name alternative sibling tools or state when users should prefer a dedicated weather-only or EPG-only tool.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive, so the bar for behavioral disclosure is lower. The description adds valuable behavioral context: the channel_id naming convention, uppercase requirements for RTS radio, and the specific availability limitations. It does not contradict the annotations.

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

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

The description is front-loaded with the core purpose and then structured into use case, important notes, and examples. The channel list is long but earns its place because it prevents likely mistakes with channel_id formatting and availability.

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 parameter objectabbility and the presence of an output schema, this description is complete enough for an agent to invoke the tool correctly. It covers what the tool does, which business units and channels are valid, formatting quirks, and concrete usage examples. No critical information is missing.

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

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

Schema description coverage is low, but the description compensates by explaining the channel_id format, listing many valid channel IDs, and providing two worked examples that map business_unit, broadcast_type, channel_id, and date. It does not deeply define `date` beyond the schema pattern, but the examples and opening sentence supply sufficient semantics.

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

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

The description states a specific action—retrieving the full electronic program guide for an SRG SSR TV or radio channel for a given day—with clear scope. It identifies the resource (program schedule) and is distinguishable from all sibling tools, which focus on weather, audio/video episodes, or polis 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?

The description gives clear context: TV/radio program previews and editorial program tips. It also provides explicit exclusions ('nicht für RTR oder SWI') and known channels, but it does not explicitly name alternative tools or when to prefer them over this one.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful context by stating the historical depth (back to 1900), the available filters, and the returned fields. No contradiction with annotations.

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

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

The description is compact and well structured: one action sentence, followed by use case, important notes, and a concrete example. Every element earns its place and there is no redundant wording.

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

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

For a simple filtered list tool with an output schema and strong annotations, the description provides enough to call it correctly: source system, data domain, historical range, filters, and sample usage. Pagination defaults are visible in the schema, so nothing critical is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for year/canton filters and gives an example (year_from=2023), but it does not explain page, page_size, or year_to semantics. Pagination is left entirely to the schema names and defaults.

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

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

The description uses a specific verb and resource: it retrieves Swiss National Council, Council of States, and cantonal elections from the Polis system and lists the returned fields (date, designation, ID). The domain 'Wahlen' clearly separates it from the sibling 'Votations' tools without needing to open 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 names concrete use cases (historical election analyses, journalistic research) and states capabilities (filter by year/canton, data since 1900). It does not explicitly mention when not to use it or point to sibling alternatives such as get_votations, so it is clear but not fully prescriptive.

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. The description adds useful behavioral context by specifying what data the tool returns for one votation, and it does not contradict the annotations. It omits error/rate-limit details, but the annotation coverage lowers the burden.

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

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

The description is compact and well-structured, with use_case, important_notes, and example sections that each earn their place. The core retrieval meaning is front-loaded, and there is no unnecessary prose.

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

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

With only one parameter, an output schema present, and annotations covering safety, the description is complete enough for correct invocation. It provides purpose, source of the required ID, a concrete example, and confirms the non-mutating nature via annotations.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by explaining that votation_id must be obtained from srgssr_polis_get_votations and by providing the concrete example 'v1'. This adds meaningful provenance beyond the schema's pattern and title, even though it does not explain the ID's full format.

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: 'Ruft detaillierte Resultate einer einzelnen Schweizer Volksabstimmung ab' and lists concrete result content (Ja/Nein-Anteile, Stimmbeteiligung, kantonale Ergebnisse, Annahme/Ablehnung). The word 'einzelnen' clearly distinguishes this tool from sibling srgssr_polis_get_votations, which lists votations.

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

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

The description gives a clear use case ('Vertiefte politische Analysen, Visualisierung kantonaler Unterschiede') and an important dependency: the votation_id must come from srgssr_polis_get_votations. It does not explicitly name alternatives to avoid, but the singular scope and the cross-reference make the intended usage 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 cover read-only, idempotent, non-destructive. The description adds valuable behavioral context beyond annotations: data goes back to 1900, the canton filter resolves to a locationid, and a year range translates into multiple queries because it maps to voting days – this is non-obvious and affects expectations. It also discloses pagination bounds (page_size 1–100). This goes beyond what annotations provide, though it doesn't cover rate limits or auth, which are likely irrelevant for this read-only endpoint.

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 efficiently structured with XML-style tags that front-load the purpose, then the use case, important notes, and example. Every sentence earns its place – there is no filler. The <example> provides a concrete invocation that reinforces the parameter semantics. The length is justified by the density of operational 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?

For a list-fetch tool with an output schema and annotations covering safety, the description is nearly complete. It covers purpose, usage, behavioral nuances, and parameter effects. The only minor gaps are the lack of explicit mention of the response's pagination structure or the meaning of 'openWorldHint', but those are not essential for correct invocation given the output schema exists. Overall, an agent has enough to call it 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 0%, so the description must compensate. It explains the semantics of canton and year_from/year_to (how they get resolved), and mentions page_size's range. However, it does not explicitly explain the 'page' parameter or the default behavior of each parameter individually. The example clarifies usage but does not fully cover all parameters. It adds meaningful meaning for the two core filters but leaves page and page_size under-described, so a 3 is appropriate.

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

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

The description clearly states the specific verb ('Ruft ... ab') and resource ('Schweizer Volksabstimmungen und Referenden aus dem Polis-System'), and lists the returned fields (Datum, Titel, votation_id). It explicitly distinguishes itself from srgssr_polis_get_elections and positions itself as the prerequisite for srgssr_polis_get_votation_results, so an agent can tell it apart 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 <use_case> tag gives concrete contexts (historical analysis, journalistic research) and explicitly states when NOT to use it ('Für Wahlen ... stattdessen srgssr_polis_get_elections'). It also provides operational guidance in <important_notes> about filter behavior (canton→locationid, year→voting days) and pagination limits, leaving no ambiguity about when to select this tool.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behaviors. The description adds useful behavioral details beyond these: episodes are delivered in descending chronological order and pagination is constrained to page_size 1–50. This clarifies response structure and limits, which is valuable and does not contradict the annotations.

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

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

The description is concise and well-structured with XML-like tags (use_case, important_notes, example) that separate purpose, behavioral notes, and an example. The primary sentence is front-loaded, and every element adds value—there is no fluff. It could arguably be more compact, but is appropriately sized for the information conveyed.

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 moderate complexity (3 parameters plus pagination), the description covers the essential behavioral aspects (ordering, pagination), provides a usage context, and links to the prerequisite tool for show_id. The output schema exists, so return values are documented elsewhere. What is missing is any mention of authorization or rate limits, but these are unlikely critical for a read-only listing tool with annotations covering safety. Overall, it is complete enough for an agent to call 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 0% (only business_unit has a description in the schema), so the description must compensate. It does so by providing a concrete example (business_unit='srf', show_id='tagesschau') and noting that show_id comes from get_shows. It also specifies the page_size range (1–50). The page parameter is not explicitly explained, but its meaning is clear from the pagination context and default value in the schema. Overall, enough meaningful guidance is added for the key 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 tool's action: 'Ruft die neuesten Episoden einer TV-Sendung ab' (retrieves the latest episodes of a TV show), and lists the returned fields (episode title, date, duration, video ID). It specifies the resource (TV show episodes) and verb, but does not explicitly contrast with the sibling audio_get_episodes. The tool name and title already convey the video domain, so differentiation is implicit rather than explicit.

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 use case ('Recherche zu konkreten Sendungsausgaben' – research on specific show editions) and notes that a valid show_id comes from srgssr_video_get_shows, guiding the agent on a prerequisite. However, it does not explicitly state when to use this tool over alternatives (e.g., not for audio episodes) nor provide 'when-not' guidance. The context is helpful but not 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 annotations already declare read-only, idempotent, and non-destructive behavior. The description adds a useful behavioral caveat: RTR and SWI have fewer or no live channels, so an empty or short result is expected, and it surfaces the dependency on srgssr_epg_get_programs.

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

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

The main statement is one concise sentence, followed by compact, well-structured tags for use case, caveat, and example. There is no filler or repetition; every element earns its place.

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

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

For a single-parameter read-only tool with an output schema and strong annotations, the description covers what the tool does, when to use it, an important business-unit caveat, and an example. Nothing needed to select or invoke it correctly is missing.

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

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

The input schema fully documents business_unit with an enum and a description, so the example (business_unit='srf') is helpful but adds little new semantic meaning. Since the schema carries the parameter burden, this is a solid baseline rather than an exceptional contribution.

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

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

The description states the specific operation ('Listet alle Live-TV-Sender...') and the scope ('einer SRG SSR Unternehmenseinheit'), making it clear what resource is returned. It also distinguishes this tool from siblings like srgssr_audio_get_livestreams and srgssr_video_get_shows.

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 use_case explicitly frames this as the live-stream selection step and prerequisite for srgssr_epg_get_programs, which needs a channel_id. It lacks explicit when-not-to-use guidance against the audio or on-demand siblings, but the main usage 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 establish readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: the API groups shows by first letter, omitting character_filter triggers 27 merged queries, and page_size applies per letter. This discloses a significant performance behavior without contradicting any annotation.

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

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

The description is compact, front-loaded with the verb+resource statement, and efficiently organized into use case, important notes, and example. Every sentence contributes useful information, especially the 27-request warning, with no padding or 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?

For a list-only tool with annotations and an output schema, the description covers the non-obvious behavior that an agent needs to invoke it correctly: optional letter filtering, per-letter pagination, request-count implications, and the sibling to use for episodes. Nothing essential is missing.

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

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

Although schema description coverage is low, the description compensates well for the key parameters: it explains the behavioral impact of character_filter, notes that page_size is per letter, and provides a concrete example with business_unit='srf' and character_filter='t'. It does not add semantic depth for page, but schema defaults and titles cover its basic usage.

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 ('Listet') and resource: TV shows of an SRG SSR business unit, including title, ID, and description. The use case tag ('Katalog-Browsing für TV-Sendungen') makes the tool's role clear and distinguishes it from audio/video 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 important_notes give explicit guidance: without character_filter, 27 requests are executed and should only be made when the whole catalog is truly needed; with character_filter, a single request is made. It also routes episode lookups to srgssr_video_get_episodes via show_id, which is direct when-to-use versus alternative 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, idempotentHint=true, and destructiveHint=false. The description adds non-annotated behavioral context: the Swiss-only coordinate bounds, the recommendation to use geolocation_id from srgssr_weather_search_location, and the data fields returned. No contradiction with annotations; the description complements them 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 main sentence is dense and informative, and the use_case, important_notes, and example are cleanly separated with XML tags. Every section contributes operational value (purpose, scenarios, constraints, example) and there is no filler or 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 and annotations already cover safety properties, the description supplies the remaining practical context: use cases, geographic restrictions, and a tool relationship. It is complete enough for correct invocation; minor details like measurement units are not necessary for calling the tool successfully.

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 reported as 0% at the top level, though nested properties do have descriptions. The description compensates by providing a concrete coordinate example (Zürich) and the valid lat/lon ranges, and it clarifies the source of geolocation_id. It does not explain the 'params' wrapper or elaborate on parameter types beyond what the schema already contains, so coverage is moderate rather than comprehensive.

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 'Liefert' and a precise resource: 'aktuelle Wettersituation von SRF Meteo für einen Schweizer Standort', followed by the returned data fields. The term 'aktuelle' plus the listed siblings (forecast_24h, forecast_7day) make the distinction between current weather and forecasts clear without needing to inspect schemas.

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

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

The <use_case> section explicitly lists suitable scenarios (outdoor activities, traffic reports, energy forecasts, editorial enrichment), and the <important_notes> section gives a geographic boundary and recommends geolocation_id from srgssr_weather_search_location. It does not explicitly say 'use forecast tools for future conditions', but the sibling names and 'aktuelle' strongly imply the boundary.

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, and destructiveHint=false, establishing a safe read-only operation. The description adds valuable behavioral constraints: it works only for Swiss coordinates (latitude/longitude ranges) and returns at most 24 hourly data points. It also notes that geolocation_id can be omitted and will be resolved from coordinates. These details go beyond the annotations and help the agent set expectations.

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

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

The description is compact and front-loaded: the core purpose is in the first sentence, followed by clearly structured XML-style tags for use cases, important notes, and an example. There is no redundancy or filler; every section adds distinct value. This is an exemplary structure for a tool description.

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 input schema and an output schema, the description covers the essential context: geographic constraints, data point limit, and a usage example. It does not mention units, timezone, or the exact response format, but those are likely defined in the output schema. The description is sufficiently complete for an agent to call the tool correctly and interpret the results, though a note about timezone could have been included.

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

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

Schema description coverage is 0%, meaning the description does not repeat parameter explanations. However, the input schema itself provides detailed descriptions for latitude, longitude, and geolocation_id, so the agent can rely on the schema. The description adds a concrete example (latitude=47.3769, longitude=8.5417) which illustrates usage but does not explain parameter semantics beyond that. Since the schema already covers the parameters thoroughly, a score of 3 is appropriate, though the description could have added a note about the optional geolocation_id resolution.

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

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

The description states the tool's purpose clearly: it delivers the hourly weather forecast for the next 24 hours from SRF Meteo. The verb 'Liefert' and the specific resource 'Wettervorhersage der nächsten 24 Stunden' are explicit. It distinguishes from siblings like srgssr_weather_current (current weather) and srgssr_weather_forecast_7day (7-day forecast) by the time frame, and from srgssr_weather_search_location by purpose.

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

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

The use_case tag provides practical contexts (Tagesplanung, Veranstaltungsorganisation, kurzfristige Wetterwarnungen) that indicate when this tool is appropriate. It does not explicitly compare with alternatives or state when not to use it, but the use cases and the time-frame specificity offer clear guidance for selection. The important_notes also constrain valid input, which indirectly guides usage.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: the reliability drop-off (Tage 1–3 vs. 5–7) and the geographic limitation to Switzerland. This exceeds the baseline given 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 compact and well-structured with a clear main sentence followed by tagged use_case, important_notes, and example sections. Each part earns its place, and the most critical information (what it does, Swiss scope, reliability) is front-loaded. No 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 description covers the main purpose, use cases, key constraints, and provides an example. Since an output schema exists, return-value details are not needed in the description. It lacks explicit differentiation from the 24h forecast tool, but the 7-day scope makes that implicit. Overall, an agent can call this tool correctly with the provided information.

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

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

Schema description coverage is 0% for the top-level param, but the nested properties have descriptions. The tool description provides an example with concrete latitude/longitude values and notes the Swiss location constraint, which partially compensates for the low coverage. However, it does not explain the optional geolocation_id parameter or specify units for temperature/precipitation, so it doesn't fully compensate.

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

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

The description states a specific verb ('Liefert') and resource ('tägliche Wettervorhersage der nächsten 7 Tage von SRF Meteo') with concrete data fields (Min/Max-Temperatur, Niederschlag, Wetterlage). It clearly distinguishes from siblings like srgssr_weather_forecast_24h and srgssr_weather_current by specifying the 7-day horizon.

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 use_case section provides clear contexts (Wochenplanung, Tourismus-Empfehlungen, Trendanalysen) and the important_notes gives constraints (only Swiss locations, reliability window). However, it does not explicitly mention alternatives or when not to use this tool versus siblings, so it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable context beyond annotations: it explains that the geolocationId improves forecast quality compared to coordinates, and reiterates the Swiss scope. It does not contradict annotations and provides useful operational nuance.

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 use_case, important_notes, and example sections. Every part serves a purpose: the core sentence states functionality, use_case gives context, important_notes adds scope and benefit, and examples clarify parameter values. It's slightly longer than necessary but remains efficient and front-loads the core purpose.

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

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

For a single-parameter search tool with an output schema (not shown), the description is complete: it explains what it returns (list with geolocationId), when to use it, the Swiss scope, and gives concrete examples. An agent has everything needed to invoke it correctly and interpret its role in the forecast workflow.

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 signal reports 0% schema description coverage, the schema actually includes a description for the query property. The tool description reinforces the format with examples (query='Zürich', '8001', 'Lausanne') and explicitly mentions 'Name oder Postleitzahl'. This compensates well for any perceived coverage gap and clarifies acceptable input patterns beyond the regex.

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

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

The description clearly states a specific action (search Swiss locations), the resource (weather forecast locations), and the output (list with geolocationId). It distinguishes itself from sibling weather tools by explicitly positioning itself as the first step to obtain a precise geolocationId before calling forecast tools. No ambiguity.

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

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

The use_case tag explicitly says this is the first step before srgssr_weather_current, srgssr_weather_forecast_24h, or srgssr_weather_forecast_7day to get the precise geolocationId. This gives clear when-to-use guidance and names the alternatives. The important_notes also sets scope (Swiss locations only), preventing misuse for non-Swiss queries.

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