Skip to main content
Glama
NovaLux12

SpotifyMCP

by NovaLux12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

import_playlist

Import M3U or CSV playlist files into Spotify by parsing the document and appending its Spotify URIs to a target playlist. Use inline content or file path, with deduplication and dry-run preview.

Instructions

Parse an M3U or CSV document (the inverse of export_playlist) and append its Spotify URIs to a target playlist. Pass the document inline via content or read it from input_path. Skips non-Spotify lines, dedupes within the batch, and adds in batches of 100. Use dry_run=true to preview without writing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoDocument format; auto-detected when omitted
contentNoThe M3U or CSV document body, passed inline
dry_runNoParse and report what would be added without touching the playlist
input_pathNoRead the document from this local file instead of content
playlist_idYesTarget playlist ID or spotify:playlist: URI
response_formatNo'concise' = human prose, 'detailed' = more fields in prose, 'json' = raw API objectconcise

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.28.0
    • 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"
+}
  2. Addedv1.26.1

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It covers key non-obvious behaviors: skips non-Spotify lines, dedupes within the batch, adds in batches of 100, and supports a dry-run mode. It does not mention idempotence relative to existing playlist contents or error paths, so it is strong but not exhaustive.

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?

Three sentences with no filler. The operation and input modes are front-loaded, and the preview safety mechanism comes last. Every sentence earns its place.

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 6-parameter tool with no output schema and no annotations, the description explains input sources, accepted formats, filtering, deduplication, batching, and dry-run behavior. The main gap is the lack of detail about what the response contains after a successful import, though the response_format parameter partially covers that.

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 100%, so the schema already documents all parameters. The description adds real meaning beyond that by explaining how content and input_path are alternative input modes, clarifying the dry_run behavior, and framing format as M3U/CSV parsing. This is a solid enrichment over the structured 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?

The description names a specific verb ('Parse and append'), a precise resource ('Spotify URIs to a target playlist'), and the input formats (M3U or CSV). It also identifies itself as the inverse of export_playlist, which clearly distinguishes it from related tools like add_to_playlist or batch_add_to_playlist.

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

Usage Guidelines4/5

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

It gives clear usage context: pass the document inline via content or via input_path, and use dry_run=true to preview without writing. It does not explicitly state when to choose this over sibling tools beyond the 'inverse of export_playlist' comparison, so it stops short of full when-not 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