Skip to main content
Glama
gbone001

media-stack-mcp

by gbone001
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

media-stack-mcp

What This Is

media-stack-mcp is a Model Context Protocol server for operating a self-hosted media stack:

  • Radarr

  • Sonarr

  • Prowlarr

  • SABnzbd

  • qBittorrent

The primary deployment target is QNAP Docker. In Docker mode this runs as a persistent Streamable HTTP MCP endpoint:

http://<qnap-ip>:3000/mcp

For Claude remote MCP/custom connector usage, publish the same MCP server through Cloudflare Tunnel:

https://mcp.yourdomain.com/mcp

Clients must send:

Authorization: Bearer <MCP_HTTP_TOKEN>

The container exposes an unauthenticated health endpoint:

http://<qnap-ip>:3000/healthz

Related MCP server: Arr Suite MCP Server

Clone The Repo Locally And Build Docker

Use this path if you want to clone the repository on your workstation, build the Docker image locally, and optionally smoke-test the HTTP server before deploying it on the QNAP.

Clone the repo locally:

git clone https://github.com/gbone001/media-stack-mcp.git
cd media-stack-mcp

Create a local .env from the example:

cp .env.example .env

Edit .env and set at least:

MCP_TRANSPORT=http
MCP_HTTP_HOST=0.0.0.0
MCP_HTTP_PORT=3000
MCP_HTTP_TOKEN=use_a_long_random_secret_here

If you want to run the container locally, use LAN IP URLs for Radarr, Sonarr, Prowlarr, SABnzbd, and qBittorrent unless those services are also running on the same local Docker network:

RADARR_URL=http://<qnap-ip>:7878
SONARR_URL=http://<qnap-ip>:8989
PROWLARR_URL=http://<qnap-ip>:9696
SABNZBD_URL=http://<qnap-ip>:8080
QBITTORRENT_URL=http://<qnap-ip>:5080

Build the Docker image locally:

docker build -t media-stack-mcp .

This does not require Node.js or pnpm on your workstation. The Dockerfile installs and builds everything inside the image.

Optional local smoke test:

docker run --rm -p 3000:3000 --env-file .env -e MCP_TRANSPORT=http media-stack-mcp

In another terminal, check:

curl http://localhost:3000/healthz

Expected response:

{"ok":true,"name":"media-stack-mcp","transport":"http"}

When you are ready to run it on the QNAP, SSH into the QNAP and either clone the same repo there or pull the latest code in the existing QNAP checkout:

cd /share/Container/media-stack-mcp
git pull
docker compose up -d --build

The included docker-compose.yml is the preferred QNAP runtime path because it publishes port 3000, loads .env, and attaches the container to the expected media-stack Docker network.

For Claude, also configure Cloudflare Tunnel so the public HTTPS URL routes to the internal Docker service:

https://mcp.yourdomain.com -> http://media-stack-mcp:3000

QNAP Docker Quick Start

SSH into your QNAP and choose an install location:

mkdir -p /share/Container
cd /share/Container
git clone https://github.com/gbone001/media-stack-mcp.git
cd media-stack-mcp

Create your runtime config:

cp .env.example .env
vi .env

At minimum, change the token:

MCP_HTTP_TOKEN=use_a_long_random_secret_here

Build and start the MCP container:

docker compose up -d --build

Watch startup logs:

docker compose logs -f media-stack-mcp

Claude HTTPS Setup

Claude remote MCP/custom connectors need a trusted HTTPS URL. This project ships an optional cloudflared sidecar in Docker Compose so the MCP app can stay plain HTTP inside Docker while Cloudflare publishes HTTPS externally.

The sidecar is off by default and lives behind the cloudflare Compose profile. Enable it by adding --profile cloudflare to your compose commands (see below). If you reach the MCP another way (LAN only, your own reverse proxy, etc.), you can ignore this section entirely and leave CLOUDFLARED_TOKEN blank.

The important lesson from Claude setup is that Claude does not connect to the QNAP LAN URL directly. Use the Cloudflare HTTPS hostname in Claude, not http://<qnap-ip>:3000/mcp, not localhost, and not a self-signed HTTPS URL.

