What can you do with this server?

This server enables AI assistants to interact with Overseerr for automated media discovery, requests, and management in your Plex ecosystem. Core Capabilities: * Search & Discovery: Unified search for movies, TV shows, and people with pagination and language support. Features highly efficient batch search and dedupe modes to check 50-100 titles at once with 99% fewer API calls. * Media Requests: Request movies or TV shows by TMDB ID with optional 4K quality, custom servers, and quality profiles. TV show requests support specific seasons or all seasons with smart confirmation for large requests (>24 episodes). * Request Management: List, approve, decline, and delete media requests with filtering by status (pending, approved, available, etc.). Permission-aware operations ensure users see only their requests while admins see all. * Detail Lookup: Retrieve flexible information about movies and TV shows using TMDB IDs with basic, standard, or full response levels including ratings, genres, runtime, and seasons. * Status Checking: Search by title to verify if media has been requested and check current status and availability. * Batch Operations: Efficient batch processing with 88% token reduction and smart caching that reduces API calls by 70-85%, optimized for workflows like anime season checks. * Smart Validation: Automatic pre-request checks, season validation, and confirmation prompts to prevent accidental bulk downloads.

Which integrations are available for this server?

Provides integration with Overseerr for automated media discovery, requests, and management in a Plex ecosystem. Enables searching for movies and TV shows, requesting media (with options for specific seasons and 4K), checking request status, managing approvals and declines, and viewing detailed media information from TMDB.

How do I use Overseerr MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Overseerr MCP Server search for the latest Marvel movies and request any that aren't already in my library" 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.

Overseerr MCP Server

by jhomen368

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

Seerr MCP Server

License: MIT Docker Version PayPal

A Model Context Protocol (MCP) server for Overseerr and Seerr (the unified successor) that enables AI assistants to search, request, and manage media through the Model Context Protocol.

🎯 Key Features

🚀 99% fewer API calls for batch operations (150-300 → 1)
⚡ 88% token reduction with compact response formats
🎯 Batch Dedupe Mode - Check 50-100 titles in one operation
🔄 Smart Caching - 70-85% API call reduction
🛡️ Safety Features - Multi-season confirmation, validation
📦 6 Tools - Search, request, and manage media | Discover Radarr/Sonarr server configurations

Related MCP server: Overseerr MCP Server

🔒 Security

🤖 Automated Security Scanning
- Dependabot for dependency updates (weekly)
- CodeQL for code vulnerability analysis (PR + weekly)
- Trivy for Docker image scanning (CI only - blocks PRs if vulnerabilities found)
- CI validates everything during PR review, CD trusts CI and publishes
🐳 Hardened Docker Images
- Non-root user (mcpuser)
- Multi-stage builds
- Minimal Alpine base
- dumb-init process management
✅ Input Validation
- URL and API key format validation
- Fails fast with clear error messages

🛠️ Available Tools

Tool	Purpose	Key Features
search_media	Search & dedupe	Single/batch search, dedupe mode for 50-100 titles, franchise awareness
request_media	Request movies/TV	Batch requests, season validation, multi-season confirmation, dry-run mode
manage_media_requests	Manage requests	List/approve/decline/delete, filtering, summary statistics
get_media_details	Get media info	Batch lookup, flexible detail levels (basic/standard/full)
get_services	List Radarr/Sonarr servers	Discover server IDs, active defaults, 4K status
get_service_details	Get server config	Quality profiles, root folders, tags per server

📋 Prerequisites

Node.js 18.0 or higher
Seerr or Overseerr instance (self-hosted or managed)
Seerr/Overseerr API key (Settings → General in your instance)

🚀 Quick Start

Option 1: NPM (Recommended)

npm install -g @jhomen368/overseerr-mcp

Configure with Claude Desktop:

Add to your configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "seerr": {
      "command": "npx",
      "args": ["-y", "@jhomen368/overseerr-mcp"],
      "env": {
        "SEERR_URL": "https://seerr.example.com",
        "SEERR_API_KEY": "your-api-key-here"
      }
    }
  }
}

Legacy Overseerr Users: If you're still using Overseerr (not Seerr), you can continue using the legacy variables:
{
  "env": {
    "OVERSEERR_URL": "https://overseerr.example.com",
    "OVERSEERR_API_KEY": "your-api-key-here"
  }
}
Both OVERSEERR_* and SEERR_* variables are supported for backward compatibility. Legacy variables will be removed in v3.0.0.

