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., "@MCP JustWatch Server Find streaming options for The Matrix in the US"
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 Model Context Protocol (MCP) server built to provide access to JustWatch streaming availability data. Search for movies and TV shows and find out where they're available to stream across different platforms and countries.
Search Content: Search for movies and TV shows by title with detailed metadata
Streaming Availability: Get comprehensive information about where content is available to stream
Multi-Country Support: Query streaming availability across multiple countries simultaneously
Detailed Information: Access IMDb/TMDb scores, genres, runtime, release dates, and more
Offer Details: Get pricing, quality (HD/4K), and direct URLs to streaming platforms
Related MCP server: TMDB MCP Server
This server is built using:
FastMCP: A modern, decorator-based framework for building MCP servers with minimal boilerplate
simple-justwatch-python-api: GraphQL-based wrapper for the JustWatch API
Python 3.11 or higher
pip or uv package manager
Skip to "As an MCP Server" as a section to automatically download the package inside common MCP clients.
Clone the repository:
git clone <repository-url>
cd mcp-justwatchInstall the package:
pip install -e .Install with development dependencies:
pip install -e ".[dev]"This server is designed to be used with MCP clients. Add it to your MCP client configuration:
Add to your claude_desktop_config.json to automatically download the package at the start of the session using uvx.
{
"mcpServers": {
"justwatch": {
"command": "uvx",
"args": ["mcp-justwatch", "python", "-m", "mcp_justwatch.server"]
}
}
}Or if installed in a virtual environment:
{
"mcpServers": {
"justwatch": {
"command": "/path/to/venv/bin/python",
"args": ["-m", "mcp_justwatch.server"]
}
}
}See the mcphost-config.yaml example file for configuration with other MCP hosts.
pytestFormat code with Black:
black src testsLint with Ruff:
ruff check src testsContributions are welcome! Please feel free to submit a Pull Request.
This project uses the simple-justwatch-python-api, an unofficial JustWatch API wrapper. This API is in no way affiliated, associated, authorized, endorsed by, or in any way officially connected with JustWatch. This is an independent and unofficial project. Use at your own risk and discretion.
Get detailed information about a specific movie or TV show using its JustWatch node ID.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | The JustWatch node ID (obtained from search results, e.g., 'tm12345') | |
| country | No | Two-letter ISO 3166-1 alpha-2 country code (e.g., 'US', 'GB', 'DE') | US |
| language | No | ISO 639-1 language code (e.g., 'en', 'es', 'fr') | en |
| best_only | No | Return only best quality offers per platform |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states 'Get detailed information' without disclosing behavioral traits such as authentication, rate limits, or scope of data; minimal transparency.
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?
Single concise sentence with no extraneous information, efficiently conveying purpose and key detail about node_id origin.
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 is simple with 4 parameters and output schema; description adequately covers purpose and input requirement, but could add more context on node_id acquisition.
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 coverage is 100%; description adds no extra meaning beyond what's in the parameter descriptions, meeting baseline of 3.
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?
Description clearly states it retrieves detailed information about a movie/TV show using a JustWatch node ID, distinguishing it from sibling tools like get_offers_for_countries and search_content.
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?
Implies use after obtaining node_id from search results but lacks explicit guidance on when to use vs. siblings or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get streaming offers for specific content across multiple countries.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | The JustWatch node ID (from search results) | |
| countries | Yes | List of two-letter country codes (e.g., ['US', 'GB', 'CA', 'AU']) | |
| language | No | ISO 639-1 language code (e.g., 'en', 'es', 'fr') | en |
| best_only | No | Return only best quality offers per platform |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden of behavioral disclosure. It does not mention what the offers contain, whether there are limits, pagination, or side effects. The description is too sparse to inform an agent about behavioral traits.
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 concise sentence with no redundant phrasing. It is efficient, though it could include a bit more context without becoming verbose.
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 4 parameters, an output schema, and sibling tools, the description is too brief. It does not explain that node_id comes from search_content, that countries should be ISO codes, or the effect of best_only. The agent lacks sufficient context to use the tool correctly.
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% so baseline is 3. The description adds no extra meaning beyond the schema; it does not explain how to obtain node_id or what the country codes require. Thus it meets but does not exceed the baseline.
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 streaming offers for specific content across multiple countries' clearly states the verb (get) and resource (streaming offers), and implies scope (multiple countries). It distinguishes from sibling tools 'get_details' and 'search_content' which serve different purposes.
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 implies the tool is for retrieving offers across multiple countries after obtaining a node_id, but does not explicitly state when to use it versus alternatives, nor does it mention prerequisites like first using 'search_content' to get a node_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for movies and TV shows on JustWatch with streaming availability.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The title to search for (movie or TV show) | |
| country | No | Two-letter ISO 3166-1 alpha-2 country code (e.g., 'US', 'GB', 'DE') | US |
| language | No | ISO 639-1 language code (e.g., 'en', 'es', 'fr') | en |
| count | No | Maximum number of results to return (1-20) | |
| best_only | No | Return only best quality offers per platform |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, authentication requirements, rate limits, or what happens when no results are found. For a read-only search, this is a significant gap.
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, well-structured sentence that immediately conveys the tool's purpose without any extraneous words.
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 presence of an output schema (not shown but indicated), the description is sufficient for a simple search tool. However, additional context about streaming availability interpretation could be helpful.
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 coverage is 100% with descriptions for all parameters. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
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 'search', the resource 'movies and TV shows', and a distinctive aspect 'with streaming availability' on JustWatch. It effectively distinguishes from siblings like get_details and get_offers_for_countries.
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 its siblings (get_details, get_offers_for_countries) or any scenarios where it is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: search finds content, get_details provides detailed info, and get_offers_for_countries gives streaming offers across countries. No overlap.
All tools use a consistent verb_noun snake_case pattern (get_details, get_offers_for_countries, search_content), making them predictable.
Three tools is appropriate for a content discovery and streaming info server, covering the essential operations without bloat.
The set covers search, details, and multi-country offers, which are core. Minor missing features like per-country offers or trending content, but overall adequate.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Movies and TV show data — search, details, ratings, and cast from iTunes and TVmaze APIs
Streaming availability across 200+ services: titles, sources, releases.
Unlock a world of television with the TV Maze MCP server. Effortlessly search for shows by name or
OMDb MCP — IMDB-derived movie / TV / episode data (BYO key)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kkrizka/mcp-justwatch'
If you have feedback or need assistance with the MCP directory API, please join our Discord server