Claude needs:

  • a publicly reachable https:// URL with a trusted certificate

  • the full MCP path, for example https://mcp.yourdomain.com/mcp

  • the bearer token header: Authorization: Bearer <MCP_HTTP_TOKEN>

  • no extra browser-only login page in front of /mcp

In the Cloudflare Zero Trust dashboard:

  1. Create a Cloudflare Tunnel.

  2. Choose Docker as the connector environment.

  3. Add a public hostname, for example mcp.yourdomain.com.

  4. Set the tunnel service target to:

http://media-stack-mcp:3000

Copy the tunnel token into .env:

CLOUDFLARED_TOKEN=your_cloudflare_tunnel_token

Set the public MCP URL and allowed Host header:

MCP_PUBLIC_URL=https://mcp.yourdomain.com/mcp
MCP_ALLOWED_HOSTS=mcp.yourdomain.com

Start or update the stack with the tunnel enabled:

docker compose --profile cloudflare up -d --build

Check the Cloudflare Tunnel logs:

docker compose logs -f cloudflared

Use this URL in Claude:

https://mcp.yourdomain.com/mcp

Use this header:

Authorization: Bearer <MCP_HTTP_TOKEN>

Do not put Cloudflare Access in front of /mcp unless your Claude client can send the required Cloudflare Access headers. Keep MCP_HTTP_TOKEN as the MCP protection layer.

Claude connector values should look like this:

Name: media-stack
URL: https://mcp.yourdomain.com/mcp
Authorization header: Bearer your_long_random_mcp_token

If Claude asks for separate auth fields, use:

Header name: Authorization
Header value: Bearer your_long_random_mcp_token

The token must be the value from MCP_HTTP_TOKEN, not the Cloudflare tunnel token.

Do not paste CLOUDFLARED_TOKEN into Claude. That token is only for the cloudflared Docker sidecar.

Required .env Values

These MCP settings should be present for QNAP Docker mode:

MCP_SERVER_NAME=media-stack-mcp
MCP_TRANSPORT=http
MCP_HTTP_HOST=0.0.0.0
MCP_HTTP_PORT=3000
MCP_HTTP_PATH=/mcp
MCP_HTTP_TOKEN=use_a_long_random_secret_here
MCP_PUBLIC_URL=https://mcp.yourdomain.com/mcp
MCP_ALLOWED_HOSTS=mcp.yourdomain.com
CLOUDFLARED_TOKEN=your_cloudflare_tunnel_token

Configure whichever media apps you want enabled. A tool returns a clear configuration error if its matching app URL/key is missing.

RADARR_URL=http://radarr:7878
RADARR_API_KEY=your_radarr_api_key

SONARR_URL=http://sonarr:8989
SONARR_API_KEY=your_sonarr_api_key

PROWLARR_URL=http://prowlarr:9696
PROWLARR_API_KEY=your_prowlarr_api_key

SABNZBD_URL=http://sabnzbd:8080
SABNZBD_API_KEY=your_sabnzbd_api_key

QBITTORRENT_URL=http://vpn:5080
QBITTORRENT_USERNAME=admin
QBITTORRENT_PASSWORD=your_qbittorrent_password

For Radarr, Sonarr, and Prowlarr, get the API key from each app's UI under Settings -> General -> Security / API Key.

For SABnzbd, get the API key from Config -> General -> Security / API Key.

For qBittorrent, use the WebUI URL and WebUI username/password.

Docker Networking On QNAP

The included docker-compose.yml expects an existing external Docker network named media-stack:

networks:
  media-stack:
    external: true

List Docker networks on the QNAP:

docker network ls

Inspect which networks your existing media containers use:

docker inspect radarr --format '{{json .NetworkSettings.Networks}}'
docker inspect sonarr --format '{{json .NetworkSettings.Networks}}'
docker inspect prowlarr --format '{{json .NetworkSettings.Networks}}'
docker inspect sabnzbd --format '{{json .NetworkSettings.Networks}}'
docker inspect vpn --format '{{json .NetworkSettings.Networks}}'

If media-stack already exists and your media containers are on it, no compose change is needed.