Option 2: Docker (Remote Access)

docker run -d \
  --name seerr-mcp \
  -p 8085:8085 \
  -e SEERR_URL=https://your-seerr-instance.com \
  -e SEERR_API_KEY=your-api-key-here \
  ghcr.io/jhomen368/overseerr-mcp:latest

Docker Compose:

services:
  seerr-mcp:
    image: ghcr.io/jhomen368/overseerr-mcp:latest
    container_name: seerr-mcp
    ports:
      - "8085:8085"
    environment:
      - SEERR_URL=https://your-seerr-instance.com
      - SEERR_API_KEY=your-api-key-here
    restart: unless-stopped

Test the server:

curl http://localhost:8085/health

Connect MCP clients:

Transport: Streamable HTTP
URL: http://localhost:8085/mcp

Option 3: From Source

git clone https://github.com/jhomen368/overseerr-mcp.git
cd overseerr-mcp
npm install
npm run build
node build/index.js

💡 Usage Examples

Batch Dedupe Workflow (Perfect for Anime Seasons)

// Check 50-100 titles in ONE API call
search_media({
  dedupeMode: true,
  titles: [
    "Frieren: Beyond Journey's End",
    "My Hero Academia Season 7",
    "Demon Slayer Season 4",
    // ... 47 more titles
  ],
  autoNormalize: true  // Strips "Season N", "Part N", etc.
})

Response:

{
  "summary": {
    "total": 50,
    "pass": 35,
    "blocked": 15,
    "passRate": "70%"
  },
  "results": [
    { "title": "Frieren", "status": "pass", "id": 209867 },
    { "title": "My Hero Academia S7", "status": "pass", "franchiseInfo": "S1-S6 in library" },
    { "title": "Demon Slayer S4", "status": "blocked", "reason": "Already requested" }
  ]
}

Request Media with Validation

// Single movie request
request_media({
  mediaType: "movie",
  mediaId: 438631
})

// TV show with specific seasons
request_media({
  mediaType: "tv",
  mediaId: 82856,
  seasons: [1, 2]
})

// All seasons (excludes season 0 by default)
request_media({
  mediaType: "tv",
  mediaId: 82856,
  seasons: "all"
})

Manage Requests

// List with filters
manage_media_requests({
  action: "list",
  filter: "pending",
  take: 20
})

// Batch approve
manage_media_requests({
  action: "approve",
  requestIds: [123, 124, 125]
})

// Get summary statistics
manage_media_requests({
  action: "list",
  summary: true
})

Service Discovery

// List all configured servers (Radarr + Sonarr)
get_services({})

// List only Radarr servers
get_services({ serviceType: "radarr" })

// Get quality profiles, root folders, and tags for a server
get_service_details({
  serviceType: "radarr",
  serverId: 0
})

// Use discovered values when requesting media
request_media({
  mediaType: "movie",
  mediaId: 438631,
  serverId: 0,
  profileId: 13,
  rootFolder: "/data/media/movies"
})

Natural Language Examples

Simply ask your AI assistant:

"Search for Inception in Seerr"
"Check if these 50 anime titles have been requested"
"Request Breaking Bad all seasons"
"Show me all pending media requests"
"Approve request ID 123"
"Get details for TMDB ID 550"
"What Radarr servers are configured?"
"Show me the quality profiles for my Sonarr server"

⚙️ Configuration

Environment Variables

Required:

SEERR_URL - Your Seerr/Overseerr instance URL
SEERR_API_KEY - API key from Settings → General

Legacy (deprecated, will be removed in v3.0.0):

OVERSEERR_URL - Use SEERR_URL instead
OVERSEERR_API_KEY - Use SEERR_API_KEY instead

Optional (with defaults):

CACHE_ENABLED=true                   # Enable caching
CACHE_SEARCH_TTL=300000             # Search cache: 5 min
CACHE_MEDIA_TTL=1800000             # Media cache: 30 min
CACHE_REQUESTS_TTL=60000            # Request cache: 1 min
CACHE_MAX_SIZE=1000                 # Max cache entries
CACHE_SERVICES_TTL=600000           # Services cache: 10 min
CACHE_SERVICEDETAILS_TTL=600000     # Service details cache: 10 min
REQUIRE_MULTI_SEASON_CONFIRM=true   # Confirm >24 episodes
HTTP_MODE=false                      # Enable HTTP transport
PORT=8085                            # HTTP server port

