TMDB MCP Server
Enables searching, retrieving details, and accessing trending movies from The Movie Database (TMDB) API. Provides specific movie information by ID, similar movie recommendations, and supports generating custom movie reviews.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@TMDB MCP Serversearch for movies about artificial intelligence"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
TMDB MCP Server
This project implements a Model Context Protocol (MCP) server that integrates with The Movie Database (TMDB) API. It enables AI assistants like Claude to interact with movie data, providing capabilities for searching, retrieving details, and generating content related to movies.
Features
Resources
Static Resources:
tmdb://info- Information about TMDB APItmdb://trending- Currently trending movies
Resource Templates:
tmdb://movie/{id}- Detailed information about a specific movie
Prompts
Movie Review: Generate a customized movie review with specified style and rating
Movie Recommendation: Get personalized movie recommendations based on genres and mood
Tools
Search Movies: Find movies by title or keywords
Get Trending Movies: Retrieve trending movies for day or week
Get Similar Movies: Find movies similar to a specified movie
Related MCP server: TMDB MCP Server
Setup Instructions
Prerequisites
Node.js (v16 or later)
npm or yarn
TMDB API key
Installation
Clone this repository
git clone https://github.com/your-username/tmdb-mcp.git cd tmdb-mcpInstall dependencies
npm installConfigure your TMDB API key
Create a
.envfile in the project root (alternative: editsrc/config.tsdirectly)Add your TMDB API key:
TMDB_API_KEY=your_api_key_here
Build the project
npm run buildStart the server
npm start
Setup for Claude Desktop
Open Claude Desktop
Go to Settings > Developer tab
Click "Edit Config" to open the configuration file
Add the following to your configuration:
{
"mcpServers": {
"tmdb-mcp": {
"command": "node",
"args": ["/absolute/path/to/your/tmdb-mcp/build/index.js"]
}
}
}Restart Claude Desktop
Usage Examples
Using Static Resources
"What is TMDB?"
"Show me currently trending movies"
Using Resource Templates
"Get details about movie with ID 550" (Fight Club)
"Tell me about the movie with ID 155" (The Dark Knight)
Using Prompts
"Write a detailed review for Inception with a rating of 9/10"
"Recommend sci-fi movies for a thoughtful mood"
Using Tools
"Search for movies about space exploration"
"What are the trending movies today?"
"Find movies similar to The Matrix"
Development
Project Structure
tmdb-mcp/
├── src/
│ ├── index.ts # Main server file
│ ├── config.ts # Configuration and API keys
│ ├── handlers.ts # Request handlers
│ ├── resources.ts # Static resources
│ ├── resource-templates.ts # Dynamic resource templates
│ ├── prompts.ts # Prompt definitions
│ ├── tools.ts # Tool implementations
│ └── tmdb-api.ts # TMDB API wrapper
├── package.json
├── tsconfig.json
└── README.mdTesting
Use the MCP Inspector to test your server during development:
npx @modelcontextprotocol/inspector node build/index.jsLicense
MIT
Acknowledgements
Available Tools
4 toolsget-movie-detailsC
Get detailed information about a specific movie
| Name | Required | Description | Default |
|---|---|---|---|
| movieId | Yes | ID of the movie to get details for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves details but doesn't mention whether it's a read-only operation, potential rate limits, error conditions, or what 'detailed information' entails. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every part contributing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, potential response formats, or behavioral traits like safety or performance. For a tool with no structured context, this leaves critical gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the 'movieId' parameter. The description adds no additional parameter semantics beyond implying the tool requires a specific movie, which is already covered by the schema. This meets the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific movie'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get-similar' or 'search-movies', which might also retrieve movie information in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search-movies' or 'get-similar'. It lacks context about prerequisites (e.g., needing a movie ID) or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-similarC
Get similar movies to a given movie
| Name | Required | Description | Default |
|---|---|---|---|
| movieId | Yes | ID of the movie to find similar movies for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It doesn't describe response format, error handling, rate limits, or other behavioral traits beyond the basic operation, which is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, making it appropriately sized and front-loaded. Every word contributes directly to the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns a list of movies. It doesn't explain what 'similar' means (e.g., genre, director, ratings), the return format, or any limitations, leaving significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents the 'movieId' parameter fully. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, resulting in the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('similar movies'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'search-movies' or 'get-trending' beyond the basic concept of similarity, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search-movies' or 'get-trending'. It lacks explicit context, exclusions, or prerequisites, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-trendingC
Get trending movies
| Name | Required | Description | Default |
|---|---|---|---|
| timeWindow | No | Time window for trending movies |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Get trending movies') without revealing any behavioral traits such as rate limits, authentication needs, data freshness, or response format (e.g., list of movies with scores). This leaves critical operational aspects unspecified, making it inadequate for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Get trending movies'), consisting of a single, front-loaded sentence that directly conveys the core functionality without any wasted words. It is appropriately sized for a simple tool with one optional parameter, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns a list of trending movies. It does not address what 'trending' means, how results are ordered, or what data is included in the response. While the schema covers the parameter well, the overall context for using the tool effectively is insufficient, especially for an agent needing to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'timeWindow' fully documented in the schema (enum: 'day', 'week'). The description adds no additional meaning beyond the schema, such as explaining the impact of timeWindow on results or default behavior. Given the high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get trending movies' clearly states the verb ('Get') and resource ('trending movies'), making the purpose immediately understandable. It distinguishes from siblings like 'get-movie-details' (specific movie info), 'get-similar' (related movies), and 'search-movies' (query-based search) by focusing on trending content. However, it lacks specificity about what 'trending' entails (e.g., popularity metrics, ranking criteria), preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention use cases (e.g., discovering popular movies, time-sensitive trends) or exclusions (e.g., not for detailed movie info or search queries). Without such context, an agent must infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search-moviesC
Search for movies by title or keywords
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| page | No | Page number for results |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches for movies but doesn't mention key behaviors like whether it's read-only (likely, but not confirmed), how results are returned (e.g., format, pagination details beyond the 'page' parameter), or any limitations (e.g., rate limits, authentication needs). This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose and avoids redundancy, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search functionality with pagination), no annotations, and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., read-only status, result format), usage context relative to siblings, and output expectations, leaving the agent with incomplete guidance for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('query' and 'page') documented in the schema. The description adds minimal value beyond the schema by implying the 'query' parameter is for title/keyword searches, but it doesn't provide additional context like search syntax, result ordering, or default behaviors. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Search') and resource ('movies'), and specifies the search criteria ('by title or keywords'). However, it doesn't explicitly differentiate from sibling tools like 'get-trending' or 'get-similar', which might also involve movie discovery but through different mechanisms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-trending' (for popular movies) or 'get-similar' (for recommendations based on a known movie). It mentions the search criteria but doesn't clarify scenarios where this is preferred over sibling tools, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a clearly distinct purpose: get-movie-details retrieves specific movie information, get-similar finds related movies, get-trending lists popular movies, and search-movies performs keyword-based queries. There is no overlap in functionality, making tool selection straightforward for an agent.
All tools follow a consistent verb-noun pattern using kebab-case (e.g., get-movie-details, get-similar, get-trending, search-movies). The naming is uniform and predictable, with 'get' for retrieval operations and 'search' for querying, enhancing readability and usability.
With 4 tools, the server is well-scoped for basic movie discovery and information retrieval. While it covers core functions like details, similarity, trends, and search, it might feel slightly thin for a full movie database API, but it is reasonable and focused.
The tool set covers key read operations for movie data, including details, similarity, trends, and search. However, there are notable gaps such as no update, delete, or creation tools (if applicable to the domain), and missing operations for TV shows, actors, or reviews, which could limit agent workflows in broader contexts.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
The media memory layer for AI agents and their humans. Your AI client gets 29 tools to search your collection, add items, update ratings, preview music, and find patterns across everything you've read, watched, and listened to.
Turn Claude into a creative studio: DNA-locked characters, images, video, voiceover — 55 tools.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Search, read, create and edit your Memol notes from Claude. Team note-taking with AI search.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to search and retrieve movie information from The Movie Database (TMDB) API through the Model Context Protocol interface.632MIT
- AlicenseNot gradedqualityDmaintenanceProvides integration with The Movie Database (TMDB) API for searching movies, TV shows, and people, accessing detailed information, and discovering popular and trending content. Enables AI assistants to access comprehensive movie and television metadata including ratings, cast, crew, and overviews.631MIT
- FlicenseNot gradedqualityNot gradedmaintenanceProvides access to The Movie Database (TMDB) API for searching movies, retrieving movie details, cast information, and browsing current, upcoming, popular, and top-rated films, as well as searching for actors and directors.63
- AlicenseAqualityCmaintenanceProvides access to The Movie Database (TMDB) API, enabling users to search for movies, TV shows, and people, get detailed information, discover content with advanced filters, and retrieve recommendations.13635MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ShubhanshuSondhiya/MCP-TMDB'
If you have feedback or need assistance with the MCP directory API, please join our Discord server