The server is an MCP toolset for interacting with a Seerr/Overseerr instance to manage media requests and queries.
Check the health/status of the Seerr/Overseerr server
List movie requests with optional filters by status or start date, with pagination controls
List TV show requests with optional filters by status or start date, with pagination controls
Submit movie requests to a specific library on behalf of a user using a TMDB ID
Submit TV show requests to a specific library on behalf of a user using a TMDB ID, optionally specifying seasons
Search for movies and TV shows available on the Seerr/Overseerr instance
Get configured Sonarr (TV) and Radarr (Movie) libraries
Get the list of users configured in Seerr/Overseerr
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., "@overseerr-mcp-server search for Dune Part Two on Overseerr"
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.
FastMCP server to interact with the Seerr API for movie and TV show requests management, built using the fastmcp library.
Project Repository: https://github.com/ptbsare/seerr-mcp-server
The server implements the following tools to interact with Seerr:
seerr_status: Get the status of the Seerr server.
seerr_movie_requests: Get a paginated list of movie requests. Accepts optional status, start_date (YYYY-MM-DDTHH:MM:SS.mmmZ format), take (default 7), and skip (default 0).
seerr_tv_requests: Get a paginated list of TV show requests. Accepts optional status, start_date (YYYY-MM-DDTHH:MM:SS.mmmZ format), take (default 7), and skip (default 0).
seerr_request_movie_to_library: Submit a movie request using its TMDB ID to a specific library, on behalf of a specific user. Requires tmdb_id, library_name, and user_display_name. Available library names and user display names (unique ones only) are fetched at server startup and included in the tool's argument descriptions.
seerr_request_tv_to_library: Submit a TV show request using its TMDB ID to a specific library, on behalf of a specific user. Requires tmdb_id, library_name, and user_display_name. Optionally accepts seasons (list of integers). Available library names and user display names (unique ones only) are fetched at server startup and included in the tool's argument descriptions.
seerr_search_media: Search for movies and TV shows available on Seerr. Accepts query and optional page (default 1).
seerr_get_available_libraries: Get the configured Sonarr (TV) and Radarr (Movie) server IDs and names from Seerr.
seerr_get_users: Get a list of all users configured in Seerr, including their ID, username, email, displayName, etc.
It's good to first instruct your AI assistant (e.g., Claude) to use the Seerr tools. Then it can call the appropriate tool when needed.
Try prompts like these:
Get the status of our Seerr server.
Show me the first 5 movie requests that are currently pending.
List all TV show requests from 2024-01-01 that are now available.
What movies have been requested but are not available yet?
What TV shows have recently become available in our library?
Search for the movie "Dune: Part Two" on Seerr.
What movie and TV libraries are configured in Seerr?
List all users in Seerr.
Request the movie with TMDB ID 693134 for the user 'John Doe' in the 'Movies HD' library. (Uses user_display_name='John Doe', library_name='Movies HD')
Request seasons 1 and 2 for the TV show with TMDB ID 1396 for user 'Jane Smith' in the 'TV Shows 4K' library. (Uses user_display_name='Jane Smith')
Related MCP server: nas-mcp-server
uv (installation instructions: https://github.com/astral-sh/uv)
An Seerr instance running.
API Key from your Seerr instance (Settings → API Keys).
uvx (Recommended - No Installation Required)You can run the server directly from the git repository using uvx — no clone or install needed:
uvx --from git+https://github.com/ptbsare/seerr-mcp-server.git seerr-mcp-serverAdd the following to your claude_desktop_config.json:
{
"mcpServers": {
"seerr-mcp-server": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/ptbsare/seerr-mcp-server.git",
"seerr-mcp-server"
],
"env": {
"SEERR_API_KEY": "<your_api_key_here>",
"SEERR_URL": "<your_seerr_url>"
}
}
}
}Replace <your_api_key_here> and <your_seerr_url> with your actual Seerr API key and URL.
The following environment variables are required:
SEERR_API_KEY: Your Seerr API key (found in Seerr Settings → API Keys)
SEERR_URL: The URL of your Seerr instance (e.g., http://localhost:5055)
For clients like Claude Desktop, add these to the env field as shown above. For local use, you can export them or use a .env file:
SEERR_API_KEY=your_api_key_here
SEERR_URL=http://localhost:5055If you prefer to install locally for development:
git clone https://github.com/ptbsare/seerr-mcp-server.git
cd seerr-mcp-server
uv venv
source .venv/bin/activate # On Windows use `.venv\Scripts\activate`
uv pip install -e .Follow the installation steps using uv pip install -e . for an editable install.
Install or sync dependencies using uv:
uv sync
# or
uv pip install -e .Since MCP servers run over stdio, debugging can be challenging.
MCP Inspector: The MCP Inspector is highly recommended.
Launch it pointing to your server script:
# Using uvx (no local installation needed)
npx @modelcontextprotocol/inspector uvx --from git+https://github.com/ptbsare/seerr-mcp-server.git seerr-mcp-server
# Or using uv run (from local project directory)
npx @modelcontextprotocol/inspector uv run seerr-mcp-serverAccess the URL provided by the Inspector in your browser.
Logging: The server logs basic information to stdout/stderr. Check the terminal where you ran uv run seerr-mcp-server. For clients like Claude Desktop, check the client's log files (e.g., ~/Library/Logs/Claude/mcp-server-seerr-mcp.log on macOS, but the name might vary based on your config).
MIT
Get the configured Sonarr (TV) and Radarr (Movie) server IDs and names from Overseerr.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state behavioral traits such as read-only safety, authentication requirements, or rate limits. The verb 'Get' implies a read operation, but the description fails to add clarity beyond that, leaving the agent to assume no side effects.
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, front-loaded sentence that contains no fluff. It precisely states the action and the data returned, earning its place without redundancy.
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?
For a tool with no parameters and no output schema, the description provides adequate context by naming the data returned (server IDs and names). However, it does not specify the return structure (e.g., array of objects) or handle edge cases like no configured libraries, leaving slight ambiguity. Given the simplicity, this is mostly complete.
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 tool has zero parameters, which sets the baseline at 4. The description adds no parameter info (there are none to add), but it does clarify the output content (IDs and names), indirectly explaining what the tool returns without input. This aligns with the baseline for a parameterless tool.
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 uses a specific verb ('Get') and clearly identifies the resource (configured Sonarr/Radarr server IDs and names). It distinguishes itself from sibling tools by focusing on library configuration retrieval, which is unique among the listed tools.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention prerequisites or scenarios (e.g., 'before making a request, get library IDs'). It simply states what it does without contextualizing its usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all users configured in Overseerr.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden, but it only restates the tool's name. It does not disclose authentication requirements, output format, pagination, or potential errors.
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 clear, front-loaded sentence with no wasted words. Every word contributes to meaning.
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?
For a simple zero-parameter read tool, the description is minimally adequate. However, without an output schema, it does not clarify the exact structure of the returned user list, and it lacks usage context.
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 tool has zero parameters, so the baseline of 4 applies. The description correctly adds no parameter details because there are none to explain.
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 uses a specific verb ('Get') and a specific resource ('list of all users configured in Overseerr'), clearly distinguishing it from sibling tools that search, request, or check status.
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?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a paginated list of movie requests that satisfy the filter arguments.
Args:
status (Optional[str]): Filter by media availability status (e.g., "pending", "available", "approved"). Valid values: "all", "approved", "available", "pending", "processing", "unavailable", "failed". Defaults to all if omitted or invalid.
start_date (Optional[str]): Filter for requests created on or after this date, formatted as 'YYYY-MM-DDTHH:MM:SS.mmmZ'.
take (Optional[int]): The number of results to return (page size). Defaults to 7.
skip (Optional[int]): The number of results to skip (for pagination). Defaults to 0.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | ||
| take | No | ||
| status | No | ||
| start_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it reveals meaningful behavioral traits: pagination defaults (take=7, skip=0), the default of 'all' for invalid status values, and the expected date format for start_date. However, it does not explicitly state that the operation is read-only or describe the response structure, so it is not fully transparent.
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 compact and well-structured: one sentence states the purpose, followed by a clean Args list with per-parameter explanations. Every line adds value, with no redundancy or unnecessary detail.
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?
For a simple read operation with four optional parameters, the description covers all parameter semantics and pagination behavior. However, since there is no output schema, the lack of a description of the returned payload means the agent may not know the exact fields returned, which is a minor gap.
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 0% description coverage, but the description fully compensates by explaining every parameter's semantics: valid status values, date format, and pagination defaults. This adds significant meaning beyond the schema's type and default declarations.
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 uses the verb 'Get' and clearly identifies the resource as a 'paginated list of movie requests' with filter arguments, which distinguishes it from sibling tools like `overseerr_tv_requests` that handle TV requests. This makes the tool's purpose immediately clear.
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 clearly implies usage for listing movie requests based on the resource name and filter arguments, but it does not explicitly mention alternatives such as `overseerr_tv_requests` for TV requests. This provides clear context without exclusions, thus meeting the 'clear context' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a movie request to a specific Overseerr library identified by its name, on behalf of a specific user.
Args: tmdb_id (int): The The Movie Database (TMDB) ID of the movie to request. library_name (str): The name of the target Radarr (Movie) library configured in Overseerr. Must match exactly. Available: None fetched. user_display_name (str): The exact display name of the Overseerr user making the request. Available: None fetched (or duplicates exist).
| Name | Required | Description | Default |
|---|---|---|---|
| tmdb_id | Yes | ||
| library_name | Yes | ||
| user_display_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that library_name must match exactly and that user_display_name may have duplicates, but it does not explain side effects, permissions, idempotency, or response behavior. As a mutation tool with no safety profile, 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 one-sentence summary followed by a compact Args list. Every line provides useful information without filler, and the length is appropriate for a three-parameter tool.
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?
The description covers purpose and all parameter semantics, but there is no output schema or annotations, so the description should explain return value and usage flow. It does not mention what happens after submission, error cases, or whether to fetch available libraries/users first. Adequate for a simple request but has clear gaps.
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 0%, but the description adds substantial meaning: tmdb_id is the TMDB ID, library_name is the target Radarr library name that must match exactly, and user_display_name must be an exact name and may have duplicates. It does not explicitly direct the agent to get_available_libraries or get_users, but it provides enough context to interpret the values.
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 states 'Submit a movie request to a specific Overseerr library identified by its name, on behalf of a specific user.' This specifies a clear verb (submit), resource (movie request to Overseerr library), and scope (by library name and user). It distinguishes from the sibling TV tool by explicitly mentioning movie request and Radarr (Movie) library.
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 usage for movie requests as opposed to TV requests, but it does not explicitly name alternatives like overseerr_request_tv_to_library. The parameter notes 'Available: None fetched' hint that the agent may need to fetch library/user lists first, but there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a TV show request to a specific Overseerr library identified by its name, on behalf of a specific user.
Args: tmdb_id (int): The The Movie Database (TMDB) ID of the TV show to request. library_name (str): The name of the target Sonarr (TV) library configured in Overseerr. Must match exactly. Available: None fetched. user_display_name (str): The exact display name of the Overseerr user making the request. Available: None fetched (or duplicates exist). seasons (Optional[List[int]]): List of season numbers to request. If omitted or empty, all seasons will be requested.
| Name | Required | Description | Default |
|---|---|---|---|
| seasons | No | ||
| tmdb_id | Yes | ||
| library_name | Yes | ||
| user_display_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose important constraints (library name must match exactly, duplicate display names possible) and defaults (all seasons requested if omitted). However, it omits side effects, permission requirements, and confirmation behavior.
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 compact and front-loaded with a clear purpose statement, followed by a structured parameter list. The 'Available: None fetched' and '(or duplicates exist)' parentheticals feel like placeholder or incomplete data and slightly disrupt readability, but overall it remains concise.
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?
Even though parameter semantics are well covered, the description lacks explicit linkage to sibling tools (e.g., overseerr_get_available_libraries, overseerr_get_users) for resolving the 'not fetched' names, and does not describe what the tool returns or any side effects. For a mutation-style tool, this leaves gaps for the 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?
Schema description coverage is 0%, and the description fully compensates by explaining each parameter's meaning and constraints: tmdb_id is the TMDB ID, library_name is the exact Sonarr library name, user_display_name is the exact Overseerr user, and seasons has a documented default behavior. This goes beyond the schema's bare type definitions.
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 first sentence clearly states the action ('Submit a TV show request'), the target resource ('specific Overseerr library identified by its name'), and the beneficiary ('on behalf of a specific user'). This distinguishes it from the sibling movie request tool and other contextual tools.
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 does not provide any guidance on when to use this tool versus alternatives such as overseerr_request_movie_to_library. It also fails to mention prerequisites like fetching the library list or user list, despite noting 'Available: None fetched'.
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 available on Overseerr.
Args:
query (str): The search term (e.g., movie or TV show title).
page (int): The page number for pagination (default is 1).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden of behavioral disclosure. It does not state whether the operation is read-only, what the return format is, or any authentication/rate-limit requirements. It only mentions pagination default.
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 concise with a clear one-sentence purpose followed by a structured Args section. Every part serves a purpose, though the Args section is somewhat templated and not fully integrated.
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?
The description covers the tool's purpose and parameters adequately for a simple search tool. However, without an output schema, it should describe the return value (e.g., a list of matching media) and ideally mention usage context relative to other tools.
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 description explicitly explains both parameters: query as the search term with an example, and page as the page number with default 1. This adds significant meaning beyond the bare schema, which has 0% description 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 'Search for movies and TV shows available on Overseerr' with a specific verb (search) and resource (media on Overseerr). This distinguishes it from sibling tools like overseerr_get_users or overseerr_movie_requests.
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?
No explicit guidance on when to use this tool versus alternatives such as overseerr_get_available_libraries or overseerr_request_movie_to_library. The need to search before requesting is implied by the sibling names but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of the Overseerr server. No arguments required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Get the status' implies a read-only operation, but it does not elaborate on potential side effects, authentication requirements, or the format of the response. It is minimally transparent.
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: two short sentences with no filler. It front-loads the purpose and immediately clarifies the lack of arguments.
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 simplicity (no parameters, no output schema), the description is nearly complete. It could benefit from specifying what status information is returned, but the core purpose is fully conveyed.
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 tool takes zero parameters, and the description reinforces this with 'No arguments required.' Since the schema is empty and the message is clear, the description adds sufficient context for parameter handling.
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 function with a specific verb and resource: 'Get the status of the Overseerr server.' This distinguishes it from sibling tools that focus on users, requests, or searches.
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 notes 'No arguments required,' implying when to use it (a simple status check), but it does not explicitly mention when not to use it or identify alternatives among the sibling tools. Usage context is only implied by the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a paginated list of TV show requests that satisfy the filter arguments.
Args:
status (Optional[str]): Filter by media availability status (e.g., "pending", "available", "approved"). Valid values: "all", "approved", "available", "pending", "processing", "unavailable", "failed". Defaults to all if omitted or invalid.
start_date (Optional[str]): Filter for requests created on or after this date, formatted as 'YYYY-MM-DDTHH:MM:SS.mmmZ'.
take (Optional[int]): The number of results to return (page size). Defaults to 7.
skip (Optional[int]): The number of results to skip (for pagination). Defaults to 0.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | ||
| take | No | ||
| status | No | ||
| start_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explains pagination via take/skip, default values, status filter valid values, and date format. It does not mention authentication or response structure, but for a read-only list operation, it provides substantial 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?
The description is succinct, front-loaded with the main purpose, and uses a clear Args list. Every sentence adds value; no wasted 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 no output schema, the description still provides a complete picture: what the tool returns (paginated list), all filter parameters, and defaults. It is fully adequate for selecting and invoking 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 coverage is 0%, so the description fully compensates. It explains each parameter's purpose, valid values for status, the expected date format, and defaults for take and skip, adding significant meaning beyond the raw schema.
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 the resource 'paginated list of TV show requests,' with filter arguments. It distinguishes itself from the sibling tool overseerr_movie_requests by specifying TV show requests.
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 this tool is for reading/filtering TV requests, contrasting with sibling tools like overseerr_request_tv_to_library (creating) and overseerr_movie_requests (movies). It does not explicitly name alternatives or exclusions, but the context is clear from the resource type.
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.
v0.0.2overseerr_get_available_librariesoverseerr_get_usersoverseerr_movie_requestsoverseerr_request_movie_to_libraryoverseerr_request_tv_to_libraryoverseerr_search_mediaoverseerr_statusoverseerr_tv_requestsEach tool has a clear, distinct purpose: user management, server status, request retrieval for movies/TV, request submission for movies/TV, media search, and library configuration. No overlapping tools.
All tools share the 'overseerr_' prefix, and most follow a verb_noun pattern (get_users, search_media, request_movie_to_library). However, 'status' and 'movie_requests' are nouns without a leading verb, making the pattern slightly inconsistent.
8 tools is well-scoped for an Overseerr media request management server. Each tool covers a necessary function without redundancy.
The tool set covers core workflows: searching, requesting, listing requests, and fetching context (users, libraries, status). Missing update/delete or approval actions for requests, but the primary request lifecycle is represented.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Unlock a world of television with the TV Maze MCP server. Effortlessly search for shows by name or
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ptbsare/seerr-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