📚 Documentation

CHANGELOG.md - Version history and release notes
CONTRIBUTING.md - Contribution guidelines
Overseerr API Docs - Official API reference

🔧 Troubleshooting

Connection Issues

Verify Seerr/Overseerr URL is accessible
Check API key validity (Settings → General)
Review firewall rules for remote access

Docker Issues

# Check logs
docker logs seerr-mcp

# Verify health
curl http://localhost:8085/health

# Restart container
docker restart seerr-mcp

Build Issues

# Ensure Node.js 18+
node --version

# Clean rebuild
rm -rf node_modules build
npm install
npm run build

🤝 Contributing

Contributions welcome! Please see CONTRIBUTING.md for guidelines.

📄 License

MIT License - see LICENSE for details

🙏 Acknowledgments

Seerr - Next-generation media request and discovery tool
Overseerr - Original media request tool for Plex
Model Context Protocol - Open protocol for AI integrations
Anthropic - Creators of the MCP standard

Support this project: PayPal

Available Tools

6 tools

get_media_detailsC

Get media details. Single/batch with level control (basic/standard/full).

ParametersJSON Schema

Name	Required	Description	Default
`items`	No	Batch items
`level`	No	Detail level	standard
`fields`	No	Specific fields
`format`	No		compact
`mediaId`	No	TMDB ID (single)
`language`	No	Language code	en
`mediaType`	No	Media type (single)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It only says 'Get media details', which implies a read operation but does not disclose side effects, idempotency, auth requirements, rate limits, or any other behaviors.

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 a single sentence that is efficient and front-loaded. It conveys the core concept without extra words, though it might be too brief given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 parameters (including batch and format control) and no output schema, the description omits important details like how to specify single vs. batch format, the meaning of format/fields/language, and the output structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is high (86%), so baseline is 3. The description adds value by clarifying single vs. batch usage and the levels (basic/standard/full), but does not address fields, format, or language parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get media details') and resource, and mentions the key capabilities (single/batch, level control). However, it does not distinguish this tool from siblings like 'get_service_details' or 'search_media', which might also return media-related information.

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 provides no guidance on when to use this tool versus alternatives. It lists capabilities but does not explain the context (e.g., retrieving details vs. searching) or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_service_detailsB

Get quality profiles, root folders, tags, and language profiles (Sonarr) for a Radarr/Sonarr server.

ParametersJSON Schema

Name	Required	Description	Default
`serverId`	No	Server ID from get_services (default: 0)
`serviceType`	Yes	Service type

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It states it retrieves data but does not disclose auth requirements, side effects, rate limits, or whether the tool is read-only (implied but not explicit).

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?

One sentence, front-loaded with key purpose, no fluff. Every word earns its place.

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 simple parameters and no output schema, description adequately lists the types of data returned. Could mention that servers from get_services are needed, but it's implied. Minor gap for moderate completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (both parameters described). The description adds no extra meaning beyond the schema; it lists output types but not parameter details. Baseline 3 is appropriate.

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 resources: quality profiles, root folders, tags, and language profiles for a Radarr/Sonarr server. It distinguishes from siblings like get_media_details (media items) and get_services (list servers).

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 on when to use this tool vs siblings like get_media_details or search_media. No mention of prerequisites, when not to use, or how it fits in a workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_servicesA

List configured Radarr/Sonarr servers. Returns ID, name, isDefault, 4K status, active defaults (directory, profile, tags).

ParametersJSON Schema

Name	Required	Description	Default
`serviceType`	No	Which service type to list. Omit for both.

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. The description indicates a read operation ('List'), which is inherently non-destructive, but it does not explicitly state read-only behavior, permissions, or side effects. For a simple list operation, this is acceptable but could be more explicit.

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 two sentences, front-loading the core action and then listing return fields. Every sentence adds value, and there is no redundant or unnecessary information.

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 the simplicity of the tool (list operation with one optional parameter, no output schema), the description provides sufficient context: what the tool does and what fields are returned. No additional details (e.g., pagination) are necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully describes the single optional parameter with an enum and default behavior ('Omit for both'). The description does not add meaning beyond the schema, so a baseline score of 3 is appropriate.

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 purpose: 'List configured Radarr/Sonarr servers.' It uses a specific verb ('List') and resource ('servers'), and lists the fields returned (ID, name, isDefault, etc.). This distinguishes it from sibling tools like 'get_service_details' which likely retrieves a single server.

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 the tool is for retrieving all configured servers and mentions the fields returned. However, it does not explicitly contrast with sibling tools like 'get_service_details' or state when to use this versus alternatives, e.g., for an overview vs. detailed info.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

