Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

imdb_title_quotes

Retrieve IMDb-listed quotes for a movie or TV title by ID or URL, returning speaker-prefixed exchanges with spoiler flags and total counts.

Instructions

IMDb title quotes. Returns the quotes IMDb lists for a title. Pass exactly one of id or url. Each entry in facts is a whole exchange, with lines prefixed by the speaker, plus a spoiler flag. total is the count IMDb lists, so a short list is normal on popular titles.

Input Schema

NameRequiredDescriptionDefault
idNoIMDb title id
urlNoAbsolute https://www.imdb.com/title/<id>/ URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations and no output schema, the description carries the disclosure burden and does it well: it explains that `facts` entries are whole exchanges with speaker-prefixed lines and a `spoiler` flag, and that `total` is IMDb's count so a short list is normal. It omits error behavior for titles with no quotes, which is the only notable gap for a read-only tool.

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?

Front-loaded with the one-line purpose, then the parameter rule, then output structure and the short-list caveat. Every sentence carries information; no filler or repetition of 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 simple read tool with no annotations and no output schema, the description covers what is returned (`facts`, `total`), how to invoke it, and a realistic expectation about list length. Only the empty-result/error case is unaddressed, a minor omission.

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 baseline is 3, but the description adds a genuinely non-schema constraint: exactly one of `id` or `url` must be passed. Since `required` is empty in the schema, this mutual-exclusivity rule is meaningful added value.

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 the quotes IMDb lists for a title.' This is unmistakably distinct from the nearest sibling, imdb_title_trivia, and from the broader imdb_title_* family, so an agent can select it without opening any schema.

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 implied by the name and first sentence (fetch quotes for a given title), and 'Pass exactly one of `id` or `url`' constrains invocation. However, there is no explicit when-to-use/when-not guidance or pointer to alternatives such as imdb_title_trivia for related content, leaving selection 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