Skip to main content
Glama

Start or stop monitoring

set_monitoring

Turn monitoring on or off for Sonarr and Whisparr series, seasons, or episodes, and Lidarr albums or artists, with preview-first confirmation before changes apply.

Instructions

Turns monitoring on or off. Sonarr and Whisparr: a series (by id or title), one season, or episodes (not both). Lidarr takes level: album sets one album's flag; artist sets the artist flag and monitor_new_items (none is the only value that stops the wanted list growing by itself), and omitting artists reaches every artist. The artist flag is not the album flag: an unmonitored artist's albums drop out of get_wanted but keep their own flags and come back with the artist, so stop wanting one album with level: "album" (ids from get_media_details on the artist, or a get_wanted albumId). Radarr monitoring is update_media. Unmonitor before delete_episode_files, or Sonarr downloads the files again. Safe tier. The preview shows the current state; a season, episode or artist that does not exist is refused rather than silently written. Previews first; confirm to apply. Field reference: arr://docs/set_monitoring.

Input Schema

NameRequiredDescriptionDefault
idNoThe series id within that service, or the album id when service is lidarr, as an integer string. Required everywhere except the lidarr artist level, where it is refused.
levelNolidarr only, and required there: whether `id` names an album or an artist. Refused on every other service.
titleNoSonarr or Whisparr: a series title in place of `id`. A title two series match equally is refused with both ids.
seasonNoOne season. 0 is specials. Omit for the whole series. On Whisparr a season is a release year, e.g. 2019.
artistsNolidarr artist level only: artist ids, as integer strings. Omit to apply to every artist in that Lidarr.
confirmNoThe token from this tool's preview, passed back verbatim to apply it. Single-use and bound to the previewed arguments.
dry_runNoPreview without a confirm token, for "what would happen if" questions; not the first step of a real change.
serviceYes
episodesNoSpecific episode ids, as integer strings. Mutually exclusive with `season`.
instanceNoWhich instance (e.g. "4k") when several of this service exist. Omit it when there is one.
monitoredNotrue to monitor, false to stop. Required except on the lidarr artist level, where it sets each artist's own flag, which decides whether Lidarr wants any of its albums, and may be given alone or with `monitor_new_items`.
monitor_new_itemsNolidarr artist level only: the standing rule for albums Lidarr discovers later. `none` is what a finished, stable library wants.

Output Schema