If your media stack uses a different network name, update docker-compose.yml to use that network instead of media-stack.

If the network does not exist, create it:

docker network create media-stack

Then attach existing containers as needed:

docker network connect media-stack radarr
docker network connect media-stack sonarr
docker network connect media-stack prowlarr
docker network connect media-stack sabnzbd
docker network connect media-stack vpn

When this MCP container shares a Docker network with your media apps, use container DNS names:

RADARR_URL=http://radarr:7878
SONARR_URL=http://sonarr:8989
PROWLARR_URL=http://prowlarr:9696
SABNZBD_URL=http://sabnzbd:8080
QBITTORRENT_URL=http://vpn:5080

If it does not share a Docker network, use your QNAP or LAN IP instead:

RADARR_URL=http://<qnap-ip>:7878
SONARR_URL=http://<qnap-ip>:8989
PROWLARR_URL=http://<qnap-ip>:9696
SABNZBD_URL=http://<qnap-ip>:8080
QBITTORRENT_URL=http://<qnap-ip>:5080

If qBittorrent runs behind Gluetun and the WebUI is exposed by the VPN/Gluetun container, use the container that exposes the WebUI. Commonly:

QBITTORRENT_URL=http://vpn:5080

Validate The Deployment

Check container status:

docker compose ps

Check logs:

docker compose logs -f media-stack-mcp

Check the health endpoint:

curl http://<qnap-ip>:3000/healthz

Expected response:

{"ok":true,"name":"media-stack-mcp","transport":"http"}

Check the Cloudflare HTTPS health endpoint:

curl https://mcp.yourdomain.com/healthz

Expected response:

{"ok":true,"name":"media-stack-mcp","transport":"http"}

Check that /mcp rejects unauthenticated requests:

curl -i -X POST http://<qnap-ip>:3000/mcp \
  -H 'Content-Type: application/json' \
  -d '{}'

Expected status:

401 Unauthorized

Check that the public HTTPS /mcp endpoint also rejects unauthenticated requests:

curl -i -X POST https://mcp.yourdomain.com/mcp \
  -H 'Content-Type: application/json' \
  -d '{}'

Expected status:

401 Unauthorized

MCP clients must call /mcp with:

Authorization: Bearer <MCP_HTTP_TOKEN>

MCP Client Config

Use this shape for clients that support remote Streamable HTTP MCP servers:

{
  "mcpServers": {
    "media-stack": {
      "url": "https://mcp.yourdomain.com/mcp",
      "headers": {
        "Authorization": "Bearer your_long_random_token"
      }
    }
  }
}

Replace mcp.yourdomain.com with your Cloudflare Tunnel hostname and your_long_random_token with MCP_HTTP_TOKEN from .env.

HTTP MCP sessions are stored in memory. Restarting the container resets active MCP sessions, which is expected.

Operations

Start or update after config changes:

docker compose up -d --build

Stop:

docker compose down

Restart:

docker compose restart media-stack-mcp

Follow logs:

docker compose logs -f media-stack-mcp

Follow Cloudflare Tunnel logs:

docker compose logs -f cloudflared

Pull the latest code and rebuild:

git pull && docker compose up -d --build

Troubleshooting

.env Not Found

Create the runtime env file:

cp .env.example .env
vi .env

network media-stack declared as external, but could not be found

Create the expected network:

docker network create media-stack

Or edit docker-compose.yml to use the Docker network your media containers already use.

MCP_HTTP_TOKEN is required when MCP_TRANSPORT=http

Set a token in .env:

MCP_HTTP_TOKEN=use_a_long_random_secret_here

Then restart:

docker compose up -d --build

CLOUDFLARED_TOKEN Is Missing Or Invalid

Create a Cloudflare Tunnel in the Cloudflare Zero Trust dashboard, copy the Docker tunnel token, and set:

CLOUDFLARED_TOKEN=your_cloudflare_tunnel_token

Then restart with the cloudflare profile and check logs:

docker compose --profile cloudflare up -d --build
docker compose logs -f cloudflared

Cloudflare Tunnel Shows 502 Or Cannot Reach The Service

