Skip to main content
Glama
Sign In
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

rottentomatoes_publication

Fetches a Rotten Tomatoes publication profile by encrypted or publication ID, returning editorial details, follower and review counts, approval flags, and critic roster for publication analysis.

Instructions

Rotten Tomatoes publication profile. Returns one Rotten Tomatoes publication: its name, encrypted id, editorial page, image, whether it is a top publication and Tomatometer approved, its follower and review counts, and the critics who write for it with their names, encrypted ids, profile URLs and top-critic flags. Take the id from encrypted_publication_id (or publication_id) on any review row returned by the review endpoints. data.fetched_at is the UTC fetch time.

Input Schema

NameRequiredDescriptionDefault
idYesPublication id: encrypted_publication_id or publication_id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.18

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does meaningful work: it is clearly a single-record read, discloses what is returned, and notes that `data.fetched_at` is UTC fetch time. It omits any auth, rate-limit, or missing-record behavior, which keeps it short of a 5.

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?

The identity of the tool and its payload are front-loaded, followed by the id-sourcing instruction and the fetched_at note. Every sentence is useful, though the return-field enumeration is dense enough that a single flat paragraph makes it harder to scan.

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?

There is no output schema, and the description compensates well by listing the returned fields and explaining the fetched_at timestamp. What remains missing is edge-case behavior (unknown id, empty critics) and anything about response wrapping beyond the fetched_at hint.

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 the schema description already says 'Publication id: encrypted_publication_id or publication_id'. The description repeats that same instruction without adding syntax, format, or validation detail, so the schema is doing the heavy lifting.

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

Purpose5/5

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

States a specific verb and resource ('Returns one Rotten Tomatoes publication') and then enumerates the returned fields (name, encrypted id, editorial page, image, top-publication/Tomatometer flags, follower and review counts, contributing critics). This clearly distinguishes it from sibling list/aggregate tools such as rottentomatoes_critic_publications.

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?

Explicitly tells the agent where to source the required id: 'Take the `id` from `encrypted_publication_id` (or `publication_id`) on any review row returned by the review endpoints.' That is a concrete usage pathway, but no exclusions or named alternatives are given for when a different publication-related sibling should be preferred.

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