imdb-analytics-mcp

by iamneilroberts

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: ranking people, searching for a specific person, retrieving one person's details, comparing a fixed set of people, finding collaborations, and searching titles. The descriptions actively clarify boundaries, e.g. search_people is lookup not ranking, and compare_people is not a search. There is no real risk of selecting the wrong tool.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern: rank_people, search_people, get_person, compare_people, find_collaborations, search_titles. The verbs are clear and the nouns consistently identify the entity being acted on. Minor singular/plural variation does not create confusion.
Tool Count5/5
Six tools is well-scoped for a read-only analytics server. Each tool covers a distinct query shape without redundancy. The count feels intentional rather than padded or thin.
Completeness4/5
The server covers the main person-analytics workflows well: discover, rank, inspect, compare, collaborate, and filter titles by people. The only notable gap is the absence of a dedicated title-detail tool for full cast/crew or richer title metadata, but search_titles and the collaboration tools provide reasonable workarounds.
Average 4.8/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description adds meaningful behavioral guarantees: 'Every number comes from the same code path a ranking uses, so a value here and the same value in a rank_people row cannot disagree.' It also discloses the return shape ('one compact row per person... plus, in query_summary.pairs...') and that IDs are accepted 'in either form.' These are non-obvious traits an agent needs.
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 description is long but every section earns its place: purpose, examples, consistency guarantee, return summary, ID format, and routing to siblings. The examples are illustrative rather than padding. It could be slightly tighter, but it remains well-structured and front-loaded.
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 tool with an output schema and two parameters, the description covers the core context: what is compared, how results are shaped, how IDs are passed, and how to follow up for shared titles. Missing details like behavior for null or fewer-than-two person_ids and the single-person get_person alternative are not critical given the schema and sibling context, but they would make it more complete.
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?
The description clarifies person_ids semantics by saying 'Takes IMDb name ids in either form' and implies a two-to-ten count, which the schema does not enforce. However, it does not explain the credit_definition parameter in prose; it only hints at consistency with ranking. With schema description coverage reported as 0%, the description should compensate more, so this is adequate but not strong.
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?
The description states a specific verb and resource: 'Put two to ten named people side by side on the same measures.' It also includes illustrative queries and explicitly distinguishes itself from search: 'It is a comparison, not a search.' This makes the tool's purpose unmistakable and distinct from siblings like search_people and rank_people.
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?
The description gives explicit routing guidance: 'to find the people first, use search_people or rank_people, then pass their ids here' and 'For the titles two of them actually share, follow up with find_collaborations in shared_titles mode.' This clearly states when to use this tool versus the relevant alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, but the description adds substantial behavioral detail: only 1.7 of 12.8 million titles have ratings, rating/vote filters drop unrated titles, there is no theatrical-release flag, and person filtering uses a default credit definition that can match a series through an episode. These caveats go well beyond the annotations and are essential for correct use.
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 description is long but well-structured: a one-line purpose, illustrative examples, return-format summary, pagination note, and a clearly labeled limitations section. Each section earns its place, though the number of examples makes it slightly more verbose than strictly necessary.
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 tool with five parameters, a nested filters object, and an output schema, the description covers the key invocation scenarios, pagination, return fields, and critical data-coverage caveats. It is missing only minor explicit guidance on sorting options, which the schema's enum already provides, so the agent can still invoke the tool correctly.
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?
With schema description coverage reported as 0%, the description compensates by explaining the main filter dimensions (text, type, year, genre, rating, votes, person IDs) and the meaning of with_person_ids. It also clarifies pagination via next_cursor. However, it does not directly explain sort_by, sort_direction, or limit semantics, and the nested schema descriptions carry some of that weight.
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?
The description opens with a specific verb and resource: 'Find and rank titles by text, type, year, genre, rating, votes, or who is in them.' It gives concrete example queries and distinguishes itself from the people-focused sibling tools by emphasizing title metadata and explicitly contrasting with the collaboration-count use case.
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?
The description provides clear usage context through examples and directly explains when with_person_ids is the right approach versus when the user wants a collaboration count instead. It also documents important boundary cases in 'What it cannot do', but it does not explicitly name sibling tools as alternatives, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses counting semantics (series counted once per unit), credit-definition honoring, the principal-cast hard limit of 69 people per title, and the crucial caveat that absence of a shared credit is not evidence against collaboration. This is exceptionally useful behavioral context.
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 every sentence carries useful information for a multi-mode tool. It is front-loaded with the core question, then organizes mode behavior, shared semantics, and data caveats in clear paragraphs. There is no fluff or repetition.
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?
Given the tool's complexity, the description covers the five distinct modes, the role of key parameters, the data limitations, and the necessary search_people prerequisite. An output schema exists, so the description does not need to explain return values. This is a complete and self-sufficient definition.
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?
Although the top-level schema has little description coverage, the prose explains the mode enum with five worked examples, states that limit bounds returned collaborators, and that max_hops bounds the path search. It also conveys the meaning of credit_definition through the include_tv_series/include_tv_movies/include_video example. It does not formally name the person_ids parameter, but the examples and 'Pass ids, not names' adequately compensate.
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?
The description opens with a clear query intent, 'Who has worked with whom,' and then enumerates all five modes with concrete example questions. It also distinguishes itself from sibling tools by instructing the agent to 'use search_people first' for name resolution, making its role unambiguous.
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?
The description gives strong usage context: which mode to pick for which question shape, the meaning of limit and max_hops, and the prerequisite 'Pass ids, not names; use search_people first.' It does not explicitly contrast with siblings like compare_people or rank_people, but the mode examples make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses real behavioral traits: exact-match-first ordering, the fields returned, the fact that it never scans the whole catalogue, primary-name-only matching, and M4-dependent filter limitations. No statement contradicts the annotations.
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 dense but every sentence carries information: concrete examples, return semantics, ordering, cross-tool filter reuse, and explicit non-goals are all packed in without filler. The most decision-relevant claim—lookup, not ranking—appears early.
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?
Given the output schema exists and the description already covers return fields, ordering, filter semantics, and limitations, an agent has everything needed to select and invoke this tool correctly. The only omitted item, limit behavior, is minor and inferable from the schema default.
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?
Yet 0% top-level schema description coverage, the desc">ription compensates for the required 'name' parametir and 'filters' object, e"plaining that filters mirror rank_people and are used to disambiguate same-name people by birth year or profession. It does not e"plicitly e"plain 'limit', though the schema's default of 20 and the return-ordering sentence make its role inferable, so the compensation is strong but not total.
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?
The description opens with a specific verb and resource—'Find people by name and pick the right one'—and immediately separates the tool from ranking tools by declaring 'This is lookup, not ranking.' Example questions make the intended use unmistakable, and the final sentence names concrete unsupported dimensions (nationality, gender, award) that distinguish it from sibling 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?
It gives explicit when-to-use context ('before spending another call on them'), tells the agent to use the returned imdb_name_id for later calls, and issues clear exclusions: do not use for superlative questions, nationality/gender/award searches, or alternate-name matching. It also points to rank_people for the shared filter vocabulary, giving the agent a route to the sibling tool's semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the readOnly/idempotent annotations: recognition and background-work blocks always use default definitions and do not change with the credit definition, and the voice filter is an approximation via Animation genre. These non-obvious behaviors are exactly what an agent needs to avoid misinterpreting results.
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 dense but every sentence earns its place: core purpose, example queries, summary of return fields, distinction from siblings, and parameter guidance. It is front-loaded with the essential sentence and uses short paragraphs and examples rather than filler.
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 three parameters and a complex nested credit_definition object, the description fully covers the important semantics, caveats, and usage patterns. With an output schema present, return-value details are not needed. Nothing an agent needs to call this tool correctly is missing.
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?
Although schema coverage is listed at 0%, the description compensates richly: it explains the person_id format (nm string or numeric form), clarifies the credit_definition object with named presets and concrete flag combinations, and reveals behavioral quirks like include_adult skewing lists. It adds practical semantics that the raw schema alone would not convey.
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 states a specific verb and resource ('Everything known about one person') and distinguishes itself from siblings by noting it is the only tool returning full component detail while ranking tools return compact rows. The examples of questions ('Tell me about Samuel L. Jackson') make the use case instantly recognizable.
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?
Description explicitly explains when to use this tool versus ranking tools, gives concrete question types, and shows how to adjust the credit definition for follow-ups with specific flag examples. It even maps natural language requests like 'restrict to theatrical films' to exact parameter settings, leaving little ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

imdb-analytics-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![imdb-analytics-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/iamneilroberts/imdb-analytics-mcp/badges/card.svg)](https://glama.ai/mcp/servers/iamneilroberts/imdb-analytics-mcp)

Score Badge

Copy to your README.md:

[![imdb-analytics-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/iamneilroberts/imdb-analytics-mcp/badges/score.svg)](https://glama.ai/mcp/servers/iamneilroberts/imdb-analytics-mcp)