In the Cloudflare Tunnel public hostname settings, the service target should be:

http://media-stack-mcp:3000

Confirm both containers are on the same Docker network:

docker compose ps
docker inspect media-stack-mcp --format '{{json .NetworkSettings.Networks}}'
docker inspect media-stack-mcp-cloudflared --format '{{json .NetworkSettings.Networks}}'

Claude Cannot Connect To The MCP URL

Use the public Cloudflare URL in Claude:

https://mcp.yourdomain.com/mcp

Do not use these in Claude remote MCP/custom connector setup:

http://<qnap-ip>:3000/mcp
http://localhost:3000/mcp
https://<qnap-ip>:3000/mcp

Then validate from outside your LAN if possible:

curl https://mcp.yourdomain.com/healthz

If health works but Claude still fails, check that Claude has the bearer token header exactly:

Authorization: Bearer <MCP_HTTP_TOKEN>

Also confirm Cloudflare is not presenting an Access login page or other browser challenge in front of /mcp.

Public HTTPS URL Returns Host Header Errors

Set MCP_ALLOWED_HOSTS to your Cloudflare Tunnel hostname:

MCP_ALLOWED_HOSTS=mcp.yourdomain.com

Then restart:

docker compose restart media-stack-mcp

401 Unauthorized

Your MCP client is missing the bearer token or using the wrong token. Configure:

Authorization: Bearer <MCP_HTTP_TOKEN>

Media App Connection Failures

Check that each URL works from inside the MCP container's network. If container names do not resolve, either attach the MCP container to the same Docker network or use LAN IP URLs.

Common same-network URLs:

RADARR_URL=http://radarr:7878
SONARR_URL=http://sonarr:8989
PROWLARR_URL=http://prowlarr:9696
SABNZBD_URL=http://sabnzbd:8080

Common LAN URLs:

RADARR_URL=http://<qnap-ip>:7878
SONARR_URL=http://<qnap-ip>:8989
PROWLARR_URL=http://<qnap-ip>:9696
SABNZBD_URL=http://<qnap-ip>:8080

Also confirm the API key is copied from the matching app, not another service.

qBittorrent Auth Failure

Confirm QBITTORRENT_URL points to the WebUI endpoint and that the WebUI credentials are correct:

QBITTORRENT_URL=http://vpn:5080
QBITTORRENT_USERNAME=admin
QBITTORRENT_PASSWORD=your_qbittorrent_password

If you use Gluetun, the correct host is often the VPN/Gluetun container rather than a separate qbittorrent container.

Current MCP Tools

Health

  • media_health_check

Radarr

  • radarr_lookup_movie

  • radarr_add_movie

  • radarr_get_queue

Sonarr

  • sonarr_lookup_series

  • sonarr_add_series

  • sonarr_get_queue

SABnzbd

  • sabnzbd_get_queue

  • sabnzbd_pause

  • sabnzbd_resume

Prowlarr

  • prowlarr_search

  • prowlarr_test_indexers

qBittorrent

  • qbittorrent_list_torrents

  • qbittorrent_pause_all

  • qbittorrent_resume_all

Local Stdio Mode

For local process-spawned MCP clients, set:

MCP_TRANSPORT=stdio

Install and build locally:

corepack enable
pnpm install
pnpm run build

Example local stdio MCP config:

{
  "mcpServers": {
    "media-stack": {
      "command": "node",
      "args": ["/path/to/media-stack-mcp/dist/index.js"],
      "env": {
        "MCP_TRANSPORT": "stdio",
        "RADARR_URL": "http://<qnap-ip>:7878",
        "RADARR_API_KEY": "your_key",
        "SONARR_URL": "http://<qnap-ip>:8989",
        "SONARR_API_KEY": "your_key",
        "SABNZBD_URL": "http://<qnap-ip>:8080",
        "SABNZBD_API_KEY": "your_key",
        "PROWLARR_URL": "http://<qnap-ip>:9696",
        "PROWLARR_API_KEY": "your_key",
        "QBITTORRENT_URL": "http://<qnap-ip>:5080",
        "QBITTORRENT_USERNAME": "admin",
        "QBITTORRENT_PASSWORD": "your_password"
      }
    }
  }
}

