Skip to main content
Glama

pause_player

Pause Spotify music playback while preserving the current position and queue state. Use this tool to temporarily stop music during calls, meetings, or when needing to pause playback without losing your place.

Instructions

Pause the current music playback while maintaining position and queue state.

🎯 USE CASES: • Pause music during calls, meetings, or conversations • Create automatic pause triggers for smart home systems • Implement voice commands for hands-free control • Pause playback when leaving designated areas • Build custom music control interfaces with pause functionality

📝 WHAT IT RETURNS: • Confirmation of successful pause operation • Final playback position before pausing • Current track information preserved for resume • Device state showing paused status • Queue information maintained for later resume

🔍 EXAMPLES: • "Pause my music" • "Stop playing on my bedroom speaker" • "Pause the current track" • "Hold the music for a moment"

💡 PAUSE BENEFITS: • Preserves exact playback position for seamless resume • Maintains queue, shuffle, and repeat settings • Keeps track information available for display • Allows for quick resume without losing context

⚠️ REQUIREMENTS: • Valid Spotify access token with user-modify-playback-state scope • Active playback session must be running • User must have appropriate device permissions

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesSpotify access token for authentication
deviceIdNoSpotify device ID (optional, uses active device if not specified)

Implementation Reference

  • The core handler function for the 'pause_player' MCP tool. It destructures the input arguments and delegates to the SpotifyService.pausePlayback method to pause the playback.
    handler: async (args: any, spotifyService: SpotifyService) => {
      const { token, deviceId } = args;
      return await spotifyService.pausePlayback(token, deviceId);
    },
  • The Zod-based input schema definition for the 'pause_player' tool, specifying the required 'token' and optional 'deviceId' parameters.
    schema: createSchema({
      token: commonSchemas.token(),
      deviceId: commonSchemas.deviceId(),
    }),
  • The SpotifyService helper method that implements the actual Spotify API call to pause playback on the specified device.
    async pausePlayback(
      token: string,
      deviceId: string | null = null
    ): Promise<void> {
      const endpoint = deviceId
        ? `me/player/pause?device_id=${deviceId}`
        : "me/player/pause";
      return await this.makeRequest<void>(endpoint, token, {}, "PUT");
    }
  • The complete tool definition object for 'pause_player', including title, description, schema, and handler, which is exported as part of playbackTools and registered via ToolRegistrar.
      pause_player: {
        title: "Pause Player",
        description: `Pause the current music playback while maintaining position and queue state.
    
    🎯 USE CASES:
    • Pause music during calls, meetings, or conversations
    • Create automatic pause triggers for smart home systems
    • Implement voice commands for hands-free control
    • Pause playback when leaving designated areas
    • Build custom music control interfaces with pause functionality
    
    📝 WHAT IT RETURNS:
    • Confirmation of successful pause operation
    • Final playback position before pausing
    • Current track information preserved for resume
    • Device state showing paused status
    • Queue information maintained for later resume
    
    🔍 EXAMPLES:
    • "Pause my music"
    • "Stop playing on my bedroom speaker"
    • "Pause the current track"
    • "Hold the music for a moment"
    
    💡 PAUSE BENEFITS:
    • Preserves exact playback position for seamless resume
    • Maintains queue, shuffle, and repeat settings
    • Keeps track information available for display
    • Allows for quick resume without losing context
    
    ⚠️ REQUIREMENTS:
    • Valid Spotify access token with user-modify-playback-state scope
    • Active playback session must be running
    • User must have appropriate device permissions`,
        schema: createSchema({
          token: commonSchemas.token(),
          deviceId: commonSchemas.deviceId(),
        }),
        handler: async (args: any, spotifyService: SpotifyService) => {
          const { token, deviceId } = args;
          return await spotifyService.pausePlayback(token, deviceId);
        },
      },
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 and does so well. It discloses behavioral traits like maintaining playback position, queue state, and requiring an active session and specific permissions, which are crucial for safe and effective use.

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 front-loaded with the core purpose, but includes extensive sections (USE CASES, WHAT IT RETURNS, etc.) that, while informative, could be more concise. Some sentences, like in 'PAUSE BENEFITS', repeat information without adding new value.

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 is fairly complete. It covers purpose, usage, returns, examples, benefits, and requirements, though it could benefit from more detail on error handling or output specifics.

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 the schema already documents both parameters. The description adds no additional meaning beyond the schema, such as explaining token scope details or deviceId behavior, but meets the baseline for high coverage.

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's purpose with a specific verb ('Pause') and resource ('current music playback'), and distinguishes it from siblings like 'resume_player' by specifying it maintains position and queue state. The title being null doesn't affect this clarity.

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?

The 'USE CASES' section provides clear contexts for when to use the tool, such as during calls or for smart home triggers. However, it lacks explicit guidance on when NOT to use it or direct alternatives among siblings, though 'resume_player' is implied as a counterpart.

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