prowlarr-mcp
prowlarr-mcp
Un servidor MCP para html.
Configuración
cd prowlarr-mcp
uv sync
cp .env.example .envDefine PROWLARR_API_KEY en .env. La clave de API está disponible en Prowlarr en
Configuración → General → Seguridad.
Configuración:
Variable | Predeterminado | Descripción |
|
| URL base de Prowlarr, incluida cualquier ruta base de URL |
| requerida | Clave de API de Prowlarr |
|
| Tiempo de espera HTTP, mayor que 0 y como máximo 300 segundos |
|
| Tope máximo aceptado por |
Related MCP server: MCP *arr Server
Ejecución
uv run prowlarr-mcpEjemplo de configuración stdio estilo Codex/OpenCode:
{
"command": "uv",
"args": [
"--directory",
"/path/to/prowlarr-mcp",
"run",
"prowlarr-mcp"
]
}Herramienta
search_releases acepta:
query: consulta de texto; una cadena vacía busca lanzamientos recientes.search_type:search,tvsearch,movie,musicobook.indexer_ids: IDs de indexadores de Prowlarr opcionales.categories: IDs de categorías Newznab opcionales.limit: número de resultados, 20 por defecto y con un tope según la configuración.offset: desplazamiento de resultados no negativo.
La respuesta es intencionadamente más pequeña que el ReleaseResource completo de Prowlarr, pero conserva indexer_id y guid para un futuro flujo de trabajo de envío de descargas. Prowlarr puede aplicar limit de forma independiente a varios indexadores, por lo que el servidor MCP también lo aplica a la respuesta combinada. truncated significa que el servidor MCP descartó parte de la respuesta que recibió; no es un indicador de paginación has_more y no puede demostrar si Prowlarr tiene resultados adicionales.
Hoja de ruta
v0.1: Buscar lanzamientos a través de los indexadores de Prowlarr configurados.
Descubrir los indexadores disponibles y las categorías de búsqueda.
Enviar un lanzamiento seleccionado a un cliente de descargas configurado.
Inspeccionar la salud de Prowlarr, el estado de los indexadores y el historial de búsquedas.
Pruebas con el cliente MCP
El repositorio incluye un cliente stdio genérico para lanzar el servidor y llamar a una herramienta:
uv run src/prowlarr_mcp/scripts/mcp_client.py \
--command "uv run prowlarr-mcp" \
--method "search_releases" \
--arguments '{"query": "yani neko"}'Usa --cwd cuando el comando del servidor deba ejecutarse desde un directorio distinto, y --timeout para anular el tiempo de espera predeterminado de 60 segundos de las llamadas a herramientas. El script imprime la salida estructurada de la herramienta como JSON y devuelve un código de salida distinto de cero ante entradas no válidas, fallos de conexión o errores de herramientas MCP.
Desarrollo
uv run ruff format --check .
uv run ruff check .
uv run pyrefly check
uv run python -m unittest discover -s testsAvailable Tools
1 toolsearch_releasesARead-onlyIdempotent
Search enabled Prowlarr indexers for Torrent or Usenet releases.
An empty query requests recent releases. Omit indexer_ids and categories to search all enabled indexers and categories. Results preserve Prowlarr's ordering. The indexer_id and guid identify a release for a future download submission capability, which is not available in version 0.1.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| offset | No | ||
| categories | No | ||
| indexer_ids | No | ||
| search_type | No | search |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| query | Yes | |
| offset | Yes | |
| releases | Yes | |
| returned | Yes | |
| truncated | Yes | |
| search_type | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds meaningful behavioral context beyond annotations: results preserve Prowlarr ordering, empty queries mean recent releases, and indexer_id plus guid are not yet usable for downloads. It does not contradict the annotations.
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: three short sentences that front-load the main action and then add behavioral clarifications. The future-download-availability caveat is a small but relevant addition that prevents the agent from assuming a download capability that doesn't exist in this version. No sentence is wasted.
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 simple parameter set, no required parameters, a complete output schema, and safety annotations, this description covers everything needed to call the tool correctly. An agent can understand the search scope, the empty-query special case, filtering by indexers/categories, and the result-ordering guarantee.
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?
With 0% schema description coverage, the description compensates by explaining the key query semantics: empty query means recent releases, and omitted indexer_ids/categories search all enabled ones. It does not explicitly describe limit, offset, or search_type, but those are straightforward from the schema defaults and the enum values. This is strong semantic coverage despite a few remaining gaps.
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 states a specific action ('Search'), a specific resource ('enabled Prowlarr indexers'), and the result domain ('Torrent or Usenet releases'). The empty-query and omit-filter explanations further clarify the scope. Although there are no sibling tools to differentiate from, the purpose is unambiguous and complete.
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 tells the agent when behaviors change: an empty query requests recent releases, and omitting indexer_ids and categories searches all enabled indexers and categories. There are no sibling tools to compare against, so the lack of alternatives guidance is acceptable; the exclusion of download submission capability is also useful context.
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.
1 tool update
v0.1.0- First observed
search_releases
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of confusing it with another. Its purpose is clearly focused on searching releases, making misselection unnecessary.
search_releases follows a clean verb_noun naming convention. With a single tool there is no conflicting pattern, and the name accurately describes the operation.
A single tool is slightly thin for a server named Prowlarr, but it is appropriate for the currently advertised search-only capability. The missing functionality is explicitly reserved for a future version, so the count is reasonable, not excessive.
The search tool offers robust coverage for querying, filtering by categories or indexer_ids, and fetching recent releases. However, there is no way to discover available indexer_ids or continue from a search result to download submission, and the description explicitly notes that capability is unavailable, leaving a meaningful workflow gap.
Maintenance
Related MCP Connectors
Search the tool catalog. Customer API key required. Catalog metadata is not a security guarantee.
Search OpenAlex papers, authors, institutions and citations. Hosted on Apify; needs an Apify token. Send your own Apify API token as an Authorization: Bearer header.
- LerpOAuthgallery.lerp
Search website motion, specs and recreation packs. Account required; OAuth or bearer API key.
Search a curated directory of agent tools, MCP servers, APIs, protocols and skills. No auth.
Related MCP Servers
- FlicenseAqualityDmaintenanceEnables interaction with qBittorrent through its Web API to search for torrents using search plugins and manage downloads. Supports torrent searching, downloading via URLs/magnet links, and torrent management operations like pause, resume, and delete.73-
- AlicenseBqualityCmaintenanceEnables unified control of \*arr media management applications (Sonarr, Radarr, Lidarr, Readarr, Prowlarr) through natural language queries. Manage TV shows, movies, music, books, search for content, monitor downloads, and check upcoming releases across all services.661,003 npm237MIT
- AlicenseAqualityDmaintenanceEnables web search capabilities via a SearXNG instance, allowing for filtered searches across categories like news, images, and science. It supports multi-language queries, time-range filtering, and safe search options to provide formatted results with metadata.1221 npmMIT
- AlicenseAqualityAmaintenanceMCP server exposing Prowlarr's API v1 as tools for managing indexers, applications, download clients, and more, including cross-indexer searches and system commands.10MIT