Security

Do not expose port 3000 directly to the public internet.

Use Cloudflare Tunnel for Claude HTTPS connectivity instead of opening inbound ports on the QNAP. Keep bearer-token auth enabled, use a long random MCP_HTTP_TOKEN, set MCP_ALLOWED_HOSTS to your public tunnel hostname, and rotate both MCP_HTTP_TOKEN and CLOUDFLARED_TOKEN if either value is shared or exposed.

Available Tools

15 tools
media_health_checkA

Check connectivity and versions for the configured media apps.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior3/5

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

No annotations provided, so the description carries the full burden. It discloses the tool checks connectivity and versions, but does not mention if it requires configuration, if it is read-only, or what happens on failure. This is adequate for a simple check but could be more detailed.

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 with no wasted words. It efficiently communicates the tool's purpose.

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?

Given no output schema, the description does not explain return values or error behavior. For a simple health check, it is minimally viable but could provide more detail about what 'check' entails.

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?

There are no parameters, so the input schema covers everything. The description does not need to add parameter information. Baseline 4 applies for zero-parameter tools.

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 checks connectivity and versions for configured media apps, using a specific verb ('check') and resource ('connectivity and versions'). It distinguishes itself from sibling tools which perform specific actions like searching, testing, or managing torrents.

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 verifying connectivity and versions, but does not provide explicit guidance on when to use this tool versus alternatives. No exclusions or context about prerequisites are given.

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

prowlarr_test_indexersA

Return Prowlarr indexers. Use this before testing individual indexers.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior2/5

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

No annotations provided, so description must convey behavioral traits. It only states 'Return Prowlarr indexers' without mentioning side effects (likely none), output format, or any safety info. Minimal disclosure beyond the action.

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?

Two sentences, no wasted words. Front-loads purpose and usage guideline. Ideal conciseness.

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 no parameters, the tool returns indexers but the description omits any output details (format, structure). Without annotations or output schema, the agent lacks guidance on interpreting results. Incomplete for practical use.

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?

No parameters exist, so schema coverage is 100% trivially. Description adds no extra parameter meaning, but baseline is 3 for high coverage; due to zero params, a 4 is appropriate as no compensation needed.

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?

Clearly states it returns Prowlarr indexers and distinguishes from sibling 'prowlarr_search' which likely uses indexers for searching. The verb 'return' and resource 'Prowlarr indexers' are specific.

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?

Explicitly says 'Use this before testing individual indexers', providing a clear usage scenario. However, it does not state when not to use it or mention alternatives, which is acceptable given the tool's simplicity.

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

qbittorrent_list_torrentsC

List qBittorrent torrents.

ParametersJSON Schema
NameRequiredDescriptionDefault
filterNo

TDQS

C2.4/5.0
Behavior2/5

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

Without annotations, the description must disclose behavioral traits. It only states 'list', implying a read operation, but omits details such as whether it returns all torrents, supports filtering behavior, pagination, or 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at one sentence, which is good for front-loading, but it sacrifices necessary detail. It earns its place but is insufficiently informative.

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

Completeness1/5

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

Given the absence of output schema, annotations, and parameter description, the tool description is not complete enough for an agent to autonomously use it correctly. Critical information about filter behavior is missing.

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

Parameters1/5

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

The input schema has one parameter 'filter' with no description (0% coverage). The tool description does not explain what 'filter' does or what values are acceptable, leaving the agent with no usable information.

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 action 'list' and the resource 'qBittorrent torrents'. It is specific and unambiguous, though it does not distinguish from sibling tools because none exist that list torrents.

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 provided on when to use this tool versus other tools, or any prerequisites or context. The description is purely declarative with no usage hints.

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

qbittorrent_pause_allA

Pause all qBittorrent torrents.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

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

No annotations provided; description only states the action without disclosing side effects, permissions, or reversibility.

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?

Single concise sentence with no unnecessary words; front-loaded purpose.

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 zero parameters and no output schema, the description covers the necessary action, though could mention API behavior briefly.

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?

