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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that episodes are in descending chronological order. No further behavioral traits (e.g., pagination, rate limits) are disclosed.

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 one main sentence plus structured tags for use case, important notes, and an example. It is efficiently front-loaded with the core action, though slightly more detail in the example could improve 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?

The output schema exists but is not shown; the description covers the core purpose and ordering. However, pagination behavior, error handling, and return format are not addressed, making it moderate for a tool with required parameters and pagination.

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 (only business_unit has a description in schema). The description provides a usage example but does not explain page_size or page parameters, which are left to the schema. More details on parameters would be beneficial.

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 the latest episodes of a radio show ('Ruft die neuesten Episoden einer Radiosendung ab') and provides a use case ('Auffinden konkreter Radiobeiträge oder Podcast-Folgen'). It distinguishes from sibling tools like srgssr_audio_get_shows and srgssr_video_get_episodes.

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 includes a use case tag and notes chronological ordering, but does not explicitly state when to use this tool over alternatives (e.g., srgssr_audio_get_shows or srgssr_video_get_episodes). 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 indicate the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context: that some business units yield fewer or no live channels and that the tool is a prerequisite for 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 description is well-structured with clear sections (use_case, important_notes, example). It is concise but covers essential details without 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 tool's simplicity, the output schema, and the rich annotations, the description provides all necessary context: purpose, usage guidelines, edge cases, and an example.

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 is fully defined in the schema with an enum and description. The description adds a practical example and a tip for choosing a unit that returns more results, enhancing the schema's meaning.

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

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

The description states the specific action: listing all live radio stations for a given business unit. It distinguishes from sibling tools by mentioning the video equivalent and the shows catalog.

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

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

The description explicitly tells when to use this tool (for live radio streams), when not to use it (use video for live TV), and names alternatives (srgssr_video_get_livestreams, srgssr_audio_get_shows). It also notes that RTR and SWI may have fewer results.

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, idempotent, and non-destructive behavior. The description adds meaningful behavioral context: channel_id is mandatory and sourced from a specific sister tool, shows are grouped by initial letter, without character_filter all 27 letters are queried and merged (vs a single query with filter), and audio catalogs often contain podcasts. This exceeds annotation coverage without contradicting it.

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 concise and well-structured with a main purpose, use_case, important_notes, and an example. Every section adds distinct value: purpose states the verb and resource, use_case gives context, important_notes capture non-obvious behavior, and example illustrates parameter usage. No fluff 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 tool's moderate complexity (pagination, letter grouping, dependency on another tool), the description covers the most critical aspects: channel_id requirement, letter-filter behavior, and podcast presence. It does not explicitly detail how pagination interacts with the merged 27-letter query, but the output schema exists, so return values are already specified. Overall it is sufficient for safe invocation.

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

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

The schema already describes business_unit, channel_id, and character_filter. The description adds value by explaining the character_filter's impact on query count/merging and clarifying that channel_id comes from srgssr_audio_get_livestreams. Page/page_size are not explained, but that is a minor gap given the schema presence and the tool's simplicity.

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?

Purpose is clearly stated as 'Listet Radiosendungen eines SRG SSR Radiokanals auf' (lists radio shows of a SRG SSR radio channel). It distinguishes from siblings by specifying audio shows per channel, and adds details about letter grouping and podcast inclusion that differentiate it from video show and episode tools.

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

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

Provides a clear use case ('Katalog-Browsing für Radio- und Podcast-Formate') and important notes about requiring channel_id from srgssr_audio_get_livestreams. It explains when to use the character_filter (single query) vs no filter (all 27 letters), but does not explicitly mention alternatives or exclusions, so it lacks a full 'when-not-to-use' statement.

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?

Describes parallel fetching (asyncio.gather) and graceful degradation with ToolErrorResponse in the event one source fails, providing behavioral context beyond the readOnlyHint/idempotentHint annotations. This sets accurate expectations for error handling and performance.

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 and important_notes sections, making it scannable. Every sentence adds value: purpose, rationale, limitations, and a concrete example.

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, use case, constraints (EPG only for specific units), failure behavior, and provides an example. Given that an output schema exists, the description adequately covers all essential behavioral and contextual aspects of the tool.

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

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

With 0% schema description coverage, the description compensates partially via a full example (business_unit='srf', channel_id='srf-1', etc.) and contextual notes about EPG availability for certain units. However, it does not explicitly explain each parameter's meaning, relying on inference from the example and tool purpose.

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 function: 'Aggregiertes Tagesbriefing: kombiniert die 24-Stunden-Wettervorhersage von SRF Meteo mit dem EPG-Tagesprogramm eines SRG SSR TV- oder Radiosenders.' It uses a specific verb (kombiniert) and names both integrated resources, distinguishing it from individual weather/EPG sibling tools.

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

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