manage_media_requestsB

ParametersJSON Schema

Name	Required	Description	Default
`skip`	No
`sort`	No		added
`take`	No
`action`	Yes	Action
`filter`	No		all
`format`	No		compact
`summary`	No	Stats instead of list
`requestId`	No	Request ID (single)
`requestIds`	No	Request IDs (batch)

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It mentions batching and filters but does not disclose destructive nature of 'delete', side effects of 'approve'/'decline', or required permissions.

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?

Extremely concise: two sentences delivering purpose and filter options. No filler, front-loaded information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 9 parameters, multiple actions, batch support, and no output schema, the description is inadequate. Missing explanations for format, summary, batching mechanics, and action specifics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 44% (only action, summary, requestId, requestIds have descriptions). Description adds filter enum values and batching hint but does not explain skip, take, sort, format, or their interactions. Partially compensates.

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?

Description clearly states the tool manages media requests with specific actions (get/list/approve/decline/delete). It distinguishes from siblings like 'request_media' (creation) and 'search_media' (searching) by focusing on request management.

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?

Description implies usage for request management but does not explicitly guide when to use this tool vs siblings like 'request_media' or 'get_media_details'. No exclusion or alternative mention.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

request_mediaA

Request media with auto-confirm for TV ≤24 eps. Single/batch with validation. Confirm: Movies auto | TV ≤24 eps auto | TV >24 eps needs confirmed:true TV needs seasons (array or "all"). "all"=no specials; [0,1,2]=with specials

ParametersJSON Schema

Name	Required	Description
`is4k`	No	Request 4K
`items`	No	Batch items
`dryRun`	No	Preview only
`mediaId`	No	TMDB ID (single)
`seasons`	No	TV seasons. "all"=no season 0 (specials); [0,1,2]=with specials
`serverId`	No
`confirmed`	No	Confirm multi-season
`mediaType`	No	Media type (single)
`profileId`	No
`rootFolder`	No
`validateFirst`	No	Check existing

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses auto-confirm logic, validation, dry run, and TV seasons behavior. Missing details are what happens after a request is made (e.g., submission status).

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 concise, uses newlines for structure, and every sentence provides essential information. It is front-loaded with the core behavior.

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 11 parameters and no output schema, the description covers key invocation details: auto-confirm, seasons, validation. Missing are clarifications for some params like serverId, profileId, rootFolder, and the output format.

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 high (73%). The description adds significant context beyond schema, especially the auto-confirm rule and seasons interpretation. This goes beyond the baseline of 3.

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 action ('request media'), the resource, and the key auto-confirm behavior for TV ≤24 episodes. It distinguishes from siblings like search_media and manage_media_requests by specifying single/batch and validation details.

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?

Explicit guidance is provided on when auto-confirm applies (movies and TV ≤24 eps) and when confirmed:true is needed (TV >24 eps). Seasons handling is clearly explained. However, no explicit alternatives or when-not-to-use scenarios are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_mediaC

ParametersJSON Schema

Name	Required	Description	Default
`page`	No	Page number
`limit`	No	Max results
`query`	No	Single search query
`format`	No	Response format	compact
`titles`	No	Titles to check (dedupe mode)
`queries`	No	Multiple search queries (batch mode)
`language`	No	Language code	en
`dedupeMode`	No	Batch dedupe with availability check
`autoRequest`	No	Auto-request passing items (requires dedupeMode)
`autoNormalize`	No	Strip "Season N"/"Part N" from titles
`includeDetails`	No	Add details to dedupe results (dedupe only)
`requestOptions`	No	AutoRequest options
`checkAvailability`	No	Check status (slower, fetches per-result details)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description should fully disclose behavior. It mentions dedupe returns actionable statuses but fails to indicate if tool triggers requests (autoRequest) or is read-only. No side effects or auth needs disclosed.

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?