Zero parameters; description correctly indicates no inputs are needed, and no additional meaning is required.

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 specific verb 'Pause' and resource 'all qBittorrent torrents', clearly distinguishing from siblings like qbittorrent_resume_all.

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; lacks context like prerequisites or recommendations.

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

qbittorrent_resume_allA

Resume all qBittorrent torrents.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention if the operation is idempotent, whether it requires authentication, or what happens if some torrents are already running. For a mutation tool, more detail is needed.

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 at five words, with no wasted text. For a tool with no parameters and a straightforward action, this level of conciseness is ideal.

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 tool's simplicity (no parameters, no output schema) and clear sibling context, the description is complete. It provides the essential information for an agent to invoke the tool correctly: what it does and on what resource.

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 input schema has zero parameters, so schema description coverage is effectively 100%. The description adds no parameter information, but none is required. Per guidelines, baseline 4 is appropriate for 0 parameters.

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 'Resume all qBittorrent torrents' with a specific verb (resume) and resource (all qBittorrent torrents). It effectively distinguishes from sibling tools like qbittorrent_pause_all by the action performed.

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 provided on when to use this tool versus alternatives like qbittorrent_pause_all or individual resume operations. There is no mention of prerequisites, context, 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.

radarr_add_movieA

Add a movie to Radarr by TMDB ID. Use radarr_lookup_movie first.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYes
tmdbIdYes
monitoredNo
rootFolderPathYes
searchForMovieNo
qualityProfileIdYes
minimumAvailabilityNo

TDQS

A3.5/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 disclose behavioral traits. It only states 'Add a movie', implying a create operation, but lacks details on authentication requirements, rate limits, whether duplicates are handled, or any side effects. This is insufficient for a mutation tool.

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 with two short sentences, each earning its place. The first sentence states the core action, and the second provides a key usage hint. No wasted words.

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?

Given the complexity (7 parameters, no output schema, no annotations), the description is incomplete. It fails to explain how to obtain necessary parameter values (e.g., qualityProfileId, rootFolderPath) or what the expected outcome or errors are. The agent is left with significant information gaps.

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

Parameters2/5

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

Schema description coverage is 0% for 7 parameters. The description adds minimal value beyond the schema by mentioning 'TMDB ID', which maps to one parameter (tmdbId). It does not explain other critical parameters like qualityProfileId, rootFolderPath, or searchForMovie, failing to compensate for the schema gaps.

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 action ('Add a movie') and the resource ('to Radarr') using a specific identifier ('by TMDB ID'). It distinguishes from sibling tools like radarr_lookup_movie (lookup) and radarr_get_queue (queue management).

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 provides explicit sequential guidance ('Use radarr_lookup_movie first'), helping the agent understand the prerequisite step. However, it does not specify when not to use this tool (e.g., if movie already exists) or compare with alternatives beyond the lookup tool.

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

radarr_get_queueC

Get Radarr download/import queue.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.7/5.0
Behavior2/5

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

The description simply says 'Get', implying a read-only operation, but provides no details about pagination, sorting, filtering, rate limits, or what the queue contains (e.g., items in progress vs completed). With no annotations, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short at one sentence, but it could be more informative without increasing length. It is under-specified, not conciseness.

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?

Given no output schema and no annotations, the description lacks crucial context about the expected output format, what a 'queue' item contains, and whether the tool supports filtering or other options.

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?

There are no parameters, so the input schema is fully covered. The description adds no extra semantic meaning, but the baseline for 0 parameters is 4.

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

Purpose3/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 'Radarr download/import queue', but does not distinguish it from sibling tools like sonarr_get_queue or sabnzbd_get_queue, which have identical phrasing.

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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or situations where this tool is or is not appropriate.

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

radarr_lookup_movieA

Search Radarr/TMDB for a movie by title.

ParametersJSON Schema
NameRequiredDescriptionDefault
termYes

TDQS

A3.9/5.0
Behavior3/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 indicates an external search, but does not disclose important traits like return format (list vs single), match behavior (exact vs fuzzy), authentication needs, or rate limits.

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 sentence with no wasted words, front-loading the key action and resource.

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?

