Skip to main content
Glama
Sign In
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

rottentomatoes_season_reviews

Retrieve Rotten Tomatoes TV season critic reviews, newest first, with stable IDs, critic details, article URLs, and cursor pagination up to 500 reviews.

Instructions

Rotten Tomatoes TV season critic reviews. Returns the critic reviews of one TV season, newest first. Each review has a stable id, ISO created_at/updated_at timestamps, 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); if the feed cannot be read, the service may fall back to loading the season's reviews page in a browser (transport: browser_render, much slower and at most five pages deep). A season with no critic reviews yet returns 200 with an empty reviews array. data.subject identifies the season. data.fetched_at, X-Cache and X-Availability-Last-Success-* describe freshness. Pass exactly one of path or url.

Input Schema

NameRequiredDescriptionDefault
urlNoAbsolute https://www.rottentomatoes.com season URL
pathNoRotten Tomatoes season path
typeNoReview list: critics (default), top-critics or audience.
afterNoPagination cursor: pass data.page_info.end_cursor from the previous response. 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

A3.9/5.0
Behavior4/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 so well: it discloses the primary feed path (~1s), a browser_render fallback that is much slower and capped at five pages, a 500-review pagination ceiling, and that an empty season returns 200 with an empty reviews array. It omits auth requirements and rate limiting, which keeps it just below the top.

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 purpose and return shape, then paging, then transport behavior and freshness — a sensible ordering where each sentence adds operational information. It is dense but not padded; a few freshness-metadata asides could be trimmed.

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?

With no output schema and five params, the description supplies the return-field anatomy (id, created_at/updated_at, critic identity, article URL), cursor semantics, transport/latency expectations, and the empty-result case. An agent can call and page through it correctly without further information.

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 already 100%, so the baseline is 3; the description earns more by adding the invariant that exactly one of `path` or `url` must be passed, which the schema does not enforce. It loses credit for ignoring `type` entirely and framing the tool as critic-only even though the schema exposes an audience option.

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?

"Rotten Tomatoes TV season critic reviews... Returns the critic reviews of one TV season, newest first" states a specific verb, resource and ordering. It doesn't name sibling alternatives (rottentomatoes_movie_reviews, rottentomatoes_episode_reviews, rottentomatoes_critic_reviews), so differentiation is inferred from "TV season" rather than stated.

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?

It gives precise in-tool usage mechanics ("pass data.page_info.end_cursor as after and keep limit the same while paging") and the one-of-path-or-url rule, but never says when to choose this over the movie/episode/critic review siblings. Usage is implied by the resource scope rather than guided.

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