Skip to main content
Glama
leehave

Claude Music MCP

by leehave

get_playlist

Retrieve detailed information about a specific music playlist using its unique ID. This tool enables users to access playlist contents, metadata, and structure for music management within the Claude Music MCP server.

Instructions

获取播放列表信息

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
playlistIdYes播放列表ID

Implementation Reference

  • The primary handler function for the 'get_playlist' tool that executes the core logic: fetches playlist data, retrieves associated songs, and formats a detailed response.
    private async handleGetPlaylist(args: any) {
      const { playlistId } = args;
      const playlist = await this.playlistManager.getPlaylist(playlistId);
      
      if (!playlist) {
        throw new Error(`未找到ID为 ${playlistId} 的播放列表`);
      }
    
      const songs = await Promise.all(
        playlist.songIds.map(id => this.musicDb.getSongById(id))
      );
    
      return {
        content: [
          {
            type: 'text',
            text: `🎵 播放列表: ${playlist.name}\n\n描述: ${playlist.description || '无'}\n歌曲数量: ${playlist.songIds.length}\n创建时间: ${playlist.createdAt}\n\n歌曲列表:\n${songs.map((song, index) => 
              `${index + 1}. ${song?.title} - ${song?.artist}`
            ).join('\n')}`,
          },
        ],
      };
    }
  • src/index.ts:115-128 (registration)
    Registration of the 'get_playlist' tool in the ListToolsRequestSchema handler, including name, description, and input schema definition.
    {
      name: 'get_playlist',
      description: '获取播放列表信息',
      inputSchema: {
        type: 'object',
        properties: {
          playlistId: {
            type: 'string',
            description: '播放列表ID',
          },
        },
        required: ['playlistId'],
      },
    },
  • TypeScript interface defining the Playlist data structure used throughout the get_playlist implementation.
    export interface Playlist {
      id: string;
      name: string;
      description?: string;
      songIds: string[];
      createdAt: string;
      updatedAt: string;
    }
  • Supporting method in PlaylistManager class that retrieves a specific playlist by ID, called by the main handler.
    async getPlaylist(id: string): Promise<Playlist | undefined> {
      return this.playlists.get(id);
    }
  • src/index.ts:177-178 (registration)
    Tool dispatching logic in the CallToolRequestSchema switch statement that routes 'get_playlist' calls to the handler.
    case 'get_playlist':
      return await this.handleGetPlaylist(args);
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('获取播放列表信息') without detailing traits such as whether it's read-only (implied but not explicit), requires authentication, has rate limits, returns structured data, or handles errors. For a tool with no annotation coverage, this is a significant gap in transparency.

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 a single, efficient sentence ('获取播放列表信息') that is front-loaded with the core action. It avoids unnecessary words, making it concise. However, it could be more structured by including key details (e.g., 'Retrieves metadata and tracks for a specific playlist by ID'), but as-is, it is not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is incomplete. It lacks information on return values (e.g., what 'playlist information' includes), error handling, or behavioral context. Without annotations or an output schema, the description should compensate by explaining these aspects, but it does not, leaving gaps for the 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?

The input schema has 100% description coverage, with the single parameter 'playlistId' documented as '播放列表ID' (playlist ID). The description does not add any meaning beyond this, such as format examples (e.g., alphanumeric string) or sourcing guidance (e.g., from 'list_playlists'). With high schema coverage, the baseline score of 3 is appropriate, as the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description '获取播放列表信息' (Get playlist information) states a clear verb ('获取' - get) and resource ('播放列表信息' - playlist information), establishing the basic purpose. However, it lacks specificity about what information is retrieved (e.g., metadata, tracks, owner details) and does not differentiate from sibling tools like 'list_playlists' (which likely lists multiple playlists) or 'get_song_info' (which focuses on songs). This makes the purpose somewhat vague but not misleading.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a playlist ID), exclusions (e.g., not for creating or modifying playlists), or comparisons to siblings like 'list_playlists' (for listing playlists without an ID) or 'get_song_info' (for song-specific data). This leaves the agent without context for tool selection.

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/leehave/Claude-Music-Mcp'

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