Skip to main content
Glama

remove_tracks

Remove tracks from your Spotify library to maintain a curated collection of current favorites. Clean up outdated music, remove accidental saves, and update your library to reflect changing musical tastes.

Instructions

Remove tracks from the user's personal library to maintain a curated collection of current favorites.

🎯 USE CASES: • Clean up library by removing tracks you no longer enjoy • Maintain relevance in your personal music collection • Remove accidental saves and unwanted additions • Update library to reflect changing musical tastes • Organize library by removing outdated preferences

📝 WHAT IT RETURNS: • Confirmation of successful track removals • Updated library count after removals • List of successfully removed tracks • Error details for tracks that couldn't be removed • Final library state after cleanup operation

🔍 EXAMPLES: • "Remove 'Old Song' from my liked tracks" • "Unlike these 3 tracks I no longer enjoy" • "Remove track IDs: 1BxfuPKGuaTgP6aM0NMpti, 4LRPiXqCikLlN15c3yImP7" • "Clean up my library by removing outdated music"

🧹 LIBRARY MAINTENANCE: • Keeps collection current and relevant • Reflects evolving musical tastes • Maintains quality over quantity approach • Perfect for regular library cleanup sessions • Essential for curated collection management

💡 CURATION TIPS: • Regular cleanup keeps library fresh • Remove tracks that no longer resonate • Consider seasonal relevance for cleanup timing • Use bulk removals for major library overhauls • Keep library aligned with current preferences

⚠️ REQUIREMENTS: • Valid Spotify access token with user-library-modify scope • Track IDs must match exactly for successful removal • Maximum 50 tracks can be removed per request

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesSpotify access token for authentication
trackIdsYesArray of Spotify track IDs to remove

Implementation Reference

  • The handler function for the 'remove_tracks' tool that extracts arguments and calls SpotifyService.removeTracks
    handler: async (args: any, spotifyService: SpotifyService) => {
      const { token, trackIds } = args;
      return await spotifyService.removeTracks(token, trackIds);
    },
  • Input schema validation for the 'remove_tracks' tool defining token and trackIds parameters
    schema: createSchema({
      token: commonSchemas.token(),
      trackIds: z
        .array(z.string())
        .describe("Array of Spotify track IDs to remove"),
    }),
  • Registration of all tools by spreading trackTools (containing 'remove_tracks') into the central allTools registry used for MCP tool listing and execution
    export const allTools: ToolsRegistry = {
      ...albumTools,
    
      ...artistTools,
    
      ...trackTools,
    
      ...playlistTools,
    
      ...playbackTools,
    
      ...userTools,
    
      ...searchTools,
    };
  • Core helper method in SpotifyService that performs the actual API call to remove tracks from user's library via DELETE /me/tracks
    async removeTracks(
      token: string,
      trackIds: string | string[]
    ): Promise<void> {
      const ids = Array.isArray(trackIds)
        ? trackIds.map((id) => this.extractId(id))
        : [this.extractId(trackIds)];
      const params = { ids: ids.join(",") };
      return await this.makeRequest<void>("me/tracks", token, params, "DELETE");
    }
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (removes tracks), return values (confirmation, updated count, list of removed tracks, errors, final state), and constraints (max 50 tracks per request, exact track ID matching). It also mentions authentication requirements (Spotify token with user-library-modify scope), which is crucial for a mutation tool. It lacks details on rate limits or error handling specifics, but covers core behavioral aspects well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (USE CASES, WHAT IT RETURNS, etc.), but it is overly verbose. Sections like 'LIBRARY MAINTENANCE' and 'CURATION TIPS' contain redundant information already covered in 'USE CASES', and the multiple examples could be condensed. While front-loaded with purpose, it includes unnecessary elaboration that reduces conciseness.

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?

Given no annotations, no output schema, and a mutation tool with 2 parameters, the description provides substantial context: purpose, usage, returns, examples, requirements, and behavioral details. It covers authentication, constraints, and expected outcomes comprehensively. However, it lacks explicit error handling guidance or rate limit information, leaving minor gaps for full completeness.

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 has 100% description coverage, so the baseline is 3. The description adds value by explaining parameter semantics in the 'REQUIREMENTS' section: it clarifies that 'trackIds' must match exactly and have a maximum of 50 per request, and that 'token' requires a specific Spotify scope (user-library-modify). This provides practical context beyond the schema's basic descriptions.

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 the tool removes tracks from the user's personal library, specifying the action (remove) and resource (tracks from personal library). It distinguishes from sibling tools like 'remove_from_playlist' by focusing on the personal library rather than playlists, and from 'unsave_playlist' by targeting tracks instead of playlists.

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?

The description provides explicit usage guidance through sections like 'USE CASES' (e.g., clean up library, remove accidental saves), 'LIBRARY MAINTENANCE' (e.g., keep collection current), and 'CURATION TIPS' (e.g., regular cleanup, bulk removals). It implicitly distinguishes from alternatives by focusing on personal library tracks rather than playlist operations or other Spotify actions.

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/latiftplgu/Spotify-OAuth-MCP-server'

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