tvmaze-mcp-server

Tvmaze Get Next Episode

tvmaze_get_next_episode

Read-onlyIdempotent

Report when a show’s next episode airs, converted to a viewer timezone. Accepts a TVmaze id or a show title — a title is resolved with a stricter single-match search than tvmaze_search_shows uses. A show with no scheduled next episode is reported as a miss carrying its most recent episode, which is the normal state for a series between seasons.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`show`	No	The show the answer is about. Absent when the show itself could not be resolved.
`error`	No	Present when the call failed. Absent on success.
`found`	No	True when a next episode is scheduled.
`guidance`	No	What to do next when no next episode was returned. Absent on a hit.
`timezone`	No	IANA timezone the air times were rendered in.
`miss_reason`	No	Why no next episode was returned. "show_not_found" means the title or id resolved to nothing; "no_scheduled_episode" means the show exists but has nothing on the schedule.
`next_episode`	No	The next scheduled episode. Absent on a miss.
`previous_episode`	No	The most recently aired episode. Returned on a hit and on a "no_scheduled_episode" miss, so a between-seasons answer still says where the show left off.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 22, 2026

changedOutput schema / properties / next_episode / properties / local_date / description

Previous value: -"Calendar date the episode airs, in the requested timezone, ISO 8601 (YYYY-MM-DD)."New value: +"Calendar date the episode airs, ISO 8601 (YYYY-MM-DD). When time_known is true, the date in the requested timezone. When time_known is false, the source’s own announced air date, not timezone-converted — the same in every timezone."

changedOutput schema / properties / next_episode / properties / type / description

Previous value: -"Episode classification: \"regular\", \"significant_special\", or \"insignificant_special\". Anything other than \"regular\" is a special, and specials are excluded from a whole-run listing unless include_specials is set."New value: +"Episode classification: \"regular\", \"significant_special\", or \"insignificant_special\". Anything other than \"regular\" is a special; tvmaze_get_episodes leaves specials out unless include_specials is set."

changedOutput schema / properties / previous_episode / properties / local_date / description

Previous value: -"Calendar date the episode airs, in the requested timezone, ISO 8601 (YYYY-MM-DD)."New value: +"Calendar date the episode airs, ISO 8601 (YYYY-MM-DD). When time_known is true, the date in the requested timezone. When time_known is false, the source’s own announced air date, not timezone-converted — the same in every timezone."

changedOutput schema / properties / previous_episode / properties / type / description

Previous value: -"Episode classification: \"regular\", \"significant_special\", or \"insignificant_special\". Anything other than \"regular\" is a special, and specials are excluded from a whole-run listing unless include_specials is set."New value: +"Episode classification: \"regular\", \"significant_special\", or \"insignificant_special\". Anything other than \"regular\" is a special; tvmaze_get_episodes leaves specials out unless include_specials is set."

First observedSep 20, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds valuable behavior beyond that: timezone conversion, stricter title matching, and the miss state when no next episode is scheduled. Explaining that the miss carries the most recent episode is especially useful for interpreting results between seasons.

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

Conciseness5/5

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

The description is three tightly written sentences with no filler. The core action is front-loaded, and each subsequent sentence adds distinct value: lookup modes, resolution behavior, and edge-case behavior.

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

Completeness5/5

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

For a read-only lookup tool with an output schema present, the description covers all essential operational details: input identification, timezone behavior, and the no-schedule edge case. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the parameters are fully documented structurally. The description nonetheless adds semantic meaning by explaining the difference between the id and title branches and clarifying that title lookup uses a stricter match than tvmaze_search_shows, which helps the agent choose correctly.

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?

The description opens with a specific verb and resource ('Report when a show’s next episode airs') and immediately conveys the tool's scope. It also differentiates itself from tvmaze_search_shows by noting the stricter single-match title resolution, 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.

Usage Guidelines4/5

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

It clearly establishes when the tool is appropriate: whenever the next episode and air time are needed, identified by either id or title. It references tvmaze_search_shows as an alternative for title matching, though it does not explicitly contrast with tvmaze_get_episodes or tvmaze_get_schedule.

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

All tvmaze-mcp-server 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.