Extremely concise: two sentences covering purpose and dedupe statuses. No redundant information; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 13 parameters and no output schema, description omits output format for single/batch modes, mode selection criteria, and how to interpret results beyond dedupe. Incomplete for complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds context about dedupe statuses but does not significantly enhance parameter understanding beyond what schema descriptions provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Search movies/TV with single/batch/dedupe modes,' specifying the verb 'Search' and resource 'movies/TV.' It distinguishes from siblings like manage_media_requests or request_media, which involve different actions.

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 on when to use this tool versus alternatives (e.g., get_media_details for details, request_media for requesting). The description lacks when-not usage or explicit context for choosing modes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv2.1.3May 20, 2026
- Addedget_media_details
- Addedget_service_details
- Addedget_services
- Addedmanage_media_requests
- Addedrequest_media
- Addedsearch_media
4 tool updatesv2.1.2May 10, 2026
- Removedget_media_details
- Removedmanage_media_requests
- Removedrequest_media
- Removedsearch_media

4 tool updatesv1.0.0Jan 3, 2026

Addedget_media_details
Addedmanage_media_requests

Changedrequest_media12 fields changed

addedInput schema / properties / confirmed

Added value: +{
+  "default": false,
+  "description": "Confirm multi-season",
+  "type": "boolean"
+}

addedInput schema / properties / dryRun

Added value: +{
+  "default": false,
+  "description": "Preview only",
+  "type": "boolean"
+}

changedInput schema / properties / is4k / description

Previous value: -"Request 4K version (default: false)"New value: +"Request 4K"

addedInput schema / properties / items