Explicitly gives a use case ('«Wetter + Programm für heute Abend»: Abendplanung, redaktionelle Tages-Briefings') and explains that one call replaces two sequential roundtrips ('ein einzelner Tool-Call genügt statt zweier sequentieller Roundtrips'). It also notes an exclusion: EPG only for SRF, RTS, and RSI, guiding when not to use the 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 readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral context: the tool is only available for SRF/RTS/RSI (not RTR/SWI), channel_id must use hyphens (e.g., 'srf-1' not 'srf1'), and RTS radio channels use uppercase. This goes beyond annotations and helps avoid common errors.

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 clear tags: <use_case>, <important_notes>, and <example>. It front-loads the main purpose in the first sentence, then layers guidance. Each section is necessary and contributes to correct usage. The examples are particularly concise and helpful.

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 comprehensive for the tool's complexity. It covers purpose, use cases, availability constraints, channel_id formatting, known channels, and examples. Since an output schema exists, return values don't need to be described. The description fully prepares an agent to invoke 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?

The schema coverage is reported as 0%, so the description must compensate. It does: it explains the channel_id format, provides an extensive list of valid channel_id values per business unit and broadcast type, and gives concrete examples with business_unit, broadcast_type, channel_id, and date. This is far more useful than the bare 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 verb 'abrufen' (retrieve) and the resource: the complete EPG program schedule for an SRG SSR TV or radio station for a specific day. It is specific and distinguishes from sibling tools like video/audio/weather/polis, which are clearly different domains.

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 use case (TV/radio program previews, editorial tips) and important notes about availability, channel_id format, and known stations. It doesn't explicitly mention alternatives or when-not-to-use, but the sibling tools are obviously different, making the usage context sufficiently 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 indicate readOnly, idempotent, open world. The description adds historical range and filter options, but does not disclose pagination behavior or other traits 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 and uses structured XML tags for use case, notes, and example. It is efficient but could be slightly more compact.

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 and annotations, the description covers essential context: data range, filtering, and output fields. Pagination is implied by page_size but not explained.

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 descriptions are 0% covered. The description mentions filters for year and canton, and gives an example with year_from, but omits year_to, page_size, and page parameters, leaving gaps in understanding.

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 retrieves Swiss National Council, Council of States, and cantonal elections from the Polis system, specifying the output (date, name, ID). This is distinct from sibling tools like 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 provides use cases (historical analysis, journalism) and notes (data since 1900, filter by year and canton), but does not explicitly guide when to use this over alternatives like srgssr_polis_get_votations or clearly state 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 declare readOnlyHint=true and idempotentHint=true. The description adds that results are detailed and includes acceptance/rejection info, but does not reveal rate limits, auth needs, or pagination. Barely adds behavioral value 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 a single paragraph with clear XML tags for use case and important notes. Front-loaded with purpose. Slightly verbose but each section is justified.

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 that an output schema exists, the description does not need to detail return values. It covers prerequisites and use case. For a simple one-parameter read-only tool, this is largely sufficient.

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 0% (no description for parameters). The description mentions votation_id in the notes and provides an example ('votation_id='v1''), adding minimal meaning beyond the schema's pattern constraint. However, it does reinforce the parameter's role.

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 specific verbs ('Ruft ab') and clearly defines the resource ('detaillierte Resultate einer einzelnen Schweizer Volksabstimmung'). It lists output components (Ja/Nein-Anteile, Stimmbeteiligung, kantonale Ergebnisse), distinguishing it from sibling srgssr_polis_get_votations which lists votes.

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 states 'Vertiefte politische Analysen, Visualisierung kantonaler Unterschiede' and important_notes clarify prerequisite (requires votation_id from srgssr_polis_get_votations). No explicit when-not-to-use, but adequate for the tool's simplicity.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds meaningful behavioral details: data reaches back to 1900, canton filter resolves to locationid, year ranges map to multiple voting-day queries, and pagination uses page_size 1-100. 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 yet well-structured using use_case and important_notes sections. Every sentence adds value, and the example is a useful quick reference without unnecessary detail.

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 filtered list tool with an output schema, the description covers the purpose, use cases, filter semantics, pagination, performance caveats, and sibling exclusions. The AI agent has enough context to select and invoke this tool appropriately.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains the canton filter ('wird in eine locationid aufgelöst'), year filter ('in die Abstimmungstage'), pagination behavior, and provides a concrete example (year_from=2020, year_to=2024 | canton='ZH'). The page parameter is only implied, but overall semantics are adequately conveyed.

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 ('Ruft... ab') targeting Schweizer Volksabstimmungen und Referenden from the Polis system, and specifies what is returned (Datum, Titel, votation_id). It also differentiates from sibling tools like srgssr_polis_get_votation_results and srgssr_polis_get_elections.

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 identifies appropriate scenarios (historical analyses, journalistic research) and directs the agent to srgssr_polis_get_elections for elections. It also frames this tool as the first step for obtaining a votation_id, giving clear selection criteria.

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

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

