Skip to main content
Glama
rollecode

IMDb MCP server

by rollecode

get_title_reviews

Read-onlyIdempotent

Fetch user reviews for a specific IMDb title, ordered by helpfulness, with pagination via limit and cursor to browse multiple pages.

Instructions

Read user reviews of a title, most helpful first.

Args: id: Title id. limit: How many reviews per page. cursor: next_cursor from the previous page.

Input Schema

NameRequiredDescriptionDefault
idYes
limitNo
cursorNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds genuine context beyond that — the 'most helpful first' ordering and the pagination contract that cursor comes from the previous page's next_cursor — but says nothing about review language, filtering, or rate limits.

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 purpose sentence is front-loaded and wastes no words; the Args block is compact and scannable. Slight deduction because the docstring-style arg list duplicates parameter names already visible in 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?

For a paginated read tool with an output schema (which covers return fields including next_cursor), the description supplies what's needed: ordering semantics and the page-chaining rule. Minor gaps remain around whether reviews are filtered by language or spoiler status, but nothing required 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 description coverage is 0%, so the description carries the full burden, and it does define all three parameters: id as a title id, limit as reviews per page, and cursor as the next_cursor from the prior page. The definitions are terse (no format examples, and 'Title id' is nearly circular) but they disclose each parameter's role and the pagination linkage.

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 and resource ('Read user reviews of a title') plus the result ordering ('most helpful first'), which no sibling tool provides. The resource is clearly distinct from get_title, get_title_credits, and get_title_episodes, though no sibling is named explicitly.

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?

Usage is only implied: an agent infers this is the tool for reviews as opposed to title metadata or credits. There is no explicit when-to-use statement, no exclusions, and no named alternative for related needs.

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