Skip to main content
Glama
Sign In
Plex MCP Server

Plex MCP Server

by niavasha
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

sonarr_add_series

Add a new TV series to Sonarr using its TVDB ID and title, with options for monitoring, quality profile, tags, and episode searches.

Instructions

Add a new series to Sonarr by TVDB ID

Input Schema

NameRequiredDescriptionDefault
tagsNoTag labels to assign; labels that do not exist yet are created first (existing tags: sonarr_get_tags)
titleYesSeries title
tvdbIdYesTheTVDB ID of the series
monitoredNoWhether to monitor the series (default: true)
seriesTypeNoSeries type, used by Sonarr for renaming, parsing and searching (default: standard)
monitorTypeNoWhich episodes to monitorall
seasonFolderNoUse season folders (default: true)
rootFolderPathNoRoot folder path (auto-detected if omitted)
qualityProfileIdNoQuality profile ID (auto-detected if omitted)
searchForMissingEpisodesNoSearch for missing episodes after adding (default: true)
searchForCutoffUnmetEpisodesNoAfter adding, search for upgrades to monitored episodes whose existing files are below the quality profile's cutoff; no effect without files on disk (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.8.2
    • changedInput schema / properties / monitorType / enum
      Previous value: -[
-  "all",
-  "future",
-  "missing",
-  "existing",
-  "firstSeason",
-  "latestSeason",
-  "none"
-]New value: +[
+  "all",
+  "future",
+  "missing",
+  "existing",
+  "recent",
+  "pilot",
+  "firstSeason",
+  "lastSeason",
+  "monitorSpecials",
+  "unmonitorSpecials",
+  "none"
+]
    • addedInput schema / properties / searchForCutoffUnmetEpisodes
      Added value: +{
+  "default": false,
+  "description": "After adding, search for upgrades to monitored episodes whose existing files are below the quality profile's cutoff; no effect without files on disk (default: false)",
+  "type": "boolean"
+}
    • addedInput schema / properties / seriesType
      Added value: +{
+  "description": "Series type, used by Sonarr for renaming, parsing and searching (default: standard)",
+  "enum": [
+    "standard",
+    "daily",
+    "anime"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / tags
      Added value: +{
+  "description": "Tag labels to assign; labels that do not exist yet are created first (existing tags: sonarr_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 safety profile is covered. The description adds nothing beyond that: it doesn't say what happens on a duplicate, that a search may be triggered, that tags may be created implicitly, or that root folder/quality profile are auto-detected — all of which matter for an 11-parameter mutation.

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 nine-word sentence with the key identifier front-loaded and zero filler. It is efficient, though so terse that the brevity is close to under-specification for a tool with 11 parameters.

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?

With 100% schema coverage and annotations present, the description only needs to add the operational picture, and it largely doesn't: it is silent on duplicate handling, implicit tag creation, and what auto-detection does when rootFolderPath or qualityProfileId are omitted. There is no output schema, so a hint about the returned series record would have helped.

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 every parameter including defaults, enums and auto-detection behavior is already documented in the schema. The description only echoes the tvdbId parameter and omits 'title', which is also required. Baseline 3 applies since the schema does all the work.

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 series to Sonarr') plus the key lookup key ('by TVDB ID'), so the agent knows exactly what the call does. The tool name plus the Sonarr/Radarr prefix naturally separates it from sonarr_get_series and radarr_add_movie, but the description itself never names those siblings or the boundary between them.

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 when-to-use or when-not-to-use guidance, no mention of prerequisites (Sonarr configured, a valid TVDB ID obtained, profiles/root folders resolved), and no pointer to alternatives such as sonarr_get_series for checking whether the series already exists. Usage is only inferable from the verb 'Add'.

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