TMDB MCP Server
Servidor MCP de TMDB
Este proyecto implementa un servidor de Protocolo de Contexto de Modelo (MCP) que se integra con la API de The Movie Database (TMDB). Permite a asistentes de IA como Claude interactuar con datos cinematográficos, ofreciendo funciones de búsqueda, recuperación de detalles y generación de contenido relacionado con las películas.
Características
Recursos
Recursos estáticos :
tmdb://info- Información sobre la API de TMDBtmdb://trending- Películas que son tendencia actualmente
Plantillas de recursos :
tmdb://movie/{id}- Información detallada sobre una película específica
Indicaciones
Reseña de película : genere una reseña de película personalizada con un estilo y una calificación específicos
Recomendación de películas : obtén recomendaciones de películas personalizadas según géneros y estados de ánimo.
Herramientas
Buscar películas : Encuentra películas por título o palabras clave
Obtenga películas en tendencia : recupere películas en tendencia por día o semana
Obtener películas similares : encuentre películas similares a una película específica
Related MCP server: TMDB MCP Server
Instrucciones de configuración
Prerrequisitos
Node.js (v16 o posterior)
npm o hilo
Clave API de TMDB
Instalación
Clonar este repositorio
git clone https://github.com/your-username/tmdb-mcp.git cd tmdb-mcpInstalar dependencias
npm installConfigurar su clave API de TMDB
Cree un archivo
.enven la raíz del proyecto (alternativa: editesrc/config.tsdirectamente)Agregue su clave API de TMDB:
TMDB_API_KEY=your_api_key_here
Construir el proyecto
npm run buildIniciar el servidor
npm start
Configuración para Claude Desktop
Abra Claude Desktop
Vaya a Configuración > pestaña Desarrollador
Haga clic en "Editar configuración" para abrir el archivo de configuración
Añade lo siguiente a tu configuración:
{
"mcpServers": {
"tmdb-mcp": {
"command": "node",
"args": ["/absolute/path/to/your/tmdb-mcp/build/index.js"]
}
}
}Reiniciar Claude Desktop
Ejemplos de uso
Uso de recursos estáticos
¿Qué es TMDB?
"Muéstrame las películas que están de moda actualmente"
Uso de plantillas de recursos
Obtén detalles de la película con ID 550 (El Club de la Lucha)
Cuéntame sobre la película con ID 155 (El Caballero de la Noche)
Uso de indicaciones
Escribe una reseña detallada de Inception con una calificación de 9/10.
"Recomiendo películas de ciencia ficción para un estado de ánimo reflexivo"
Uso de herramientas
"Busca películas sobre exploración espacial"
"¿Cuáles son las películas de tendencia hoy en día?"
Encuentra películas similares a Matrix
Desarrollo
Estructura del proyecto
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.mdPruebas
Utilice el Inspector MCP para probar su servidor durante el desarrollo:
npx @modelcontextprotocol/inspector node build/index.jsLicencia
Instituto Tecnológico de Massachusetts (MIT)
Expresiones de gratitud
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
- First observed
get-movie-details - First observed
get-similar - First observed
get-trending - First observed
search-movies
TDQS
Scored across 4 tools
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
Related MCP Connectors
Any REST/SOAP/GraphQL/OData/SQL API as MCP tools for Claude & ChatGPT. 373 connectors: SAP, ERP.
Turn Claude into a creative studio: DNA-locked characters, images, video, voiceover — 55 tools.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
One workspace of tools for Claude and ChatGPT: connect 600+ apps, generate media, build tools.
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.50 npm2MIT
- 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.50 npm1MIT
- 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.50 npm-
- AlicenseAqualityDmaintenanceProvides 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.1350 npm5MIT