Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

rottentomatoes_episode_reviews

Fetch Rotten Tomatoes TV episode critic reviews, newest first, with stable IDs and cursor pagination. Use it to inspect episode reception or collect review data.

Instructions

Rotten Tomatoes TV episode critic reviews. Returns the critic reviews of one TV episode, newest first, read the same way as the season and movie feeds. Reviews carry a stable id, ISO created_at/updated_at, the critic identity and the original article URL. The list is pageable limit reviews at a time, up to 500 deep: pass data.page_info.end_cursor as after and keep limit the same while paging. It is read directly from Rotten Tomatoes' review feed (data.transport is feed_api, normally about a second), with a slower browser fallback (browser_render, at most five pages) when the feed cannot be read. Episode review lists are often small or empty: an episode nobody has reviewed yet returns 200 with an empty reviews array. data.subject identifies the episode.

Input Schema

NameRequiredDescriptionDefault
urlNoAbsolute https://www.rottentomatoes.com episode URL
pathNoRotten Tomatoes episode path
typeNoReview list: critics (default), top-critics or audience.
afterNoPagination cursor: pass data.page_info.end_cursor from the previous response, with the same limit. Critic cursors are base64 page indexes; audience cursors are opaque keyset values that should be passed back unchanged. The feed can serve up to 500 reviews; browser fallback is capped at five pages.
limitNoReviews per page, default 10, max 20. Keep it the same on every page of one walk: the cursor is a page index times this value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.18

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does it well: it discloses the primary feed transport (~1s), a slower browser fallback capped at five pages, the 500-review depth limit, and that unreviewed episodes return 200 with an empty reviews array. It also names the returned fields and states the id is stable.

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?

Front-loads what the tool does, then layers returns, pagination, transport, and edge cases in a logical order. The single dense paragraph is efficient but a touch packed; every sentence does contribute useful 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?

For a tool with no output schema and no annotations, the description supplies return-field contents, pagination mechanics, transport behavior, and empty-result handling, plus what data.subject identifies. Nothing an agent needs to call it correctly appears to be 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 baseline is 3, but the description adds a genuine cross-parameter invariant: pass data.page_info.end_cursor as after and keep limit unchanged while paging, with the cursor being a page index times limit. That is real meaning beyond the schema text.

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?

The description opens with a specific verb and resource: 'Returns the critic reviews of one TV episode, newest first.' It implicitly places itself relative to season and movie feeds ('read the same way as the season and movie feeds'), but it never names the sibling tools (e.g., rottentomatoes_season_reviews, rottentomatoes_movie_reviews) an agent might confuse this with, so full sibling differentiation is not there.

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

Usage Guidelines3/5

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

The scope ('one TV episode') implies when it applies, but there is no explicit 'use this instead of X when...' routing against the many other RT review tools. Pagination guidance is present, but selection guidance versus alternatives is left to inference.

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

Deploy Server

Other Tools