Added value: +{
+  "description": "Batch items",
+  "items": {
+    "properties": {
+      "is4k": {
+        "type": "boolean"
+      },
+      "mediaId": {
+        "type": "number"
+      },
+      "mediaType": {
+        "enum": [
+          "movie",
+          "tv"
+        ],
+        "type": "string"
+      },
+      "seasons": {
+        "description": "TV seasons (REQUIRED). \"all\"=no season 0 (specials); [0,1,2]=with specials",
+        "oneOf": [
+          {
+            "items": {
+              "type": "number"
+            },
+            "type": "array"
+          },
+          {
+            "enum": [
+              "all"
+            ],
+            "type": "string"
+          }
+        ]
+      }
+    },
+    "required": [
+      "mediaType",
+      "mediaId"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedInput schema / properties / mediaId / description

Previous value: -"TMDB ID of the media"New value: +"TMDB ID (single)"

changedInput schema / properties / mediaType / description

Previous value: -"Type of media to request"New value: +"Media type (single)"

removedInput schema / properties / profileId / description
```
Removed value: -"Quality profile ID (optional)"
```
removedInput schema / properties / rootFolder / description
```
Removed value: -"Root folder path (optional)"
```

changedInput schema / properties / seasons / description

Previous value: -"For TV shows: array of season numbers or \"all\" (optional)"New value: +"TV seasons. \"all\"=no season 0 (specials); [0,1,2]=with specials"

removedInput schema / properties / serverId / description
```
Removed value: -"Specific server ID (optional)"
```

addedInput schema / properties / validateFirst

Added value: +{
+  "default": true,
+  "description": "Check existing",
+  "type": "boolean"
+}

removedInput schema / required

Removed value: -[
-  "mediaType",
-  "mediaId"
-]

Changedsearch_media14 fields changed

addedInput schema / properties / autoNormalize

Added value: +{
+  "default": false,
+  "description": "Strip \"Season N\"/\"Part N\" from titles",
+  "type": "boolean"
+}

addedInput schema / properties / autoRequest

Added value: +{
+  "default": false,
+  "description": "Auto-request passing items (requires dedupeMode)",
+  "type": "boolean"
+}

addedInput schema / properties / checkAvailability

Added value: +{
+  "default": false,
+  "description": "Check status (slower, fetches per-result details)",
+  "type": "boolean"
+}

addedInput schema / properties / dedupeMode

Added value: +{
+  "default": false,
+  "description": "Batch dedupe with availability check",
+  "type": "boolean"
+}

addedInput schema / properties / format

Added value: +{
+  "default": "compact",
+  "description": "Response format",
+  "enum": [
+    "compact",
+    "standard",
+    "full"
+  ],
+  "type": "string"
+}

addedInput schema / properties / includeDetails

Added value: +{
+  "description": "Add details to dedupe results (dedupe only)",
+  "properties": {
+    "fields": {
+      "description": "Basic: mediaType,year,posterPath | Standard: rating,overview,genres,runtime | TV: numberOfSeasons,numberOfEpisodes,seasons | Advanced: releaseDate,firstAirDate,originalTitle,originalName,popularity,backdropPath,homepage,status,tagline | Availability: mediaStatus,hasRequests,requestCount | targetSeason auto-adds for season numbers",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "includeSeason": {
+      "default": true,
+      "description": "Auto-add targetSeason for TV with season in title",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

changedInput schema / properties / language / description

Previous value: -"Language code (e.g., \"en\", default: \"en\")"New value: +"Language code"

addedInput schema / properties / limit

Added value: +{
+  "description": "Max results",
+  "type": "number"
+}

changedInput schema / properties / page / description

Previous value: -"Page number for pagination (default: 1)"New value: +"Page number"

addedInput schema / properties / queries

Added value: +{
+  "description": "Multiple search queries (batch mode)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedInput schema / properties / query / description

Previous value: -"Search query (movie/TV show/person name)"New value: +"Single search query"

addedInput schema / properties / requestOptions

Added value: +{
+  "description": "AutoRequest options",
+  "properties": {
+    "dryRun": {
+      "default": false,
+      "description": "Preview only",
+      "type": "boolean"
+    },
+    "is4k": {
+      "default": false,
+      "description": "Request 4K",
+      "type": "boolean"
+    },
+    "profileId": {
+      "type": "number"
+    },
+    "rootFolder": {
+      "type": "string"
+    },
+    "seasons": {
+      "description": "TV seasons. \"all\"=no season 0 (specials); [0,1,2]=with specials",
+      "oneOf": [
+        {
+          "items": {
+            "type": "number"
+          },
+          "type": "array"
+        },
+        {
+          "enum": [
+            "all"
+          ],
+          "type": "string"
+        }
+      ]
+    },
+    "serverId": {
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

addedInput schema / properties / titles

Added value: +{
+  "description": "Titles to check (dedupe mode)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

removedInput schema / required
```
Removed value: -[
-  "query"
-]
```

2 tool updatesNov 3, 2025
- First observedrequest_media
- First observedsearch_media

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct operation: search, request, get details, manage requests, list services, and get service details. No overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern, e.g., search_media, request_media, get_services.

Tool Count5/5

6 tools is well-scoped for a media request server, covering the essential workflows without excess or deficiency.

Completeness5/5

The tool set covers search, request, details, request management (list/approve/decline/delete), and service configuration, leaving no obvious gaps for the domain.

Maintenance

ActivityActive

ResponsivenessResponsive

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Hint-Services-obsidian-github-mcp
ai.smithery
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Note Taking Version Control File Systems
29
Serpzilla MCP ServerOAuth
com.serpzilla
Enables AI assistants to natively interact with the Serpzilla link-building marketplace.
Marketing E-commerce & Retail
1
Achriom AOAuth
com.achriom.mcp
The media memory layer for AI agents and their humans. Your AI client gets 29 tools to search your collection, add items, update ratings, preview music, and find patterns across everything you've read, watched, and listened to.
Knowledge & Memory Entertainment & Media Search
2
IFTTT MCP serverOAuth
com.ifttt
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
App Automation
1

Related MCP Servers

anilist-mcp
Art & Culture Search Open Data
yuna0x0
A
license
B
quality
C
maintenance
AniList MCP server for accessing AniList API data
Updated 2 months ago (2026-07-13 10:44 UTC)
44
123
86
MIT
Overseerr MCP Server
Entertainment & Media App Automation
reallycleansauce
A
license
Not graded
quality
D
maintenance
Enables interaction with Overseerr API to manage movie and TV show requests, allowing users to check server status and filter requests by various criteria.
Updated a year ago (2025-08-04 08:09 UTC)
MIT
Overseerr MCP Server
Entertainment & Media Content Management Systems App Automation
jgarciaga
A
license
Not graded
quality
D
maintenance
Enables interaction with Overseerr API to manage movie and TV show requests, allowing users to check server status and filter media requests by various criteria.
Updated a year ago (2025-04-13 01:04 UTC)
1
MIT
Jellyseerr MCP Server
Agent Orchestration Entertainment & Media
aserper
F
license
Not graded
quality
C
maintenance
Enables interaction with Jellyseerr media request systems through natural language. Supports searching for media, creating requests, checking request status, and managing your media library workflow.
Updated a month ago (2026-08-08 23:44 UTC)
8
-

Appeared in Searches

Information about OPNsense firewall and routing platform

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

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