Beyond annotations (readOnly, idempotent), the description adds behavioral details: episodes are in descending chronological order, pagination uses page_size 1–50, and returned data includes video IDs for the Pillarbox player. This enriches the annotation baseline without contradiction.

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

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

The description is well-structured with explicit tags (use_case, important_notes, example). Each section adds distinct value, and the first sentence gives the core purpose. 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?

For a read-only paginated list tool with an output schema, the description covers the essentials: purpose, key return fields, ordering, pagination limits, and a source for valid show_id. It feels complete for an AI agent to invoke 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?

With 0% schema description coverage, the description compensates by providing a concrete example (business_unit='srf', show_id='tagesschau') and a note on show_id provenance. It mentions pagination range but does not explicitly explain the 'page' parameter; still adequate for 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 clearly states the tool retrieves the latest episodes of a TV show, listing specific fields (title, date, duration, video ID). This verb+resource combination is specific and distinguishes it from sibling tools like srgssr_video_get_shows and srgssr_audio_get_episodes.

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 includes a use case ('Recherche zu konkreten Sendungsausgaben') and an explicit note that valid show_id comes from srgssr_video_get_shows. This provides context for when to use the tool, though it does not explicitly contrast with audio alternatives.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context (prerequisite for EPG, channel availability caveats) but does not disclose additional behavioral traits like rate limits, pagination, or authentication needs. With annotations covering safety, the description contributes moderate value.

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 (one line main statement plus three structured tags) with no fluff. The most critical information (purpose, use_case, important_notes, example) is front-loaded and clearly separated using XML-like tags. Every sentence 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?

Given the tool's simplicity (single parameter, output schema available, annotations thorough), the description covers all necessary aspects: purpose, usage context, caveats, and a concrete example. The use_case and important_notes provide actionable guidance beyond the schema and annotations, making it complete 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 provides a description for the only parameter business_unit ('SRG SSR Unternehmenseinheit: 'srf', 'rts', 'rsi', 'rtr' oder 'swi''), so schema coverage is effectively 100%. The description does not add new semantics beyond the schema. According to rubric, baseline is 3 when schema coverage is high.

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' (lists) and the resource 'alle Live-TV-Sender einer SRG SSR Unternehmenseinheit' (all live TV channels of a business unit). It distinguishes from sibling tools like srgssr_audio_get_livestreams (audio) and other video tools (episodes, shows) by specifying video livestreams. The use_case tag reinforces that this tool is a prerequisite for EPG, adding context.

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 includes explicit use_case guidance: 'Live-Stream-Auswahl, Voraussetzung für srgssr_epg_get_programs' indicates when to use the tool. Important_notes warns that RTR and SWI have few or no live channels, helping the agent avoid unnecessary calls. The sibling tool list shows audio livestreams are separate, providing comparison.

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

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

Beyond the read-only and idempotent annotations, the description discloses non-obvious behavior: the API groups shows by first letter, omitting character_filter triggers 27 queries, and page_size applies per letter. This performance and pagination context is highly valuable and not present in structured 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 with a concise main sentence, a use_case tag, important_notes tags, and an example. Every sentence adds meaningful information, and the crucial performance caveat is prominently placed. 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 (no need to describe return values) and annotations cover safety, the description fully covers the operational context: catalog browsing, performance trade-offs, filtering behavior, pagination, and a pointer to the related episodes tool. This is complete for a listing tool.

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

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

