Skip to main content
Glama
NovaLux12

SpotifyMCP

by NovaLux12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

add_to_queue

Add a Spotify track or episode to the end of the playback queue by URI. Set dry_run to preview the change before it is applied.

Instructions

Add a track or episode to the end of the playback queue.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uriYesSpotify track or episode URI (e.g. spotify:track:...)
dry_runNoPreview only: describe what would change without performing it. Default false — pass true to preview.
device_idNoTarget device ID
response_formatNo'concise' = human prose, 'detailed' = more fields in prose, 'json' = raw API objectconcise

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.0.1
    • addedInput schema / properties / dry_run / default
      Added value: +false
    • changedInput schema / properties / dry_run / description
      Previous value: -"Preview only: validate inputs and describe exactly what would change without performing it"New value: +"Preview only: describe what would change without performing it. Default false — pass true to preview."
  2. Changed2 schema fields changedv1.31.0
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed3 schema fields changedv1.26.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / dry_run
      Added value: +{
+  "description": "Preview only: validate inputs and describe exactly what would change without performing it",
+  "type": "boolean"
+}
    • addedInput schema / properties / response_format
      Added value: +{
+  "default": "concise",
+  "description": "'concise' = human prose, 'detailed' = more fields in prose, 'json' = raw API object",
+  "enum": [
+    "concise",
+    "detailed",
+    "json"
+  ],
+  "type": "string"
+}
  4. First observedv1.0.1

TDQS

A3.5/5.0
Behavior3/5

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

Annotations only declare destructiveHint=false, so the description carries most of the burden. 'To the end of the playback queue' usefully discloses append/ordering behavior, but it omits notable traits such as the need for an active playback device and the fact that this mutation is additive-but-persistent.

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?

A single well-formed sentence with the resource and the placement constraint front-loaded; every word earns its place.

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 simple one-required-param tool with no output schema and full schema coverage, this is mostly adequate, but the device targeting (device_id) and the active-device precondition are never surfaced, leaving a real behavioral gap for an agent.

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 uri, dry_run, device_id, and response_format are all already documented in the schema, including the dry_run preview semantics and the response_format enum. The description adds nothing beyond the schema, so the 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?

The description gives a specific verb+resource ('Add a track or episode ... to the playback queue') and scopes it ('to the end'), which clearly separates it from play/pause/skip_next and get_queue siblings. It doesn't name an alternative explicitly, but the operation is unambiguous.

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?

Usage is only implied: 'to the end of the playback queue' hints at additive queuing versus immediate playback, but there is no explicit when-to-use/when-not clause and no sibling is named (e.g., play_from_search, play). An agent can infer intent but gets no routing guidance.

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