Supports configuration through environment variables stored in a .env file, used for managing API keys for the movie data services.
Provides movie search and detailed information through the OMDb API, allowing users to search movies by title and year, and get complete information including synopsis, director, and actors.
Serves as the runtime environment for the MCP server, requiring version 18+ for proper functionality.
Used for development with static typing, providing type safety for the movie search and information retrieval functionality.
Handles parameter validation for movie search queries and other requests to ensure proper data formatting and error handling.
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., "@Movie Search MCP Server search movies with title "Inception" from year 2010"
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.
A complete MCP (Model Context Protocol) server for searching and obtaining detailed movie information using OMDb (IMDB) and TMDb APIs.
✅ Search movies by title and year
✅ Detailed movie information (synopsis, director, actors, etc.)
✅ Genre-based recommendations
✅ Popular/trending movies
✅ Support for multiple APIs (OMDb + TMDb)
✅ English responses
✅ Robust error handling
Related MCP server: wizzy-mcp-tmdb
Node.js 18+
TypeScript
API keys (see configuration)
Clone or create the project:
git clone <repo> # or create a new folder
cd movie-mcpInstall dependencies:
npm installBuild the project:
npm run buildRegister to get your free API key
Add the environment variable: OMDB_API_KEY=your_api_key
Register and request an API key
Add the environment variable: TMDB_API_KEY=your_api_key
Create a .env file in the project root:
OMDB_API_KEY=your_omdb_api_key
TMDB_API_KEY=your_tmdb_api_keysearch_moviesSearch movies by title and optionally by year.
Parameters:
title (string, required): Movie title
year (string, optional): Movie year
Example:
Search movies with title "Batman" from year "2008"get_movie_detailsGet complete information for a specific movie.
Parameters:
id (string, required): Movie ID (IMDB ID or TMDb ID)
source (string, optional): 'omdb' or 'tmdb' (default: 'omdb')
Example:
Get details for movie with ID "tt0468569" using source "omdb"recommend_moviesGet movie recommendations by genre.
Parameters:
genre (string, optional): Specific genre
Available genres:
action, adventure, animation, comedy, crime
documentary, drama, family, fantasy, history
horror, music, mystery, romance, science fiction
thriller, war, western
Example:
Recommend me "action" moviespopular_moviesGet the most popular movies of the week.
Parameters: None
Example:
What are the popular movies?movie_helpShow help information about all available tools.
To use this MCP server in Cursor, add the following configuration to your .cursor/mcp.json file:
{
"mcpServers": {
"movie-search": {
"command": "node",
"args": ["/full/path/to/your/project/dist/index.js"],
"env": {
"OMDB_API_KEY": "your_omdb_api_key",
"TMDB_API_KEY": "your_tmdb_api_key"
}
}
}
}Once configured, you can use the tools directly in Cursor:
// Search movies
"Search movies of Batman from 2008"
// Get details
"Give me details of movie tt0468569"
// Recommendations
"Recommend me action movies"
// Popular movies
"What are the popular movies this week?"
// Help
"Show me the movie server help"To test the server locally:
# Build
npm run build
# Run the server
npm start
# Or in development mode
npm run devnpm run build: Compile TypeScript to JavaScript
npm run dev: Build in watch mode
npm start: Run the compiled server
npm test: Run the server (start alias)
movie-mcp/
├── src/
│ ├── index.ts # Main MCP server
│ ├── movie-apis.ts # API functions
│ └── types.ts # TypeScript types
├── dist/ # Compiled JavaScript
├── package.json
├── tsconfig.json
└── README.mdMCP Protocol: Implements the Model Context Protocol standard
Multiple APIs: Combines OMDb and TMDb for better results
Validation: Uses Zod for parameter validation
TypeScript: Fully typed code
Error handling: Informative responses in case of error
Internationalization: English responses
Fork the project
Create a feature branch (git checkout -b feature/new-feature)
Commit your changes (git commit -am 'Add new feature')
Push to the branch (git push origin feature/new-feature)
Open a Pull Request
MIT License - see the LICENSE file for more details.
Make sure to run npm install
Verify that Node.js is installed (version 18+)
Verify that environment variables are configured correctly
Confirm that API keys are valid
Check your internet connection
Confirm that movie names are spelled correctly
Verify that the file is compiled (npm run build)
Check the configuration in .cursor/mcp.json
Confirm that the path to the file is correct
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Movie ID (IMDB ID or TMDb ID) | |
| source | No | Data source (omdb or tmdb) | omdb |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| genre | No | Movie genre (optional). Examples: action, comedy, drama, horror, sci-fi, romance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Movie title to search for | |
| year | No | Movie year (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_movie_detailsmovie_helppopular_moviesrecommend_moviessearch_moviesThe tools have distinct names suggesting different purposes (details, help, popular, recommend, search), but without descriptions, there's potential ambiguity. For example, 'popular_movies' and 'recommend_movies' might overlap in functionality if recommendations are based on popularity, and 'movie_help' is vague and could be confused with other tools. The naming helps, but descriptions would be needed to fully disambiguate.
The naming follows a consistent pattern with snake_case and a mix of verb_noun (e.g., 'get_movie_details', 'search_movies') and noun_verb (e.g., 'movie_help', 'popular_movies', 'recommend_movies'). There are minor deviations in word order, but overall it's readable and mostly predictable, with no chaotic mixing of styles.
With 5 tools, this is well-scoped for a movie search server. It covers key operations like searching, getting details, finding popular movies, and recommendations, which aligns with typical movie-related functionalities. The count is appropriate, not too thin or heavy for the apparent domain.
The tool set covers basic search and discovery functions (search, details, popular, recommend), but there are notable gaps. For a movie domain, missing operations might include user-specific actions (e.g., rate_movie, add_to_watchlist), filtering or sorting options, or genre-based searches. The surface is functional but incomplete for a full movie experience, likely causing some agent limitations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that exposes functionalities to use Zomato's services.
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
MCP server for AI dialogue using various LLM models via AceDataCloud
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tonderflash/movie-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