NameRequiredDescriptionDefault
noopYes
tierYes
toolYes
resultNo
targetYes
appliedYes
dry_runYes
effectsYes
serviceYes
summaryYes
audit_idNo
warningsNo
operationYes
uncheckedNo
next_stepsNo
permissionYes
confirm_errorNo
confirm_tokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed22 schema fields changedv1.74.0
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / confirm / description
      Previous value: -"The confirmation token from this same tool's preview of this same operation. Omit it to get a preview and a token; pass the token back verbatim to apply the change. Tokens are single-use, expire, and are bound to the exact operation and arguments previewed."New value: +"The token from this tool's preview, passed back verbatim to apply it. Single-use and bound to the previewed arguments."
    • changedInput schema / properties / dry_run / description
      Previous value: -"Preview only: resolve the target and describe exactly what would happen, then stop. Never mutates anything and never returns a confirmation token. Use this to answer \"what would happen if…\" — not as the first step of actually doing it."New value: +"Preview without a confirm token, for \"what would happen if\" questions; not the first step of a real change."
    • changedInput schema / properties / instance / description
      Previous value: -"Which instance, when several of this service are configured — for example \"4k\" or \"hd\". Omit it when there is only one. If several are configured and you omit it, the call is refused and the names are listed."New value: +"Which instance (e.g. \"4k\") when several of this service exist. Omit it when there is one."
    • removedInput schema / properties / season / maximum
      Removed value: -9007199254740991
    • removedInput schema / properties / service / description
      Removed value: -"sonarr, whisparr or lidarr."
    • changedInput schema / properties / service / enum
      Previous value: -[
      -  "radarr",
      -  "sonarr",
      -  "whisparr",
      -  "lidarr",
      -  "prowlarr",
      -  "bazarr",
      -  "jellyfin",
      -  "seerr",
      -  "sabnzbd",
      -  "nzbget",
      -  "transmission",
      -  "qbittorrent",
      -  "plex",
      -  "profilarr",
      -  "cleanuparr",
      -  "reclaimerr",
      -  "dispatcharr",
      -  "shelfmark",
      -  "grimmory"
      -]New value: +[
      +  "sonarr",
      +  "whisparr",
      +  "lidarr"
      +]
    • addedInput schema / properties / title
      Added value: +{
      +  "description": "Sonarr or Whisparr: a series title in place of `id`. A title two series match equally is refused with both ids.",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • removedOutput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • removedOutput schema / properties / applied / description
      Removed value: -"Whether the change actually happened. False on every preview, refusal and no-op."
    • removedOutput schema / properties / audit_id / description
      Removed value: -"The audit row this call wrote. Every branch writes one, including previews and refusals."
    • removedOutput schema / properties / confirm_error / description
      Removed value: -"Why a presented token was rejected. Present only when one was presented."
    • removedOutput schema / properties / confirm_token / description
      Removed value: -"Present when a preview is awaiting confirmation. Single-use, expiring, bound to this exact operation and arguments."
    • removedOutput schema / properties / dry_run / description
      Removed value: -"Whether this was an explicit preview."
    • removedOutput schema / properties / effects / description
      Removed value: -"Itemised consequences, most severe first. Empty is legitimate for a no-op."
    • removedOutput schema / properties / next_steps / description
      Removed value: -"Present on an applied write when another call is worth offering. Offer it to the person; do not run it."
    • removedOutput schema / properties / noop / description
      Removed value: -"True when the request resolved but there was nothing to do — already monitored, already approved."
    • removedOutput schema / properties / result / description
      Removed value: -"Whatever the service returned, on a write that landed."
    • removedOutput schema / properties / summary / description
      Removed value: -"One sentence, safe to show a human."
    • removedOutput schema / properties / target / description
      Removed value: -"The resolved id the write acts on — what the confirmation token is bound to."
    • removedOutput schema / properties / unchecked / description
      Removed value: -"Present when a service could not be asked, so its absence from `warnings` means nothing."
    • removedOutput schema / properties / warnings / description
      Removed value: -"Present on a preview when another service has something to say about this change. Tell the user before confirming."
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only cover readOnlyHint=false and destructiveHint=false; the description adds genuinely new behavior: preview produces a token that must be passed back, the token is single-use and argument-bound, nonexistent seasons/episodes/artists are refused rather than silently written, and monitor_new_items=none is the only value that stops the wanted list growing. The artist-flag-versus-album-flag distinction is real state semantics not visible in annotations. It stops short of describing side effects on existing albums in detail, but the safety profile is well covered.

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?

Front-loaded with the one-line purpose, then branches by service in a predictable order and ends with the preview and docs pointer. The artist-flag paragraph is dense and slightly repetitive with the level semantics, but for a twelve-parameter, three-service tool nearly every sentence carries decision-relevant information.

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?

For a complex multi-service mutation tool with an output schema, the description covers service routing, level selection, ordering constraints, and the preview/confirm contract, plus a docs pointer for field-level detail. Minor gaps remain around what the preview output actually contains and per-instance behavior, but an agent has enough to invoke it correctly.

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?

Schema coverage is 92%, so the baseline is 3; the description still earns extra credit by explaining interactions the schema states only weakly: level decides whether id names an album or an artist, artists omitted reaches every artist, season and episodes are mutually exclusive, and monitor_new_items has a concrete consequence for the wanted list. It also points to where album ids come from (get_media_details on the artist, or a get_wanted albumId), which is actionable 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?

Opens with a specific verb and effect ("Turns monitoring on or off") and immediately scopes it per service: series/season/episodes for Sonarr and Whisparr, album/artist levels for Lidarr. It explicitly disclaims a sibling's territory ("Radarr monitoring is update_media"), so an agent can separate this tool from update_media and get_wanted without opening the schema.

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

Usage Guidelines5/5

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

Gives concrete when-to-use routing per service, an explicit alternative (update_media for Radarr), a workflow constraint ("Unmonitor before delete_episode_files, or Sonarr downloads the files again"), and the preview-then-confirm sequence. It also tells the agent which level to pick when only one album should stop being wanted, which is exactly the decision an agent is likely to get wrong.

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