Given the low complexity (1 param, no output schema), the description is minimal. It does not mention what the response contains (e.g., list of matches, movie details), which is a gap for a search tool without an output schema.

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 input schema has one parameter 'term' with no description (0% coverage). The description adds that the term is a movie title, providing meaningful context beyond the 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 'Search Radarr/TMDB for a movie by title' clearly states the action (search), the resource (Radarr/TMDB movie), and the method (by title). It distinguishes from sibling tools like radarr_add_movie and radarr_get_queue.

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 use when needing to find a movie by title, but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. No guidance on 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.

sabnzbd_get_queueB

Get SABnzbd queue.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are present, so the description carries full burden for behavioral disclosure. It merely states the action without any information about side effects, read-only nature, or other behavioral traits. The agent cannot infer safety or performance implications.

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 short sentence that efficiently states the purpose. It is not verbose, but for such a simple tool, it is adequately concise. However, it could be slightly more informative without losing conciseness.

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?

The tool has no output schema and no annotations, yet the description does not explain what the queue contains or the return format. For a retrieval operation, it should at least mention typical return fields (e.g., downloads, status). This lack of context leaves the agent underinformed.

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 schema has no parameters, and schema description coverage is 100% by default. The description adds no further parameter semantics, but the baseline score of 3 is appropriate since no parameters need elaboration.

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 'Get SABnzbd queue.' uses a specific verb ('Get') and resource ('SABnzbd queue'), clearly indicating the tool's action. Among sibling tools like radarr_get_queue and sonarr_get_queue, it distinguishes itself by the service name (SABnzbd).

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 provided on when to use this tool vs alternatives such as sabnzbd_pause, sabnzbd_resume, or other queue tools. The description does not mention prerequisites or usage context.

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

sabnzbd_pauseB

Pause SABnzbd.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

The description reveals only the action 'pause' without disclosing side effects, permissions, or what happens to ongoing downloads. With no annotations, the description fails to provide necessary behavioral context for an agent.

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 (3 words, 1 sentence) with no wasted text. It is front-loaded and efficient.

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?

For a tool with no output schema and no annotations, the description is too sparse. It does not explain return values, prerequisites, or behavior beyond the verb, making it incomplete for an agent to use reliably.

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 no parameters, and the schema coverage is trivially 100%. The description adds no parameter info, but none is needed. Baseline for zero parameters is 4.

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 'Pause SABnzbd' clearly states the action and target resource, effectively distinguishing it from the sibling 'sabnzbd_resume'. However, it lacks specificity on what pausing entails (e.g., all jobs, queue, or server).

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 like 'sabnzbd_resume' or context on prerequisites. The description is purely functional with no usage hints.

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

sabnzbd_resumeC

Resume SABnzbd.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.7/5.0
Behavior1/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only states the action without any details about side effects, idempotency, error conditions (e.g., what happens if already resumed), 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with a single sentence. However, it lacks helpful information beyond the bare action, making it underspecified and not adequately earned.

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?

For a simple tool with no parameters and no output schema, the description provides minimal context. It fails to explain behavior, error handling, or idempotency, leaving the agent with insufficient information for safe invocation.

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?

There are no parameters, so schema coverage is 100% by default. The description adds no parameter meaning, which is acceptable given the parameter count is zero.

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 'Resume SABnzbd.' clearly states the action and resource using a specific verb. It distinguishes from sibling tools like 'sabnzbd_pause' by implying the opposite action, though no explicit differentiation is provided.

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, such as requiring SABnzbd to be paused first, or when to avoid calling it.

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

sonarr_add_seriesC

Add a TV series to Sonarr by TVDB ID. Use sonarr_lookup_series first.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYes
tvdbIdYes
monitoredNo
seasonFolderNo
rootFolderPathYes
qualityProfileIdYes
searchForMissingEpisodesNo

TDQS

C2.9/5.0
Behavior1/5

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

No annotations provided, so description must cover behavior. It only states the action without disclosing side effects, idempotency, permissions, or error conditions.

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?

Very concise single sentence with a clear instruction, front-loaded. Could add more detail without losing conciseness.

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

