rotv-mcp

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

No annotations provided, but the description discloses staleness criteria (1.5× expected refresh interval) and names the three sources. It implies a read-only operation without side effects, and does not contradict any 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, information-dense sentence that efficiently lists all output fields. While effective, it could be slightly more structured for readability.

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

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

For a simple reporting tool with one optional parameter and an output schema, the description covers the key outputs. It does not discuss error conditions or when staleness is critical, but is otherwise complete.

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

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

Schema coverage is 100% with a well-described enum parameter. The description adds no additional meaning beyond the schema, so baseline score of 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 tool reports last-updated times, age, next refresh, and staleness for three specific data sources. This differentiates it from sibling tools which focus on content recommendations or scheduling.

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

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

The description implies usage for checking data freshness but does not explicitly state when to use this tool versus alternatives, nor does it provide prerequisites or 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?

No annotations provided, so description bears full burden. It discloses key steps (scoring, finding airing, streaming lookup) but does not mention behavior when no airing found, rate limits, or whether it is read-only. Lacks some behavioral traits for a comprehensive understanding.

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?

Two concise sentences front-load the action: 'Compares 2-5 program titles by scoring each against the chosen mood, finding the next TV airing...' No waste; every phrase 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?

Has output schema (not shown), so return values are covered. Description covers main functionality but could mention prerequisites like availability of TV data. Overall complete given tool complexity.

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

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

Schema description coverage is only 25% (one property described). The description adds meaning by explaining 'mood' is used for scoring, 'options' are titles/objects, and 'upcoming_window_hours' defaults to 48h. It does not detail 'prefer', but compensates for low schema coverage.

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

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

Description clearly states the tool compares 2-5 program titles by scoring against mood, finding next airing, and looking up in streaming catalog, returning side-by-side breakdown and winner. This is specific and distinguishes from siblings like tv_recommend_by_mood or tv_search_program.

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

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

The description implies usage for comparing multiple programs side-by-side, but does not explicitly state when to use this over alternatives (e.g., tv_get_title_details for single programs) or when not to use it. No exclusions or alternative suggestions are given.

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 built-in anti-noise filter, title dedup, and opportunity-cost lookahead, which are key behavioral traits beyond the schema. Could mention it is a read-only operation.

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

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

Well-structured with clear sections but quite verbose, including a list of trigger phrases that could be shortened.

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 main purpose, use cases, internal logic, and output shape; lacks edge cases like when no options found.

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?

Adds context for mood aliases, window behavior, risk_aversion, but does not systematically cover all 11 parameters; schema coverage is 45%, description partially compensates.

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

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

The description clearly states it returns ONE primary decision with confidence and trade-offs, and distinguishes itself from siblings by specifying it returns a decision vs ranked lists.

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 advises preferring this tool over three siblings when user wants a single decision/specific window, and provides trigger phrases. Does not 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?

No annotations provided, so description carries full burden. It lists detailed return components: per-component value, reasons, genres, streaming cross-ref, freshness, sources, and alternatives dropped with reasons. This fully discloses behavior 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?

Two sentences, first provides purpose. Second is long but lists return items. Could be more structured, but is efficient and 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?

Given output schema exists, description need not detail return values, but still lists key outputs. It covers usage context and parameters fairly well. Missing error handling or prerequisites, but acceptable for a read tool.

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

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

Schema description coverage is 75% with 3 of 4 parameters described (title, channel, start_utc). The context object has no description in schema, but tool description mentions 'mood/context', adding some meaning. However, context sub-parameters (mood, prefer, timeframe) remain undocumented, so description only partially compensates.

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

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

Description clearly states 'Returns a full score breakdown for a specific program', specifying verb and resource. It distinguishes from siblings like tv_recommend_by_mood or tv_get_title_details by focusing on explanation/debugging.

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

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

Explicitly says 'Use to understand or debug a recommendation', providing when to use. Does not mention when not to use or alternatives, but context signals from sibling names imply use is for explanation, not recommendation.

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

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

With no annotations, the description provides substantial behavioral details: default fairness algorithm (strict), auto-fallback to average with degraded flag, and return of per-person score breakdown and compromise note. This gives a clear understanding of tool behavior.

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 (three sentences) and front-loaded with purpose, then details. Each sentence adds essential information without redundancy or unnecessary 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?

For a complex tool with many parameters and an output schema, the description covers core logic, fallback, and returned details. It does not mention parameter defaults beyond fairness, but the schema covers those. It could mention prerequisites but is largely complete.

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

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

