Skip to main content
Glama
niavasha

Plex MCP Server

by niavasha
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

radarr_add_movie

Add a movie to Radarr using its TMDB ID, with optional monitoring, quality profile, root folder, and post-add search settings.

Instructions

Add a new movie to Radarr by TMDB ID

Input Schema

NameRequiredDescriptionDefault
tagsNoTag labels to assign; labels that do not exist yet are created first (existing tags: radarr_get_tags)
titleYesMovie title
tmdbIdYesThe Movie Database (TMDB) ID
monitoredNoWhether to monitor the movie (default: true)
monitorTypeNoWhat to monitor (default: movieOnly). movieAndCollection also adds and monitors every other movie in its collection; monitored and searchForMovie apply only to this movie. Does not change monitored: pass monitored: false to leave the movie itself unmonitored
rootFolderPathNoRoot folder path (auto-detected if omitted)
searchForMovieNoSearch for the movie after adding (default: true)
qualityProfileIdNoQuality profile ID (auto-detected if omitted)
minimumAvailabilityNoWhen the movie is considered availablereleased

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.8.2
    • changedInput schema / properties / minimumAvailability / enum
      Previous value: -[
-  "announced",
-  "inCinemas",
-  "released",
-  "preDB"
-]New value: +[
+  "announced",
+  "inCinemas",
+  "released"
+]
    • addedInput schema / properties / monitorType
      Added value: +{
+  "description": "What to monitor (default: movieOnly). movieAndCollection also adds and monitors every other movie in its collection; monitored and searchForMovie apply only to this movie. Does not change monitored: pass monitored: false to leave the movie itself unmonitored",
+  "enum": [
+    "movieOnly",
+    "movieAndCollection",
+    "none"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / tags
      Added value: +{
+  "description": "Tag labels to assign; labels that do not exist yet are created first (existing tags: radarr_get_tags)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. Addedv1.2.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/external-call profile is covered. The description adds nothing beyond that: it doesn't say what happens on a duplicate add, whether the movie is downloaded or merely monitored, or that a search may be triggered by default.

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

Conciseness4/5

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

A single front-loaded sentence with zero filler and the key identifier named early. It is efficiently written, though the brevity reflects under-specification rather than disciplined economy.

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

Completeness3/5

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

For a 9-parameter mutation with no output schema, the description covers only the core action; duplicate handling, failure modes, and what the response contains are left unstated. The rich input schema compensates substantially, so it is adequate but not complete.

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 100%, so all nine parameters including the two enums and the tags-creation behavior are already documented in structured fields. The description only restates the tmdbId meaning, adding no semantics beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource ('Add a new movie to Radarr') plus the identifier used ('by TMDB ID'), so an agent can immediately tell this apart from read-side siblings like radarr_get_movies or radarr_search. It does not explicitly name the sibling it replaces, but the naming convention makes the boundary obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus radarr_search or radarr_get_movies, no prerequisites (does the TMDB ID need to be resolved first?), and no exclusions. The only implied routing is the schema note pointing at radarr_get_tags, which lives in the parameter description, not the tool description.

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

Deploy Server

Other Tools