rotv-mcp

Personal Entertainment Concierge — decide for me

tv_concierge

Read-onlyIdempotent

You have a window of free time — decide for me what to watch right now. Returns ONE primary decision (TV program OR streaming title) with confidence percentage, plus best_by_source when both TV and streaming were considered (the best TV airing in the window next to the best catalog title — present both to the user when gap_pct is small, since streaming is available any time and TV only now), full reasoning breakdown, and up to 3 diverse alternatives with explicit trade-offs (pros/cons, reason not picked). Picks across live Romanian TV EPG AND streaming catalog (Netflix, HBO Max, Disney+, Prime Video, Apple TV+, SkyShowtime). Built-in anti-noise filter automatically removes news, political talk, reality shows, talk-shows (NO manual filtering needed by the model). Built-in title dedup (handles ~46% duplicate-airing ratio in TV EPG). Built-in opportunity-cost lookahead (flags better options just outside the window). Event-aware: major broadcasts (World Cup / Euro / Champions League / finals) get an importance boost in ranking AND are always listed in the important_today field, even when the mood-based pick is something else — for questions like "what is important today?", prefer tv_important_today. PREFER THIS TOOL over tv_recommend_by_mood and tv_recommend_today whenever the user wants ONE answer / a single decision — those tools return ranked LISTS for browsing, this tool returns a DECISION. It returns exactly ONE pick and leaves the rest of the window as a pause: when the user wants the whole window FILLED with several programmes in sequence ("plan my evening", "ce văd toată seara", "fă-mi un program pentru 20–24", a TV window of 3+ hours), use tv_plan_evening instead. Routes any mood internally (obosit / vesel / concentrat / romantic / familie / captivant + EN aliases tired/happy/focused/romantic/family/thrilling). Trigger phrases: "what should I do", "decide for me", "pick for me", "I have X hours", "ce să fac", "am 2 ore", "alege tu", "mood X durată Y", "o singură decizie", "fii consilierul meu", "what to watch", "concierge me".

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mood`	No	obosit \| vesel \| concentrat \| romantic \| familie \| captivant (RO/EN aliases accepted)
`prefer`	No
`window`	No	Explicit window. Skips lookahead.
`sources`	No
`min_rating`	No	Hard minimum rating (0-10). When > 0, only titles with a MEASURED rating at or above it are eligible: streaming catalog rating, or the IMDb rating the TV guide declares. TV programmes without any rating (most sport, news, shows) are excluded, not waved through.
`allow_pauses`	No
`risk_aversion`	No	low = 3 alternatives, high = none	low
`duration_hours`	No	Shorthand when window is absent; starts at now.
`exclude_keywords`	No
`max_alternatives`	No
`exclude_categories`	No	Anti-noise filter (default: all four).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`reason`	No
`window`	Yes
`context`	Yes
`decision`	Yes
`freshness`	Yes
`lookahead`	Yes
`reasoning`	Yes
`anti_noise`	Yes
`alternatives`	Yes
`asked_at_utc`	Yes
`sources_used`	Yes
`best_by_source`	No
`important_today`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 1, 2026

addedInput schema / properties / min_rating / description

Added value: +"Hard minimum rating (0-10). When > 0, only titles with a MEASURED rating at or above it are eligible: streaming catalog rating, or the IMDb rating the TV guide declares. TV programmes without any rating (most sport, news, shows) are excluded, not waved through."

Changed1 schema field changedOct 1, 2026
- addedOutput schema / properties / best_by_source
```
Added value: +{
+  "$ref": "#/properties/window"
+}
```

Changed1 schema field changedJul 10, 2026

addedOutput schema / properties / important_today

Added value: +{
+  "items": {
+    "$ref": "#/properties/window"
+  },
+  "type": "array"
+}

First observedJul 8, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Goes well beyond the annotations: discloses built-in anti-noise filtering, title dedup (~46% duplicate-airing ratio), opportunity-cost lookahead, event-aware importance boosts, and that the result is exactly one pick plus up to 3 alternatives. It does not cover latency, data freshness guarantees, or failure modes. There is mild tension between the live-EPG/streaming sourcing and openWorldHint=false, but this is not a clear-cut contradiction.

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

Conciseness3/5

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

The core decision contract is front-loaded in the first sentence, which is good. However, the single dense paragraph packs in trigger phrases, domain trivia (Romanian EPG duplication ratio), and parenthetical asides that inflate length without helping tool selection; it would be stronger with separated when/when-not/behavior blocks.

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

Completeness4/5

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

An output schema exists, so return-field explanation is not strictly required, and annotations cover the safety profile. The description nevertheless supplies the routing logic, the decision-vs-list contract, and the pause/window semantics that an agent needs. Only the under-documented input parameters keep it from a 5.

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

Parameters3/5

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

Schema description coverage is only 55% across 11 parameters. The description clarifies mood routing (internal, with RO/EN aliases) and the meaning of max_alternatives through the 'up to 3 diverse alternatives' return description, but says nothing about prefer, exclude_keywords, allow_pauses, or sources. It therefore does not compensate for the coverage gap, landing at the baseline-plus level.

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

Purpose5/5

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

States a specific verb and resource ('decide for me what to watch right now', returns ONE primary decision) and explicitly contrasts itself with named siblings (tv_recommend_by_mood, tv_recommend_today return ranked lists, this returns a decision). An agent can distinguish it from all 13 siblings without opening a schema.

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

Usage Guidelines5/5

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

Explicit when-to-use ('the user wants ONE answer / a single decision'), explicit when-not ('when the user wants the whole window FILLED with several programmes... use tv_plan_evening instead'), and explicit alternate routing ('for questions like "what is important today?", prefer tv_important_today'). Trigger phrases are enumerated in two languages.

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

All rotv-mcp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.