overseerr-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.0.2
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
8 tools is well-scoped for an Overseerr media request management server. Each tool covers a necessary function without redundancy.
Completeness4/5
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.
Average 3.9/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 4, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![overseerr-mcp-server MCP server](https://glama.ai/mcp/servers/ptbsare/overseerr-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/ptbsare/overseerr-mcp-server)

Score Badge

Copy to your README.md:

[![overseerr-mcp-server MCP server](https://glama.ai/mcp/servers/ptbsare/overseerr-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/ptbsare/overseerr-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/ptbsare/overseerr-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server