A
licenseNot graded
qualityB
maintenanceEnables searching TV show metadata, episodes, and schedules via the TVMaze API with no authentication required.
10 npm
MIT
tvmaze-mcp-server
Server Details
TVmaze shows, people, next episodes in your timezone, episode guides, schedules, and credits.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 99.9% over 41 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cyanheads/tvmaze-mcp-server
- GitHub Stars
- 1
- Server Listing
- tvmaze-mcp-server
TDQS
A4.2/5.0
Scored across 8 tools
Disambiguation4/5
Each tool targets a distinct resource or query axis, and the descriptions explicitly disambiguate the three show-resolution paths (get_show by id, lookup_show by external id, search_shows by title). Minor overlap exists between airing-related tools (get_next_episode, get_schedule, get_episodes), but the descriptions clearly define their boundaries.
Naming Consistency5/5
Every tool uses a consistent tvmaze_ prefix followed by a predictable verb_noun pattern (get_cast, get_episodes, lookup_show, search_shows). No deviations in case or verb style across the set.
Tool Count5/5
Eight tools is well-scoped for a read-only TV data server, with each tool earning its place by covering a distinct access pattern (show, episode, cast, person, schedule, search, lookup).
Completeness4/5
The surface covers show discovery, cross-catalog lookup, profiles, episode lists, cast/crew, person credits, scheduling, and next-airing, which is solid lifecycle coverage for a read-only domain. Gaps are minor, such as no direct person-by-id lookup, but agents can work around these via search.
Available Tools
8 toolstvmaze_get_castTvmaze Get CastARead-onlyIdempotentInspect
List the credited cast of a show with the characters they play, optionally with crew; or list the guest cast of one episode, optionally with its guest crew such as the director and writers. Results are paged: cast rows come first, then crew rows, and each page splits them back into cast and crew. The source records no recurring-versus-guest distinction on a show’s cast list, so a name’s absence from it does not mean the performer never appeared — check an episode’s guest cast for that.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | Applied page size, at most 250; present when clamped or more rows remain. |
| cast | No | Cast credits on this page — for scope "show", the main cast; for scope "episode", that episode’s guest cast. Empty on a page past the last cast row. |
| crew | No | Crew credits on this page — for scope "show", the show’s crew; for scope "episode", that episode’s guest crew. Present, possibly empty, whenever include_crew was set; crew rows follow every cast row, so a page that ends inside the cast carries none. |
| error | No | Present when the call failed. Absent on success. |
| scope | No | Which credit list was returned. |
| shown | No | Number of credits returned on this page. |
| notice | No | Guidance when the page was truncated, or when no cast is recorded — every one that applies, joined. Absent otherwise. |
| has_more | No | True when more credits remain beyond this page. |
| truncated | No | True when more matching credits remain. |
| cast_total | No | Matching cast credits across every page. |
| crew_total | No | Matching crew credits across every page. Present when include_crew was set. |
| subject_id | No | TVmaze id the credits belong to — a show id or an episode id, matching scope. |
| totalCount | No | Matching credits across every page, cast plus crew. |
| next_cursor | No | Pass as cursor to fetch the next page. Absent on the last page. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower, and the description still adds non-obvious context: page composition is cast rows first then crew rows, and each page re-splits them, plus the source-data caveat that a show cast list carries no recurring-vs-guest distinction. The limit clamp and pagination mechanics live in the schema rather than here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each front-loaded with its purpose: capability first, then paging behavior, then the data-quality caveat. Dense but no filler, though the paging sentence ('each page splits them back into cast and crew') is slightly convoluted for the space it takes.
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?
Both mutually exclusive call shapes are described, the crew opt-in and its rationale are covered, pagination is explained, and the recurring-vs-guest caveat closes the main interpretive gap. With an output schema present, return-value details need not be restated, so nothing an agent needs to call this correctly is missing.
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 100%, so the schema already documents name, limit, cursor, scope, show_id/episode_id and include_crew in detail. The description reinforces the crew-gated filtering and paging semantics but adds no syntax or format meaning beyond what the schema provides, which is the baseline-3 case.
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 specific verbs and resources across both call shapes: 'List the credited cast of a show with the characters they play' and 'list the guest cast of one episode'. The show-vs-episode distinction is explicit, so an agent can tell this apart from tvmaze_get_show or tvmaze_get_episodes without opening the schema.
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?
Gives clear selection context: use show scope for a show's main cast, episode scope for an episode's guest cast, and include_crew only when crew is actually wanted. It also tells the agent to fall back to an episode's guest cast when a name is absent from a show list. No exclusions or explicit sibling routing (e.g. which tool to use for person data) are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tvmaze_get_episodesTvmaze Get EpisodesARead-onlyIdempotentInspect
List a show’s episodes with air times, runtimes, and synopses. Pass a season number to list one season, which is the cheaper path and the usual one; pass air_date to list the episodes dated to one day, the direct path to a single night of a daily show; omit both to walk the whole run, which is paged because a long-running series returns hundreds of episodes. Specials are excluded unless include_specials is set, and the number left out is reported.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum episodes to return in this call. Requests above 250 are clamped to 250. Applies to every page, including a call that passes cursor. Raise it for a short series; the default keeps a long run inside a reasonable response size. | |
| cursor | No | Continuation token from a previous call’s next_cursor. It carries only the position to resume from; the page size comes from limit. Omit for the first page. | |
| season | No | Season number to list, as numbered in the season list from tvmaze_get_show. Omit, together with air_date, to list every episode of the series. Daily shows number seasons by calendar year. | |
| show_id | Yes | TVmaze show id, from tvmaze_search_shows, tvmaze_lookup_show, or tvmaze_get_schedule. | |
| air_date | No | Date to list, ISO 8601 (YYYY-MM-DD): the episodes the source dates to that day. It matches the source’s airdate, the broadcaster’s own programming day, so on a late-night slot it can differ by a day from the local_date an episode reports. Cannot be combined with season. | |
| timezone | No | IANA timezone name for the air times, e.g. "America/Los_Angeles". Defaults to the server-configured timezone. | |
| include_specials | No | Include specials alongside regular episodes. Off by default because specials roughly double the result count on a series that has many; when off, notice reports how many were left out. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | Applied page size, at most 250; present when clamped or more rows remain. |
| show | No | The show the episodes belong to. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of episodes returned on this page. |
| notice | No | Guidance when the page was truncated, when nothing was recorded, or when specials were filtered out — every one that applies, joined. Absent otherwise. |
| season | No | Season number listed. Absent when the whole run or one air date was listed. |
| air_date | No | Air date listed, YYYY-MM-DD. Absent unless air_date was given. |
| episodes | No | Episodes in airing order. |
| has_more | No | True when more episodes remain beyond this page. |
| timezone | No | IANA timezone the air times were rendered in. |
| truncated | No | True when more matching episodes remain. |
| totalCount | No | Episodes matching before the page limit was applied. |
| next_cursor | No | Pass as cursor to fetch the next page. Absent on the last page. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, openWorld), so the description earns credit for adding what they cannot: specials are excluded by default and the number omitted is reported, and unfiltered listing is paged. It stops short of describing page-size interplay or what the response envelope looks like beyond the 'reported' count.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the purpose and then the parameter-mode routing; no filler or restated title. The final specials clause is somewhat tacked on but still carries new information.
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?
An output schema exists, so return values need not be explained, and annotations cover the safety profile. With paging, exclusions, and all three filtering modes covered, an agent has everything needed to invoke this correctly.
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 100%, so all seven parameters are already documented, including the season/air_date mutual exclusion and the limit clamp to 250. The description adds only the routing rationale (season is cheaper, air_date is direct), which overlaps heavily with what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb and resource ('List a show's episodes') with the returned fields stated (air times, runtimes, synopses), so the agent immediately knows what this yields. It does not name or contrast against its closest sibling, tvmaze_get_next_episode, nor explain how it differs from tvmaze_get_schedule, which also surfaces episode data.
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?
It explicitly routes the three modes: season for one season ('the cheaper path and the usual one'), air_date for a single night of a daily show ('the direct path'), and omitting both to walk the full run. It also warns that the full walk is paged and can return hundreds of episodes, which tells the agent when to prefer a narrower call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tvmaze_get_next_episodeTvmaze Get Next EpisodeARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output 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. |
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.
tvmaze_get_personGet personARead-onlyIdempotentInspect
Search people by name to return candidates, then select a person_id to list their cast, guest, or crew credits. Name searches never select a person automatically. Credits preserve source order and page at 50 rows by default, up to 250 per call; show_id chains to tvmaze_get_show or tvmaze_get_episodes, and guest episode_id chains to tvmaze_get_cast with scope "episode".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size for person_id only. Defaults to 50; requests above 250 are clamped to 250. | |
| query | No | Person name to search. Supply query or person_id, never both. Blank is unset. | |
| cursor | No | Previous next_cursor for person_id only; the current limit sets page size. | |
| person_id | No | TVmaze person id from tvmaze_get_cast or this tool’s candidates. | |
| credit_kind | No | Credit category for person_id only. Defaults to cast. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | Applied page size or possible source search ceiling. |
| kind | No | Search candidates or one selected person with credits. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Actual number of candidates or credits returned. |
| notice | No | Candidate selection, empty result, paging, and clamp guidance. |
| person | No | Selected person profile. |
| credits | No | Selected credits on this page, in source order. |
| has_more | No | Whether further credit rows remain. |
| truncated | No | More credits remain, or the source may have capped search candidates. |
| candidates | No | Name search candidates, in source order. Never automatically selected. |
| totalCount | No | Candidates returned by search, or total selected credits before paging. |
| credit_kind | No | Credit category returned for the selected person. |
| next_cursor | No | Continuation token for the selected credit list. |
| effectiveQuery | No | Trimmed person name searched. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world behavior, so the description is free to add operational detail it does provide: 'never select a person automatically', source-order preservation, default 50-row paging, and the 250-row clamp. That is genuine context beyond the annotations, though error/empty-result behavior is not covered.
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?
Two tight sentences with no filler: the first establishes the two-step workflow and the no-auto-select rule, the second packs pagination limits and downstream chaining. Every clause carries routing or behavioral information.
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?
Given an output schema exists, return-shape detail is unnecessary, and the description covers the multi-mode nature, pagination/clamping, ordering, and cross-tool chaining that an agent needs to call this correctly. Nothing material is missing for a 5-param read tool.
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 100%, so the schema already documents query/person_id mutual exclusion, cursor semantics, limit clamping, and the credit_kind enum. The description largely restates the paging and default-category behavior rather than adding new parameter meaning, so the baseline 3 applies.
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 states both operating modes precisely: name search returning candidates, and person_id lookup returning cast/guest/crew credits. It names specific verbs and resources and distinguishes itself from siblings by describing how its outputs route into tvmaze_get_show, tvmaze_get_episodes, and tvmaze_get_cast.
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 gives clear context for the query-vs-person_id decision and warns that name searches never auto-select a person, plus it names the downstream tools for each output field. It stops short of stating explicit exclusions (e.g., when to use tvmaze_get_cast directly instead of chaining through this tool), so it falls just short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tvmaze_get_scheduleTvmaze Get ScheduleARead-onlyIdempotentInspect
List television episodes airing on a given date. Scope "linear" covers broadcast and cable networks in one country; "streaming" covers streaming services — global services such as Netflix and Prime Video when no country is given, or that country’s local streaming services when one is. Scope "all" merges both. The source caches schedule data for up to an hour, so a same-day listing can lag a late change.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date to list, ISO 8601 (YYYY-MM-DD). Defaults to today in the requested timezone. | |
| limit | No | Maximum entries to return in this call. Requests above 250 are clamped to 250. Applies to every page, including a call that passes cursor. A full day in one country runs to roughly 50 broadcast entries and over 120 global streaming entries. | |
| scope | No | Which feed to read. "linear" is broadcast and cable networks; "streaming" is streaming services; "all" merges both and costs three upstream requests. | linear |
| cursor | No | Continuation token from a previous call’s next_cursor. It carries only the position to resume from; the page size comes from limit. Omit for the first page. | |
| channel | No | Exact channel name, case-insensitive, such as "Netflix". Filters before paging. Blank means all channels. | |
| country | No | ISO 3166-1 alpha-2 country code, e.g. "US", "GB", "JP". The United Kingdom is "GB". Required in effect for scopes "linear" and "all" — omitted, it falls back to the server-configured country. For scope "streaming", omitting it selects global streaming services rather than one country’s local ones. | |
| timezone | No | IANA timezone name for the air times, e.g. "America/Los_Angeles". Defaults to the server-configured timezone. Also decides what "today" means when date is omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | Applied page size, at most 250; present when clamped or more rows remain. |
| date | No | Date listed, ISO 8601 (YYYY-MM-DD). |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of entries returned on this page. |
| notice | No | Guidance when the page was truncated, when nothing is listed, or when one feed of a merged query did not respond — every one that applies, joined. Absent otherwise. |
| entries | No | Episodes airing on the date, earliest first. |
| has_more | No | True when more entries remain beyond this page. |
| timezone | No | IANA timezone the air times were rendered in. |
| truncated | No | True when more matching entries remain. |
| totalCount | No | Matching merged entry count before paging. |
| next_cursor | No | Pass as cursor to fetch the next page. Absent on the last page. |
| applied_feeds | No | Exactly which upstream feeds the results cover, e.g. ["linear:US"], ["web:global"], ["linear:GB","web:GB","web:global"]. |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and openWorld, so the safety profile is covered. The description adds genuinely non-obvious behavior: source data caches for up to an hour so same-day listings can lag real changes. It stops short of describing response shape or pagination beyond what the schema and output schema carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with the core purpose before the scope taxonomy and the caching caveat. Every sentence carries information; only the scope restatement slightly overlaps the schema.
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?
With an output schema present and 100% parameter coverage, the description's job is to add the non-structured context, which it does via scope semantics and the cache-lag warning. A note on country effectively being required for linear/all would have made it fully self-contained, though the schema does state this.
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 100%, including enum values, clamping behavior for limit, cursor semantics, country fallback rules, and timezone defaults, so the baseline is 3. The description's scope explanation largely restates the enum description, adding only the upstream-cost note for "all".
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource+scope: "List television episodes airing on a given date," with the scope dimension spelled out. It implicitly separates itself from tvmaze_get_episodes (episodes of one show) by being date-driven, but never names a sibling or explicitly frames the distinction, so it falls short of a 5.
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?
Gives clear guidance on when each scope applies — linear for broadcast/cable in a country, streaming for global vs local services depending on whether country is set, all to merge both. That is strong invocation guidance, but there is no when-to-use-this-vs-another-tool guidance (e.g. versus get_episodes or get_next_episode).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tvmaze_get_showTvmaze Get ShowARead-onlyIdempotentInspect
Fetch a television show by its TVmaze id: full profile, weekly broadcast slot, season list, and the previous and next episode when the source has them. This is the entry point for an id returned by tvmaze_search_shows or tvmaze_lookup_show. For the episode list itself use tvmaze_get_episodes, and for credits use tvmaze_get_cast.
| Name | Required | Description | Default |
|---|---|---|---|
| show_id | Yes | TVmaze show id, from tvmaze_search_shows, tvmaze_lookup_show, or tvmaze_get_schedule. | |
| timezone | No | IANA timezone name for rendering the previous and next episode air times, e.g. "America/Los_Angeles" or "Europe/London". Defaults to the server-configured timezone. |
Output Schema
| Name | Required | Description |
|---|---|---|
| show | No | Full show profile. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when a Running show has no scheduled next episode. Absent otherwise. |
| seasons | No | Every season TVmaze records, in order. Pass a season number to tvmaze_get_episodes. |
| timezone | No | IANA timezone the episode times were rendered in. |
| next_episode | No | The next episode scheduled to air. Absent when none is scheduled — a Running show between seasons has no next episode. |
| previous_episode | No | The most recently aired episode. Absent for a show that has not premiered. |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so safety and external-source behavior are covered. The description adds useful conditional phrasing ('when the source has them') that signals optional return fields and flags that this branches out to external data. It does not discuss error behavior for invalid ids, rate limits, or response shape, but the output schema exists to cover return values, so a 3 is appropriate.
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?
Two sentences, no repetition of name or title, and the routing information is front-loaded after the one-line scope statement. Every clause earns its place by either defining scope or steering to a sibling.
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 with an output schema and fully documented parameters, this definition is complete: it states what is fetched, when to use it, what siblings handle the rest, and that some fields may be absent. The only omission is error semantics, which is minor here.
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 coverage is 100% and both parameters have descriptive text, so the schema carries the parameter burden. The description adds only an implicit link between the timezone parameter and the previous/next episode air times, which is marginal beyond the schema wording. Baseline 3 applies when the schema is fully documented.
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 uses a specific verb ('Fetch') and resource ('television show') and enumerates exactly what comes back: full profile, weekly broadcast slot, season list, previous and next episode. It also names the sibling tools covering the adjacent capabilities (tvmaze_get_episodes, tvmaze_get_cast), so an agent can separate it from tvmaze_lookup_show and tvmaze_search_shows.
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?
It states an explicit entry condition ('the entry point for an id returned by tvmaze_search_shows or tvmaze_lookup_show') and names the alternatives for neighboring needs: episode lists go to tvmaze_get_episodes, credits to tvmaze_get_cast. Nothing is left to inference about when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tvmaze_lookup_showTvmaze Lookup ShowARead-onlyIdempotentInspect
Resolve a television show from its id in another catalog — IMDb, TheTVDB, or TVRage — and return the matching TVmaze profile. Use this to cross a show id from another source into TVmaze. A show absent from TVmaze is reported as a miss with guidance, not an error.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| show | No | The resolved show. Absent on a miss. |
| error | No | Present when the call failed. Absent on success. |
| found | No | True when the external id resolved to a TVmaze show. |
| source | No | Catalog the lookup was made against. |
| guidance | No | What to do next when the lookup missed. Absent on a hit. |
| external_id | No | Id looked up; IMDb ids use the canonical lowercase tt prefix and original digits. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered and the bar is lower. The description adds genuine value beyond them by specifying error semantics: a show absent from TVmaze 'is reported as a miss with guidance, not an error,' which tells the agent to expect a structured miss rather than a failure and not to abort a workflow.
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?
Three tight sentences with zero filler: the action and scope come first, then the when-to-use cue, then the edge-case behavior. Every sentence earns its place and nothing is buried at the end.
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 the return profile need not be described, and the description covers action, scope, usage cue, and miss behavior. The only gap is not naming sibling tools for TVmaze-native or title-based lookups, which would fully close the routing decision.
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 100% and each source variant documents its own id format and pattern, so the schema carries the parameter burden. The description names the three catalogs but adds no syntax or format detail beyond the schema's const/pattern definitions – baseline 3 is appropriate.
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 (resolve) plus resource (TV show) and, critically, the scope qualifier 'from its id in another catalog — IMDb, TheTVDB, or TVRage — and return the matching TVmaze profile.' This implicitly separates it from tvmaze_get_show (native TVmaze id) and tvmaze_search_shows (name search), so an agent can route without opening the schema.
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?
'Use this to cross a show id from another source into TVmaze' gives a clear triggering context. It stops short of naming the alternatives it is not (e.g., use tvmaze_get_show when you already hold a TVmaze id, or tvmaze_search_shows when you only have a title), so no explicit exclusion is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tvmaze_search_showsTvmaze Search ShowsARead-onlyIdempotentInspect
Search television shows by title and return up to 10 matches, each with its network or streaming service, production status, genres, rating, and ids in other catalogs. Matching is fuzzy, so small typos still resolve. The result set is hard-capped at 10 by the source and cannot be paged — narrow the title to reach an eleventh match. To go the other way, from an IMDb or TheTVDB id to a show, use tvmaze_lookup_show.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Show title or title fragment. Matched fuzzily against every show title in the database, so minor misspellings still resolve. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The result ceiling the source applied. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of shows returned. |
| shows | No | Matching shows, best match first. At most 10. |
| notice | No | Guidance when nothing matched or when the ten-result ceiling was reached. Absent otherwise. |
| truncated | No | True when the source's fixed ten-result ceiling was reached. |
| effectiveQuery | No | The query as submitted upstream. |
TDQS
A4.9/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 behavioral context on top: fuzzy matching behavior, the hard-capped result set, the lack of pagination, and the exact data fields returned. This goes well beyond what annotations alone provide and contradicts nothing.
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?
Three purposeful sentences: the first defines the operation and return value, the second covers matching and limits, and the third routes to the correct alternative. No filler, no repetition, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only search tool, this description is fully self-sufficient. It tells the agent what the tool does, what data it returns, its fuzzy behavior, its pagination limitations, and how to choose a sibling tool. The presence of an output schema means return-value details don't need to be restated.
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 description coverage is 100%, so the baseline is 3. The description adds an extra layer of guidance beyond the schema by explaining that narrowing the query is required to reach results beyond the hard cap, which gives the agent a strategy for using the query parameter effectively.
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: 'Search television shows by title', then enumerates exactly what each match returns. It also distinguishes itself from the sibling tvmaze_lookup_show by explicitly stating it handles the reverse direction, making tool selection unambiguous.
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?
The description provides clear usage context: it tells the agent this is the right tool for title-based fuzzy search and explicitly says to use tvmaze_lookup_show when starting from an IMDb or TheTVDB id. It also documents the practical constraint of the 10-result cap and the strategy of narrowing the title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
6 tool updates
- Changed
tvmaze_get_cast6 fields changed- changed
Input schema / oneOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "cursor": { - "description": "Continuation token from a previous call’s next_cursor. It carries only the position to resume from; the page size comes from limit. Omit for the first page.", - "type": "string" - }, - "include_crew": { - "default": false, - "description": "Also list the show’s crew credits — producers, creators, and other series-level roles, with no episode attribution. Off by default; a long-running series carries hundreds and they are rarely what a cast question is asking for.", - "type": "boolean" - }, - "limit": { - "default": 50, - "description": "Maximum credits to return in this call, cast and crew together. Applies to every page, including a call that passes cursor. A long-running series carries over a thousand cast credits.", - "maximum": 250, - "minimum": 1, - "type": "integer" - }, - "scope": { - "const": "show", - "description": "List the show’s main cast.", - "type": "string" - }, - "show_id": { - "description": "TVmaze show id, from tvmaze_search_shows, tvmaze_lookup_show, or tvmaze_get_schedule.", - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - } - }, - "required": [ - "scope", - "show_id" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "cursor": { - "description": "Continuation token from a previous call’s next_cursor. It carries only the position to resume from; the page size comes from limit. Omit for the first page.", - "type": "string" - }, - "episode_id": { - "description": "TVmaze episode id, from tvmaze_get_episodes, tvmaze_get_next_episode, tvmaze_get_schedule, or tvmaze_get_show.", - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - }, - "include_crew": { - "default": false, - "description": "Also list the episode’s guest crew — who directed and wrote it, as TVmaze credits them. Off by default.", - "type": "boolean" - }, - "limit": { - "default": 50, - "description": "Maximum credits to return in this call, cast and crew together. Applies to every page, including a call that passes cursor. A long-running series carries over a thousand cast credits.", - "maximum": 250, - "minimum": 1, - "type": "integer" - }, - "scope": { - "const": "episode", - "description": "List one episode’s guest cast.", - "type": "string" - } - }, - "required": [ - "scope", - "episode_id" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "cursor": { + "description": "Continuation token from a previous call’s next_cursor. It carries only the position to resume from; the page size comes from limit. Omit for the first page.", + "type": "string" + }, + "include_crew": { + "default": false, + "description": "Also list the show’s crew credits — producers, creators, and other series-level roles, with no episode attribution. Off by default; a long-running series carries hundreds and they are rarely what a cast question is asking for.", + "type": "boolean" + }, + "limit": { + "default": 50, + "description": "Maximum credits to return in this call, cast and crew together. Requests above 250 are clamped to 250. Applies to every page, including a call that passes cursor. A long-running series carries over a thousand cast credits.", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" + }, + "name": { + "description": "Case-insensitive substring in performer, character, or crew role. Blank means no filter; crew is searched only with include_crew.", + "type": "string" + }, + "scope": { + "const": "show", + "description": "List the show’s main cast.", + "type": "string" + }, + "show_id": { + "description": "TVmaze show id, from tvmaze_search_shows, tvmaze_lookup_show, or tvmaze_get_schedule.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "scope", + "show_id" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "cursor": { + "description": "Continuation token from a previous call’s next_cursor. It carries only the position to resume from; the page size comes from limit. Omit for the first page.", + "type": "string" + }, + "episode_id": { + "description": "TVmaze episode id, from tvmaze_get_episodes, tvmaze_get_next_episode, tvmaze_get_schedule, or tvmaze_get_show.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "include_crew": { + "default": false, + "description": "Also list the episode’s guest crew — who directed and wrote it, as TVmaze credits them. Off by default.", + "type": "boolean" + }, + "limit": { + "default": 50, + "description": "Maximum credits to return in this call, cast and crew together. Requests above 250 are clamped to 250. Applies to every page, including a call that passes cursor. A long-running series carries over a thousand cast credits.", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" + }, + "name": { + "description": "Case-insensitive substring in performer, character, or crew role. Blank means no filter; crew is searched only with include_crew.", + "type": "string" + }, + "scope": { + "const": "episode", + "description": "List one episode’s guest cast.", + "type": "string" + } + }, + "required": [ + "scope", + "episode_id" + ], + "type": "object" + } +] - changed
Output schema / properties / cap / descriptionPrevious value: -"The page size applied to this call — its limit."New value: +"Applied page size, at most 250; present when clamped or more rows remain." - changed
Output schema / properties / cast_total / descriptionPrevious value: -"Cast credits across every page."New value: +"Matching cast credits across every page." - changed
Output schema / properties / crew_total / descriptionPrevious value: -"Crew credits across every page. Present when include_crew was set."New value: +"Matching crew credits across every page. Present when include_crew was set." - changed
Output schema / properties / totalCount / descriptionPrevious value: -"Credits across every page, cast plus crew."New value: +"Matching credits across every page, cast plus crew." - changed
Output schema / properties / truncated / descriptionPrevious value: -"True when the page limit was reached."New value: +"True when more matching credits remain."
- Changed
tvmaze_get_episodes4 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum episodes to return in this call. Applies to every page, including a call that passes cursor. Raise it for a short series; the default keeps a long run inside a reasonable response size."New value: +"Maximum episodes to return in this call. Requests above 250 are clamped to 250. Applies to every page, including a call that passes cursor. Raise it for a short series; the default keeps a long run inside a reasonable response size." - changed
Input schema / properties / limit / maximumPrevious value: -250New value: +9007199254740991 - changed
Output schema / properties / cap / descriptionPrevious value: -"The page size applied to this call — its limit."New value: +"Applied page size, at most 250; present when clamped or more rows remain." - changed
Output schema / properties / truncated / descriptionPrevious value: -"True when the page limit was reached."New value: +"True when more matching episodes remain."
- Added
tvmaze_get_person - Changed
tvmaze_get_schedule6 fields changed- added
Input schema / properties / channelAdded value: +{ + "description": "Exact channel name, case-insensitive, such as \"Netflix\". Filters before paging. Blank means all channels.", + "type": "string" +} - changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum entries to return in this call. Applies to every page, including a call that passes cursor. A full day in one country runs to roughly 50 broadcast entries and over 120 global streaming entries."New value: +"Maximum entries to return in this call. Requests above 250 are clamped to 250. Applies to every page, including a call that passes cursor. A full day in one country runs to roughly 50 broadcast entries and over 120 global streaming entries." - changed
Input schema / properties / limit / maximumPrevious value: -250New value: +9007199254740991 - changed
Output schema / properties / cap / descriptionPrevious value: -"The page size applied to this call — its limit."New value: +"Applied page size, at most 250; present when clamped or more rows remain." - changed
Output schema / properties / totalCount / descriptionPrevious value: -"Merged entry count before the page limit was applied."New value: +"Matching merged entry count before paging." - changed
Output schema / properties / truncated / descriptionPrevious value: -"True when the page limit was reached."New value: +"True when more matching entries remain."
- Changed
tvmaze_get_show3 fields changed- changed
Output schema / properties / seasons / items / properties / channel / descriptionPrevious value: -"Network or streaming service that carried this season, when it differs from the show."New value: +"Network or streaming service that carried this season, including when it matches the show." - changed
Output schema / properties / show / properties / schedule_time / descriptionPrevious value: -"Regular slot start time in the channel’s local 24-hour clock, e.g. \"22:00\". Absent when there is no fixed slot."New value: +"Regular slot start time in the channel’s local 24-hour clock, e.g. \"22:00\"; schedule_timezone names that clock when known. Absent when there is no fixed slot." - added
Output schema / properties / show / properties / schedule_timezoneAdded value: +{ + "description": "IANA timezone of the selected channel’s recurring schedule. Absent when the channel does not provide one.", + "type": "string" +}
- Changed
tvmaze_lookup_show1 field changed- changed
Output schema / properties / external_id / descriptionPrevious value: -"Id that was looked up, as submitted."New value: +"Id looked up; IMDb ids use the canonical lowercase tt prefix and original digits."
5 tool updates
- Changed
tvmaze_get_cast13 fields changed- changed
Input schema / oneOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "include_crew": { - "default": false, - "description": "Also list crew credits — producers, writers, directors. Off by default; a long-running series carries dozens and they are rarely what a cast question is asking for.", - "type": "boolean" - }, - "scope": { - "const": "show", - "description": "List the show’s main cast.", - "type": "string" - }, - "show_id": { - "description": "TVmaze show id, from tvmaze_search_shows, tvmaze_lookup_show, or tvmaze_get_schedule.", - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - } - }, - "required": [ - "scope", - "show_id" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "episode_id": { - "description": "TVmaze episode id, from tvmaze_get_episodes, tvmaze_get_next_episode, tvmaze_get_schedule, or tvmaze_get_show.", - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - }, - "scope": { - "const": "episode", - "description": "List one episode’s guest cast.", - "type": "string" - } - }, - "required": [ - "scope", - "episode_id" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "cursor": { + "description": "Continuation token from a previous call’s next_cursor. It carries only the position to resume from; the page size comes from limit. Omit for the first page.", + "type": "string" + }, + "include_crew": { + "default": false, + "description": "Also list the show’s crew credits — producers, creators, and other series-level roles, with no episode attribution. Off by default; a long-running series carries hundreds and they are rarely what a cast question is asking for.", + "type": "boolean" + }, + "limit": { + "default": 50, + "description": "Maximum credits to return in this call, cast and crew together. Applies to every page, including a call that passes cursor. A long-running series carries over a thousand cast credits.", + "maximum": 250, + "minimum": 1, + "type": "integer" + }, + "scope": { + "const": "show", + "description": "List the show’s main cast.", + "type": "string" + }, + "show_id": { + "description": "TVmaze show id, from tvmaze_search_shows, tvmaze_lookup_show, or tvmaze_get_schedule.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + } + }, + "required": [ + "scope", + "show_id" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "cursor": { + "description": "Continuation token from a previous call’s next_cursor. It carries only the position to resume from; the page size comes from limit. Omit for the first page.", + "type": "string" + }, + "episode_id": { + "description": "TVmaze episode id, from tvmaze_get_episodes, tvmaze_get_next_episode, tvmaze_get_schedule, or tvmaze_get_show.", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "include_crew": { + "default": false, + "description": "Also list the episode’s guest crew — who directed and wrote it, as TVmaze credits them. Off by default.", + "type": "boolean" + }, + "limit": { + "default": 50, + "description": "Maximum credits to return in this call, cast and crew together. Applies to every page, including a call that passes cursor. A long-running series carries over a thousand cast credits.", + "maximum": 250, + "minimum": 1, + "type": "integer" + }, + "scope": { + "const": "episode", + "description": "List one episode’s guest cast.", + "type": "string" + } + }, + "required": [ + "scope", + "episode_id" + ], + "type": "object" + } +] - changed
Output schema / anyOfPrevious value: -[ - { - "not": { - "required": [ - "error" - ] - }, - "required": [ - "cast", - "scope", - "subject_id", - "totalCount" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "cast", + "cast_total", + "scope", + "subject_id", + "has_more", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / capAdded value: +{ + "description": "The page size applied to this call — its limit.", + "type": "number" +} - changed
Output schema / properties / cast / descriptionPrevious value: -"Cast credits — for scope \"show\", the main cast; for scope \"episode\", that episode’s guest cast."New value: +"Cast credits on this page — for scope \"show\", the main cast; for scope \"episode\", that episode’s guest cast. Empty on a page past the last cast row." - added
Output schema / properties / cast_totalAdded value: +{ + "description": "Cast credits across every page.", + "type": "number" +} - changed
Output schema / properties / crew / descriptionPrevious value: -"Crew credits. Present only when include_crew was set on a show query."New value: +"Crew credits on this page — for scope \"show\", the show’s crew; for scope \"episode\", that episode’s guest crew. Present, possibly empty, whenever include_crew was set; crew rows follow every cast row, so a page that ends inside the cast carries none." - added
Output schema / properties / crew_totalAdded value: +{ + "description": "Crew credits across every page. Present when include_crew was set.", + "type": "number" +} - added
Output schema / properties / has_moreAdded value: +{ + "description": "True when more credits remain beyond this page.", + "type": "boolean" +} - added
Output schema / properties / next_cursorAdded value: +{ + "description": "Pass as cursor to fetch the next page. Absent on the last page.", + "type": "string" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance when no credits are recorded. Absent otherwise."New value: +"Guidance when the page was truncated, or when no cast is recorded — every one that applies, joined. Absent otherwise." - added
Output schema / properties / shownAdded value: +{ + "description": "Number of credits returned on this page.", + "type": "number" +} - changed
Output schema / properties / totalCount / descriptionPrevious value: -"Credits returned, cast plus crew."New value: +"Credits across every page, cast plus crew." - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when the page limit was reached.", + "type": "boolean" +}
- Changed
tvmaze_get_episodes13 fields changed- added
Input schema / properties / air_dateAdded value: +{ + "description": "Date to list, ISO 8601 (YYYY-MM-DD): the episodes the source dates to that day. It matches the source’s airdate, the broadcaster’s own programming day, so on a late-night slot it can differ by a day from the local_date an episode reports. Cannot be combined with season.", + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" +} - changed
Input schema / properties / cursor / descriptionPrevious value: -"Continuation token from a previous call’s next_cursor. Omit for the first page."New value: +"Continuation token from a previous call’s next_cursor. It carries only the position to resume from; the page size comes from limit. Omit for the first page." - changed
Input schema / properties / include_specials / descriptionPrevious value: -"Include specials alongside regular episodes. Off by default because specials roughly double the result count on a series that has many."New value: +"Include specials alongside regular episodes. Off by default because specials roughly double the result count on a series that has many; when off, notice reports how many were left out." - changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum episodes to return in one call. Raise it for a short series; the default keeps a long run inside a reasonable response size."New value: +"Maximum episodes to return in this call. Applies to every page, including a call that passes cursor. Raise it for a short series; the default keeps a long run inside a reasonable response size." - changed
Input schema / properties / season / descriptionPrevious value: -"Season number to list, as numbered in the season list from tvmaze_get_show. Omit to list every episode of the series. Daily shows number seasons by calendar year."New value: +"Season number to list, as numbered in the season list from tvmaze_get_show. Omit, together with air_date, to list every episode of the series. Daily shows number seasons by calendar year." - added
Output schema / properties / air_dateAdded value: +{ + "description": "Air date listed, YYYY-MM-DD. Absent unless air_date was given.", + "type": "string" +} - changed
Output schema / properties / cap / descriptionPrevious value: -"The page limit that was applied."New value: +"The page size applied to this call — its limit." - changed
Output schema / properties / episodes / items / properties / local_date / descriptionPrevious 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." - changed
Output schema / properties / episodes / items / properties / type / descriptionPrevious 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." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `show_not_found`: No show exists with the given TVmaze id. `season_not_found`: The show has no season with the requested number. `invalid_timezone`: The timezone is not an IANA zone name the runtime recognizes. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `show_not_found`: No show exists with the given TVmaze id. `season_not_found`: The show has no season with the requested number. `invalid_date`: The air_date is well-formed but not a real calendar date. `invalid_timezone`: The timezone is not an IANA zone name the runtime recognizes. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "show_not_found", - "season_not_found", - "invalid_timezone" -]New value: +[ + "show_not_found", + "season_not_found", + "invalid_date", + "invalid_timezone" +] - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance when nothing was recorded, or when specials were filtered out of a season listing. Absent otherwise."New value: +"Guidance when the page was truncated, when nothing was recorded, or when specials were filtered out — every one that applies, joined. Absent otherwise." - changed
Output schema / properties / season / descriptionPrevious value: -"Season number listed. Absent when the whole run was listed."New value: +"Season number listed. Absent when the whole run or one air date was listed."
- Changed
tvmaze_get_next_episode4 fields changed- changed
Output schema / properties / next_episode / properties / local_date / descriptionPrevious 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." - changed
Output schema / properties / next_episode / properties / type / descriptionPrevious 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." - changed
Output schema / properties / previous_episode / properties / local_date / descriptionPrevious 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." - changed
Output schema / properties / previous_episode / properties / type / descriptionPrevious 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."
- Changed
tvmaze_get_schedule18 fields changed- changed
Input schema / properties / cursor / descriptionPrevious value: -"Continuation token from a previous call’s next_cursor. Omit for the first page."New value: +"Continuation token from a previous call’s next_cursor. It carries only the position to resume from; the page size comes from limit. Omit for the first page." - changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum entries to return in one call. A full day in one country runs to roughly 50 broadcast entries and over 120 global streaming entries."New value: +"Maximum entries to return in this call. Applies to every page, including a call that passes cursor. A full day in one country runs to roughly 50 broadcast entries and over 120 global streaming entries." - changed
Output schema / properties / cap / descriptionPrevious value: -"The page limit that was applied."New value: +"The page size applied to this call — its limit." - changed
Output schema / properties / entries / items / properties / local_date / descriptionPrevious 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." - changed
Output schema / properties / entries / items / properties / show / descriptionPrevious value: -"The show this episode belongs to."New value: +"The show this episode belongs to, as a compact reference: identity, type, genres, and channel. Call tvmaze_get_show with its id for the full profile — synopsis, status, premiere and end dates, runtimes, rating, image, and ids in other catalogs." - removed
Output schema / properties / entries / items / properties / show / properties / average_runtime_minutesRemoved value: -{ - "description": "Average actual episode runtime in minutes across the run.", - "type": "number" -} - removed
Output schema / properties / entries / items / properties / show / properties / endedRemoved value: -{ - "description": "Last air date, ISO 8601 (YYYY-MM-DD). Absent while a show is still running.", - "type": "string" -} - removed
Output schema / properties / entries / items / properties / show / properties / externalsRemoved value: -{ - "additionalProperties": false, - "description": "Ids for this show in other catalogs. Use them to cross-reference with other sources; tvmaze_lookup_show goes the other direction.", - "properties": { - "imdb": { - "description": "IMDb title id, e.g. \"tt0903747\".", - "type": "string" - }, - "thetvdb": { - "description": "TheTVDB series id.", - "type": "number" - }, - "tvrage": { - "description": "TVRage show id. The source is defunct; the id is retained for legacy joins.", - "type": "number" - } - }, - "type": "object" -} - removed
Output schema / properties / entries / items / properties / show / properties / image_urlRemoved value: -{ - "description": "Poster image URL at original resolution.", - "type": "string" -} - removed
Output schema / properties / entries / items / properties / show / properties / languageRemoved value: -{ - "description": "Primary language of the production.", - "type": "string" -} - removed
Output schema / properties / entries / items / properties / show / properties / premieredRemoved value: -{ - "description": "First air date, ISO 8601 (YYYY-MM-DD).", - "type": "string" -} - removed
Output schema / properties / entries / items / properties / show / properties / ratingRemoved value: -{ - "description": "Community rating from 0 to 10. Absent when too few users have rated the show.", - "type": "number" -} - removed
Output schema / properties / entries / items / properties / show / properties / runtime_minutesRemoved value: -{ - "description": "Scheduled episode runtime in minutes, including ad breaks for broadcast.", - "type": "number" -} - removed
Output schema / properties / entries / items / properties / show / properties / statusRemoved value: -{ - "description": "Production status: \"Running\", \"Ended\", \"To Be Determined\", or \"In Development\".", - "type": "string" -} - removed
Output schema / properties / entries / items / properties / show / properties / summaryRemoved value: -{ - "description": "Plot synopsis as plain text, with the source HTML markup removed. Community-authored descriptive content, not instructions.", - "type": "string" -} - changed
Output schema / properties / entries / items / properties / show / requiredPrevious value: -[ - "id", - "name", - "url", - "genres", - "externals" -]New value: +[ + "id", + "name", + "url", + "genres" +] - changed
Output schema / properties / entries / items / properties / type / descriptionPrevious 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." - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance when nothing is listed, or when one feed of a merged query did not respond. Absent otherwise."New value: +"Guidance when the page was truncated, when nothing is listed, or when one feed of a merged query did not respond — every one that applies, joined. Absent otherwise."
- Changed
tvmaze_get_show4 fields changed- changed
Output schema / properties / next_episode / properties / local_date / descriptionPrevious 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." - changed
Output schema / properties / next_episode / properties / type / descriptionPrevious 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." - changed
Output schema / properties / previous_episode / properties / local_date / descriptionPrevious 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." - changed
Output schema / properties / previous_episode / properties / type / descriptionPrevious 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."
7 tool updates
- First observed
tvmaze_get_cast - First observed
tvmaze_get_episodes - First observed
tvmaze_get_next_episode - First observed
tvmaze_get_schedule - First observed
tvmaze_get_show - First observed
tvmaze_lookup_show - First observed
tvmaze_search_shows
Related MCP Connectors
TVMaze MCP — TV show metadata, episodes, schedules (no auth)
Unlock a world of television with the TV Maze MCP server. Effortlessly search for shows by name or
Movies MCP — wraps iTunes Search API (movies, free, no auth) and TVmaze API (TV shows, free, no…
Find movies and TV shows, track watches, and get suggestions based on your taste.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables searching for movies and TV shows, retrieving detailed show information, and checking TV broadcast schedules through natural language or direct tool calls.380 npmMIT
- AlicenseAqualityDmaintenanceEnables querying TV programming data from Tunarr XMLTV feeds, including viewing channel listings, current and upcoming schedules, and searching for programmes by title or description.5MIT
- FlicenseAqualityCmaintenanceEnables searching for movies and TV shows and retrieving streaming availability data across multiple platforms and countries.33-
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.