The description adds meaning for the fairness parameter (explains default and fallback) beyond the schema's enum. However, schema coverage is low (29%), and the description does not clarify other parameters like limit, min_score, timeframe, or include_streaming_xref, leaving gaps.

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 finds TV programs for two people with different moods/preferences. It includes specific details about fairness algorithms and fallback behavior, and it implicitly distinguishes from sibling tools that target single users (e.g., tv_recommend_by_mood).

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

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

The description explains the tool is for couples and describes default behavior and fallback. However, it does not explicitly state when not to use this tool or mention alternatives like tv_recommend_by_mood for single users, which would help differentiate.

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

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

With no annotations, the description fully discloses behavior: time range, timezone, grouping by channel, and default news exclusion. No contradictions. However, it does not specify data freshness or return format, but output schema covers the latter.

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

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

Three efficient sentences: core function, usage examples, notable default. Front-loaded, no redundant words, 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 simple functionality and presence of output schema, the description covers key aspects: time frame, timezone, grouping, and default. Minor gap: no explicit mention of scope parameter's effect, but schema covers it. Overall adequate.

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 (33%). The description adds value by noting default news exclusion (aligning with exclude_news) and implies date usage, but does not explain the scope parameter. Parameters are partially described, missing full compensation for the coverage gap.

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 function: 'Returns the prime-time lineup (20:00–23:00 Europe/Bucharest) for a given date, grouped by channel.' It specifies a specific verb and resource, with time range and timezone. It is easily distinguishable from sibling tools like tv_now_on_tv (current) or tv_search_program (search).

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

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

The description provides explicit query examples: 'Use for queries like "what is on prime time tonight" or "tomorrow night TV".' This gives clear context for when to use the tool, though it does not mention alternatives or 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?

No annotations are provided, so the description carries the full burden. It discloses that it looks up upcoming Romanian TV airings (default 48-hour window) and streaming catalogs. However, it does not mention if there are any side effects, rate limits, or what happens if the title is not found. A read-only hint would be useful.

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

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

The description is two sentences long, with the first explaining the core functionality and the second providing concrete examples. It is front-loaded and contains no redundant or unnecessary information.

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 (not shown but indicated), the description does not need to detail return values. It adequately covers purpose, parameters, and examples. However, it could mention whether partial matches or no results are handled, but overall 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?

Schema coverage is 100%, so baseline is 3. The description adds context by specifying default values (48 hours) and listing streaming services (Netflix, HBO Max, etc.), which is helpful beyond the schema descriptions. This additional context justifies a score of 4.

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

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

The description clearly states the tool looks up a title across upcoming Romanian TV airings and streaming catalogs, with explicit examples like 'is Avatar on Netflix?' and 'when does Game of Thrones air next?'. It distinguishes from sibling tools by specifying the Romanian context and specific streaming services.

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 example queries that illustrate when to use the tool, such as checking streaming availability or next TV airing. However, it does not explicitly state when not to use it or compare to alternatives like tv_search_program or tv_recommend_by_mood, which could overlap.

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?

No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as data freshness, caching, or any restrictions beyond the scope. The description is adequate but lacks depth on behavior.

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?

Two sentences, front-loaded with the action, no unnecessary words. Very efficient and easy to parse.

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

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

Given the presence of an output schema, the description does not need to explain return values. It covers the core use case and scope customization adequately. It explicitly mentions Romanian TV, making the domain clear.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the scope enum with counts ('14 main channels' vs 'full 254-channel list'), which goes beyond the schema. Other parameters are already well-documented in the schema.

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

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

The description clearly states 'Returns the programs currently broadcasting on Romanian TV channels.' with a specific verb and resource. It also provides an example question ('What is on TV now?') and distinguishes from siblings like tv_search_program and tv_get_prime_time.

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 tells when to use it ('Use this for 'What is on TV now?' type questions.') and notes the default scope and how to get the full list. It does not explicitly mention when not to use it or alternative tools, but the context is clear.

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

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