Completeness1/5

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

No output schema, no annotations, 7 parameters. The description is insufficient for an agent to use this tool correctly without further info.

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

Parameters1/5

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

Schema has 7 parameters with 0% description coverage; the tool description adds no parameter information, failing to compensate.

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 specific verb 'Add' and resource 'TV series', and distinguishes from sibling tools like sonarr_lookup_series by instructing to use that first.

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?

Explicitly advises to look up series before adding via 'Use sonarr_lookup_series first', providing clear context for usage. Does not state when not to use or alternatives.

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

sonarr_get_queueA

Get Sonarr download/import queue.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

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

No annotations, so description carries full burden. It implies a read operation with 'Get', but no explicit safety or permission details are provided.

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?

Single sentence with no wasted words, directly states the tool's purpose.

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?

No output schema and no description of return values or structure, which is insufficient for an agent to understand what the queue data looks like.

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?

No parameters exist, and schema coverage is 100%, so baseline is 4. Description adds nothing beyond schema, but that is acceptable.

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 'Sonarr download/import queue', distinguishing it from siblings like radarr_get_queue.

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?

No explicit when-to-use or when-not-to-use guidance, but the tool name suggests use for Sonarr's queue while siblings cover other services.

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

sonarr_lookup_seriesB

Search Sonarr/TVDB for a TV series by title.

ParametersJSON Schema
NameRequiredDescriptionDefault
termYes

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided, and description lacks behavioral details such as return format, handling of multiple matches, or network requirements. Minimal disclosure.

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?

Single sentence with no fluff. Front-loaded with action and resource.

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?

Missing output schema and does not describe what the search returns. Incomplete for an AI agent to understand the tool's full behavior.

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

Parameters2/5

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

Schema description coverage is 0%, and description only says 'by title' for the term parameter. No format, optionality, or example provided.

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 action ('Search'), the resource ('TV series'), and the input ('by title'). It distinguishes from sibling tools like sonarr_add_series and sonarr_get_queue.

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 alternatives. Does not mention that it should be used before adding a series or any prerequisites.

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.

  1. 15 tool updatesv0.1.0
    • First observedmedia_health_check
    • First observedprowlarr_search
    • First observedprowlarr_test_indexers
    • First observedqbittorrent_list_torrents
    • First observedqbittorrent_pause_all
    • First observedqbittorrent_resume_all
    • First observedradarr_add_movie
    • First observedradarr_get_queue
    • First observedradarr_lookup_movie
    • First observedsabnzbd_get_queue
    • First observedsabnzbd_pause
    • First observedsabnzbd_resume
    • First observedsonarr_add_series
    • First observedsonarr_get_queue
    • First observedsonarr_lookup_series
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

Each tool is clearly prefixed by its associated media application (prowlarr, qbittorrent, radarr, etc.), making it easy to distinguish purposes. No two tools overlap in functionality across apps.

Naming Consistency5/5

All tools follow a consistent snake_case pattern with app_verb_noun. Even the general health check follows media_health_check. No mixing of styles.

Tool Count5/5

15 tools appropriately cover the essential operations for a media stack wrapper. The count is well-scoped, with each tool serving a distinct and necessary function.

Completeness3/5

While core operations like add, lookup, and queue management are present, there are notable gaps such as missing delete/update for movies and series, and no add torrent for qBittorrent or add nzb for SABnzbd. Agents may need workarounds for full lifecycle management.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • nas-mcp-server

    matthieurosset
    A
    license
    A
    quality
    D
    maintenance
    MCP server for managing a media server stack (Plex, Radarr, Overseerr, Bazarr, Prowlarr, Trakt.tv) using natural language to browse, request, and discover content.
    12
    MIT

  • mcp-arr-suite

    ismael9291
    A
    license
    A
    quality
    C
    maintenance
    Enables interaction with the *arr media management suite (Sonarr, Radarr, Lidarr, Prowlarr, SABnzbd) and TRaSH Guides through MCP tools, allowing media library management, searching, and configuration via natural language.
    70
    13
    1
    MIT

Latest Blog Posts

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/gbone001/media-stack-mcp'

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