MCP server for Jellyseerr, enabling media search and request management through Claude and other MCP clients
This server has moderate definition quality with significant gaps. Tool naming is generally acceptable (verb-prefixed: ping, search_media, request_media, get_request, raw_request), and all tools have descriptions. However, descriptions are inconsistent in depth, parameter descriptions are minimal or absent, and output schemas are completely undocumented. Most critically, the raw_request tool is a footgun, it bypasses all safety constraints and accepts arbitrary HTTP methods/endpoints/bodies with minimal validation. The server follows a basic structure but lacks the polish and safety guardrails expected of production-grade agent tools.
Get Jellyseerr request details/status by id.
Simple liveness check.
(Advanced) Low-level tool to call any Jellyseerr endpoint. Use with caution.
Create a media request in Jellyseerr. For TV shows, optionally specify seasons (default: [1]).
Search Jellyseerr for media by text query.
raw_request tool is a dangerous footgun with no adequate guardrails. It accepts arbitrary HTTP methods, endpoints, request bodies, and query parameters with only basic method validation (whitelist check). No documentation of what endpoints are safe, what payloads are allowed, or what the agent should expect. This violates principle:tool-gateway (treat all agent-provided input as untrusted; sanitize against injection) and pattern:permission-gate (destructive operations should be gated). An agent can trivially use raw_request to delete users, modify system configuration, or inject malicious payloads.
No output schemas documented for any tool. The rubric requires all A+ tools to have documented return types. Without knowing the structure of responses, LLMs cannot plan downstream tool calls or extract the right data. For example, search_media's response structure is unknown, does it return an array? A paginated object? What fields are in each result?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Parameter descriptions are minimal or absent. search_media documents 'query' but not what the search covers (media titles, descriptions, cast?). request_media documents seasons but not the default behavior clearly or what values are valid. raw_request documents method/endpoint/params/body generically with no guidance on safety, allowed values, or expected outcomes.
No pagination support on search_media. If Jellyseerr returns hundreds of media results, they are all returned at once, potentially exhausting the context window and degrading LLM reasoning.
request_media has undocumented dependencies: the 'seasons' parameter is optional with a default of [1], but the description does not explain what happens if seasons is omitted for a TV show, or what happens if you pass seasons for a movie (is it ignored or errored?).
request_media and raw_request are destructive (they create requests, call arbitrary endpoints) but lack confirmation/dry-run support.
No error handling guidance. If raw_request hits a 404 or the Jellyseerr API is down, the code raises RuntimeError with a message. The LLM receives this error but has no guidance on whether to retry, which tool to try next, or whether the error is fatal.
raw_request tool violates single-responsibility principle. It is a generic gateway to the entire Jellyseerr API, combining roles of multiple domain-specific tools. This makes it hard to audit, debug, and reason about safety. Per pattern:tool: 'Each tool should do exactly one thing.'
Jellyseerr API key is passed via environment variable but validated only at runtime. No checks for empty/missing API key before accepting tool calls. If JELLYSEERR_API_KEY is unset, tools will fail at runtime with cryptic API errors rather than failing fast with a clear initialization error.