With schema description coverage reported as 0%, the description compensates thoroughly. It explains the character_filter parameter (letters or #, omission triggers all letters), clarifies page_size per-letter behavior, and gives a concrete example. Page is left to standard pagination defaults, but the critical parameters are richly explained.

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 lists TV shows of an SRG SSR business unit with title, ID, and description. It distinguishes from related tools by explicitly referencing episodes via srgssr_video_get_episodes and by the TV-specific scope versus audio/livestream 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?

It provides explicit use cases (catalog browsing, program analysis) and clear guidance on when to omit character_filter (full catalog, 27 queries) versus using it (single query). It also directs users to srgssr_video_get_episodes for episodes, effectively saying when not to use this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds useful behavioral context: geographic bounds (Latitude 45.8–47.9, Longitude 5.9–10.5) and the fallback behavior when geolocation_id is omitted (resolved from latitude/longitude). This goes beyond the annotations 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 with clear <use_case>, <important_notes>, and <example> tags. Every sentence contributes value, with no redundant filler.

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

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

The description covers the tool's purpose, use cases, geographic restrictions, and provides an example. It also notes the recommended source for geolocation_id. Since an output schema exists, return values are already structured. It lacks explicit mention of alternative forecast tools, but the completeness is adequate for a current-weather lookup.

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%, so the description must compensate. It provides an example (latitude=47.3769, longitude=8.5417) and recommends using geolocation_id from srgssr_weather_search_location, which adds context beyond the schema. However, it doesn't explain units or the meaning of each weather field, leaving the agent partially reliant on schema descriptions.

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

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

The description clearly states the tool's purpose: 'Liefert die aktuelle Wettersituation von SRF Meteo für einen Schweizer Standort' with a specific verb 'liefert' and lists the data fields (Temperatur, Wettercode, Wind, Niederschlag, Luftfeuchtigkeit). It distinguishes itself from sibling weather tools by emphasizing 'aktuelle' (current), contrasting with forecast tools.

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

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

The description provides a clear use case section (Echtzeit-Wetterabfragen für Outdoor-Aktivitäten etc.) and important notes specifying Swiss-only coordinates and recommending geolocation_id from srgssr_weather_search_location. It does not explicitly name alternatives or exclusions for forecast tools, but the current-vs-forecast distinction is implied.

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 the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context: the geographic bounds for Swiss locations and the limit of 24 hourly data points. This goes beyond the annotations and helps 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 well-structured using XML-like tags (use_case, important_notes, example). Each sentence or section serves a distinct purpose, and no filler or repetition exists.

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 combination of annotations, output schema, and description covers the tool's behavior well for a read-only weather forecast: it specifies the data source, time horizon, geographic limits, and provides an example. It lacks details on error handling for out-of-bounds coordinates or response format, but the output schema exists to cover the latter.

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 does not explain the parameters itself, but the input schema has detailed descriptions for latitude, longitude, and geolocation_id. The description adds an example (latitude=47.3769, longitude=8.5417) and reinforces the coordinate range, which provides minimal added meaning beyond the schema.

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

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

The description clearly states the tool returns an hourly weather forecast for the next 24 hours from SRF Meteo. This specific resource and time frame distinguishes it from sibling tools like srgssr_weather_current and srgssr_weather_forecast_7day.

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 clear context for when to use the tool (daily planning, event organization, short-term warnings). However, it does not explicitly exclude alternatives or mention when to use the current or 7-day forecast, so it stops short of full 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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context: the 7-day limit, decreasing reliability for days 5–7, and Switzerland-only support. These are not implied by 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 short, front-loaded with the main purpose, and uses structured <use_case> and <important_notes> tags to organize supplementary information without redundancy. Every sentence 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?

The description covers the core function, use cases, limitations, and an example. Since an output schema exists, the return format is already specified. It does not mention error scenarios or geocoding fallback, but for a forecast tool with good schema coverage, 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?

The schema provides descriptions for all parameters (latitude, longitude, geolocation_id), so the description does not need to explain them. The example in the description ('latitude=47.3769, longitude=8.5417') offers a concrete usage hint but does not add meaning beyond the schema's own parameter descriptions. Baseline 3 applies.

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

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

The description uses a specific verb ('Liefert') and resource ('tägliche Wettervorhersage der nächsten 7 Tage von SRF Meteo') with concrete content (Min/Max-Temperatur, Niederschlag, Wetterlage). This clearly distinguishes it from siblings like srgssr_weather_current and srgssr_weather_forecast_24h.

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 appropriate contexts (Wochenplanung, Tourismus-Empfehlungen, Trendanalysen). The <important_notes> provides a key caveat about reliability (Tage 1–3 vs 5–7) and geographic restriction (Nur für Schweizer Standorte). However, it does not explicitly name alternative tools for when not to use it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable context: limited to Swiss locations (SRF Meteo) and that the geolocationId improves forecast quality. 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 concise, well-structured with <use_case>, <important_notes>, and <example> tags. Every sentence adds value, and the purpose 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?

For a simple search tool with one parameter and an existing output schema, the description covers purpose, usage guidelines, limitations, and examples completely. No 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 query parameter (Ortname oder Postleitzahl). The tool description adds examples (query='Zürich', '8001', 'Lausanne') and context on usage, enhancing meaning beyond the schema.

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

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

The description clearly states it searches for Swiss locations by name or zip code, returning a list with geolocationId. It uses a specific verb ('Sucht') and resource ('Schweizer Standorte'), and the <use_case> tag differentiates it from sibling weather tools.

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

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

The <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 geolocationId. This provides clear when-to-use and prerequisite context.

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