No annotations are provided, so the description carries the full burden. It describes the plan structure and output format but does not disclose behavioral traits such as whether the plan is generated from actual TV schedules, if there are any side effects, or how the algorithm handles conflicts (e.g., overlapping 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?

Two sentences with clear front-loading of purpose, then a list of inputs and outputs. No verbose or redundant phrasing.

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 7 parameters and an output schema, the description provides a reasonable overview but lacks details on how mood affects selections, handling of channel preferences, and the meaning of max_gap_min. The output schema may cover return values, but the description could be more complete about algorithmic behavior.

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 only 14% (only 'start' has a description). The tool's description lists a few parameters ('start time, duration budget, mood, and channel preferences') but does not explain constraints for parameters like max_gap_min, max_segments, or allow_channel_switch. Many parameters remain undocumented.

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

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

Description clearly states the verb 'builds' and the resource 'coherent TV watching plan for an evening,' with specifics on structure (one long program or 2-3 segments). This distinguishes it from sibling tools that focus on recommendations without planning (e.g., tv_recommend_by_mood, tv_recommend_today).

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?

Description implies usage when a concrete plan with time constraints is needed, but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. No when-not or alternative guidance is given.

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?

No annotations are provided, so the description bears full burden. It explains the ranking factors (channel category, mood-fit, time proximity, streaming cross-reference) and mentions output includes mood_parts and freshness. However, it does not disclose side effects, destructive potential, permissions needed, or limitations (e.g., only Romanian content). The description is adequate but not comprehensive.

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 consists of two concise sentences that are front-loaded with the main purpose. Every phrase adds value—first sentence states core function, second explains ranking components and output. No redundant words or filler.

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

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

With 7 parameters and an output schema, the description provides a good overview but leaves gaps. It mentions 'mood_parts' and 'freshness embedded' without defining them, and doesn't explain how parameters like dislike_genres or include_streaming_xref affect results. The output schema may cover return values, but the interaction between parameters remains unclear.

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 43%, so the description needs to compensate. It adds value by describing the ranking algorithm and synonyms for mood (obosit/vesel/…). For prefer, it says 'additive boost', and for timeframe, it references time proximity. However, limit, dislike_genres, dislike_keywords, and include_streaming_xref are not explained beyond the schema. The high-level overview helps but lacks detail for uncovered 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 'Returns top-N Romanian TV programs ranked for a given mood', specifying the verb (returns), resource (Romanian TV programs), and selection criterion (mood). It distinguishes from siblings by focusing on mood-based recommendation, unlike tv_recommend_today or tv_now_on_tv.

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 no guidance on when to use this tool versus alternatives. Given 12 sibling tools, there is no indication of when mood-based ranking is preferred over other recommendation strategies. No 'use this when...' or 'for alternative use...' phrasing.

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?

No annotations are provided, so the description carries full burden. It discloses that the tool uses a deterministic scorer, rewards films/documentaries/generalist channels, penalises news, and boosts programs starting within the next hour. However, it does not discuss behavior for past times or data freshness.

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 three sentences long, front-loaded with the core purpose, then details the scorer, and ends with example queries. Every sentence adds value 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 that an output schema exists (not shown but indicated), the description need not explain return values. It covers purpose, usage guidance, and scoring logic sufficiently. However, it could briefly mention the output format (program names, channels, times) for immediate clarity.

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

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

With schema description coverage at 75%, baseline is 3. The description adds incremental value by explaining how parameters like 'prefer' and 'exclude_news' affect the scoring (rewards certain categories, penalises news). This provides context beyond the schema's parameter 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 returns ranked program recommendations for a given timeframe. It uses specific verbs ('returns', 'recommend') and resource ('program recommendations'). It distinguishes from siblings like tv_recommend_by_mood (different criteria) and tv_search_program (search vs recommend).

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

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

The description provides explicit example queries ('recommend me something for tonight', 'ce e bun la TV diseară') and explains the scoring logic (rewards films/documentaries, penalises news, boosts near-starting programs). It implies usage for recommendation needs but does not explicitly state when not to use or mention alternative siblings.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects. The description focuses only on functionality without behavioral context.

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?

Two sentences plus examples, no filler. The main purpose is front-loaded, and every sentence adds value. The examples are specific and concise.

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

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

The tool has 6 optional parameters and an output schema. The description covers the main filters and acceptable time references. It could be enhanced by explaining interaction between channel and category filters, but it is largely complete for a search tool.

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

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

Schema description coverage is 67%. The description adds useful detail for the timeframe parameter (accepted natural language references). Other parameters have schema descriptions already, so the description offers limited additional value. Baseline 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 tool searches programs across all 254 Romanian TV channels with specific filters (title, channel, category, time window). It provides concrete examples that differentiate it from sibling tools like tv_recommend_by_mood or tv_find_for_couple.

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?

Examples illustrate appropriate use cases (e.g., 'documentaries on Discovery tomorrow'). The description does not explicitly state when not to use or name alternatives, but the examples and context signal that this is the general search tool among more specialized siblings.

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