Skip to main content
Glama
SavageCore

lidarr-mcp

by SavageCore

lidarr_media_library

Run operations on a Lidarr music library: add, update, list, search, delete artists, albums, tracks, and track files, plus monitor and preview actions.

Instructions

lidarr media library operations on Lidarr. Pass operation and an arguments dict matching that operation's parameters.

  • lidarr_add_album(body={}) — Add an album to a monitored artist (body is an AlbumResource). WRITE: this modifies your Lidarr instance.

  • lidarr_add_artist(body={}) — Add a new artist from a lookup (body is an ArtistResource). WRITE: this modifies your Lidarr instance.

  • lidarr_bulk_delete_artist(body={}) — Bulk delete artists (body carries artist ids). DESTRUCTIVE: this deletes data.

  • lidarr_bulk_delete_trackfile(body={}) — Bulk delete track files (body carries track file ids). DESTRUCTIVE: this deletes data.

  • lidarr_bulk_edit_trackfile(body={}) — Bulk update track files (body is a list of resources). WRITE: this modifies your Lidarr instance.

  • lidarr_bulk_update_artist(body={}) — Bulk update artists (body is an ArtistEditorResource). WRITE: this modifies your Lidarr instance.

  • lidarr_delete_album(id, delete_files=False, add_import_list_exclusion=False) — Delete an album. DESTRUCTIVE: this deletes data.

  • lidarr_delete_artist(id, delete_files=False, add_import_list_exclusion=False) — Delete an artist, optionally deleting files or adding an import list exclusion. Query params: delete_files, add_import_list_exclusion. DESTRUCTIVE: this deletes data.

  • lidarr_delete_trackfile(id) — Delete a track file. DESTRUCTIVE: this deletes data.

  • lidarr_get_album(id) — Fetch a single album by id.

  • lidarr_get_artist(id) — Fetch a single artist by id.

  • lidarr_get_rename(artist_id=None, album_id=None) — Preview track renames for the given artists/albums. Query params: artist_ids, album_ids.

  • lidarr_get_retag(artist_id=None, album_id=None) — Preview track file metadata retags. Query params: artist_ids, album_ids.

  • lidarr_get_track(id) — Fetch a single track by id.

  • lidarr_get_trackfile(id) — Fetch a single track file by id.

  • lidarr_list_album(artist_id=None, album_ids=None, foreign_album_id=None, include_all_artist_albums=False) — List albums, optionally filtered by artist, album ids, or foreign album id. Query params: artist_id, album_ids, foreign_album_id, include_all_artist_albums.

  • lidarr_list_artist(mb_id=None) — List all artists in the library, optionally filtered by MusicBrainz id. Query params: mb_id.

  • lidarr_list_track(artist_id=None, album_id=None, album_release_id=None, track_ids=None) — List tracks, optionally filtered by artist or album. Query params: artist_id, album_id.

  • lidarr_list_trackfile(artist_id=None, track_file_ids=None, album_id=None, unmapped=False) — List track files, optionally filtered by artist or album. Query params: artist_id, album_id.

  • lidarr_lookup_album(term=None) — Look up albums by term or MusicBrainz id (MBID). Query params: term.

  • lidarr_lookup_artist(term=None) — Look up artists by term or MusicBrainz id (MBID). Query params: term.

  • lidarr_monitor_album(body={}) — Set monitored state on multiple albums (body carries album ids). WRITE: this modifies your Lidarr instance.

  • lidarr_update_album(id, body={}) — Update an album (body is an AlbumResource). WRITE: this modifies your Lidarr instance.

  • lidarr_update_albumstudio(body={}) — Bulk studio operations across selected albums (tag, monitor, scan; body is an AlbumStudioResource). WRITE: this modifies your Lidarr instance.

  • lidarr_update_artist(id, move_files=False, body={}) — Update an artist (body is an ArtistResource). WRITE: this modifies your Lidarr instance.

  • lidarr_update_trackfile(id, body={}) — Update a track file (quality, tags). WRITE: this modifies your Lidarr instance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argumentsNo
operationYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations provided, the description carries the safety disclosure burden. It explicitly labels WRITE vs DESTRUCTIVE operations, e.g., 'DESTRUCTIVE: this deletes data', and notes additional behaviors like 'add_import_list_exclusion' and 'Preview track renames'. It does not mention permissions or other side effects, but the mutation flags are a strong addition.

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 front-loaded with the dispatch pattern and then formatted as a bulleted list, with each operation on one line including its signature and safety flag. It is long due to the number of operations, but each line is dense and free of fluff, making it appropriately concise for the scope.

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 tool with 26 sub-operations and no annotations, the description provides enough detail to select and invoke the correct operation: names, parameters, query params, and safety classifications. It lacks detailed return-value explanations, but the presence of an output schema may cover that; the main missing element is the structure of body resources.

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 only provides generic `operation` and `arguments` fields, so the description is the only source of parameter meaning. It lists specific parameters per sub-operation (e.g., `id`, `delete_files`, `body`) and often explains their purpose, like 'body carries artist ids'. This compensates well for the 0% schema coverage, though detailed body resource schemas are not described.

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 it is a dispatcher for 'lidarr media library operations' and enumerates the full set of 'lidarr_*' sub-commands. This distinguishes it from sibling tools by scope and explicitly lists the covered actions.

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?

It instructs to pass an `operation` and `arguments` dict, and each sub-command includes its parameters, implying usage for that action. However, it does not explicitly state when to prefer this tool over alternatives, such as using `lidarr_release_search` for releases or `lidarr_calendar` for calendar data.

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

Install Server

Other Tools

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/SavageCore/lidarr-mcp'

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