Skip to main content
Glama
iamneilroberts

imdb-analytics-mcp

Rank People

rank_people
Read-onlyIdempotent

Rank actors and actresses from IMDb by any metric—credits, prominence, career length, average rating—and refine with filters for living status, birth year, professions, and credit definitions.

Instructions

Rank people by any measure, under any filter and any definition of an acting credit.

This is the tool for every superlative question and every refinement of one. Answers questions like: "Who are the 25 most prolific actors?", "Same list, but only people recognizable enough that an audience would know them", "Now only living actors born before 1960", "Who has the longest career?", "Which prolific actors have the most highly rated films?", "Rank these five by career length instead".

Follow-ups are the previous arguments with one field changed, so keep the whole filter object and edit it. The fields that carry the common follow-ups: "women only" is filters.professions_any=["actress"], an approximation of the credit and not of the person, until gender enrichment lands; "living only" is filters.living_only=true; "born after 1950" is filters.birth_year_min=1951; "remove the extras" is filters.max_background_share, around 0.5; "make it recognizable" is filters.min_prominence or sort_by="prominence_score"; "at least ten well-rated films" is filters.min_highly_rated_titles=10 with filters.title_rating_min and title_votes_min setting the bar; "restrict to theatrical films" is credit_definition.include_tv_series=false, include_tv_movies=false, include_video=false.

To re-rank a result you already have rather than re-running the whole filter chain, pass its ids as filters.person_ids and change sort_by. Page with next_cursor, handing it back unchanged with the same sort.

sort_by choices: acting_credits, prominence_score (peak recognition), exposure_score (volume of seen work), career_length, credits_per_year, average_rating, weighted_rating (Bayesian, pulls thinly voted careers toward the mean), total_votes, highly_rated_titles, max_title_votes, collaborator_count.

What it cannot do: filter by nationality, gender or award, which need Wikidata enrichment that lands in M4 and error until then; separate voice roles from on-screen ones, because IMDb's datasets carry no voice flag and the include_voice parameter approximates it with the Animation genre; or filter uncredited roles, which the datasets do not mark at all. collaborator_count is an anchored self-join and is refused for candidate sets over a thousand people.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
cursorNo
filtersNo
sort_byNoacting_credits
sort_directionNodesc
credit_definitionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds meaningful behavioral caveats: Wikidata-dependent filters error until M4, include_voice approximates voice roles via the Animation genre, uncredited roles are not marked in the data, and collaborator_count refuses candidate sets over a thousand people. These go well beyond the structured hints.

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?

The description is long but densely packed with useful routing, filtering, limitation, and paging guidance. Every sentence carries operational value, and the structure moves from purpose to follow-ups to re-ranking/paging to sort options to explicit limitations, keeping the most important selection cues front-loaded.

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 six top-level parameters, nested schemas, many enum choices, and an output schema, the description covers the full call cycle: when to use it, how to express common follow-ups, how to re-rank, how to page, what sort values mean, and what will fail and why. It is complete enough for an agent to invoke it correctly without external help.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite the low reported schema coverage, the description compensates by mapping natural-language follow-ups to exact parameter paths: 'women only' → filters.professions_any, 'living only' → filters.living_only, 'remove the extras' → filters.max_background_share, and theatrical restrictions → credit_definition.include_tv_series. It also explains each sort_by value and the meaning of cursor and person_ids for re-ranking.

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?

Description opens with a specific verb and resource: 'Rank people by any measure, under any filter and any definition of an acting credit.' It immediately clarifies this is the superlative-question tool and gives concrete example questions, distinguishing it from the sibling search and comparison tools.

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

Usage Guidelines5/5

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

Explicitly states 'This is the tool for every superlative question,' explains common follow-ups and how to encode them as filter fields, and tells the agent to reuse person_ids for re-ranking an existing result. It also states clear exclusions: what the tool cannot do, such as nationality, gender, award, voice-role, and uncredited-role filtering.

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