Skip to main content
Glama

get_track

Retrieve detailed metadata and audio characteristics for specific Spotify tracks to support music research, application development, and content verification.

Instructions

Retrieve comprehensive information about any specific track including detailed metadata and audio characteristics.

🎯 USE CASES: • Research song details for music blogs or articles • Analyze track metadata for music applications • Get complete song information for sharing or playlisting • Verify track details and availability before use • Build detailed music catalogs and databases

📝 WHAT IT RETURNS: • Complete track information (title, artist, album, duration) • Release date, popularity scores, and market availability • Track artwork, preview URLs, and external links • Explicit content flags and parental guidance information • ISRC codes and other professional identifiers

🔍 EXAMPLES: • "Get details for 'Hotel California' by Eagles" • "Show me information about track ID: 40riOy7x9W7GXjyGp4pjAv" • "I need complete details for this specific song" • "Get metadata for the track I just discovered"

💡 DETAILED INSIGHTS: • Professional music industry identifiers • Cross-platform compatibility information • Regional availability and licensing details • Perfect for music research and analysis • Essential for building music applications

⚠️ REQUIREMENTS: • Valid Spotify access token • Track must exist and be available in user's market

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesSpotify access token for authentication
trackIdYesSpotify track ID or URI

Implementation Reference

  • MCP tool handler for 'get_track' which extracts arguments and delegates to SpotifyService.getTrack
    handler: async (args: any, spotifyService: SpotifyService) => {
      const { token, trackId } = args;
      return await spotifyService.getTrack(token, trackId);
    },
  • Input schema for get_track tool defining token and trackId parameters
    schema: createSchema({
      token: commonSchemas.token(),
      trackId: commonSchemas.spotifyId("track"),
    }),
  • Registration of all tools including trackTools (containing get_track) into the central allTools registry used by ToolRegistrar
    export const allTools: ToolsRegistry = {
      ...albumTools,
    
      ...artistTools,
    
      ...trackTools,
    
      ...playlistTools,
    
      ...playbackTools,
    
      ...userTools,
    
      ...searchTools,
    };
  • Core helper function SpotifyService.getTrack that fetches track details from Spotify API via makeRequest
    async getTrack(token: string, trackId: string): Promise<SpotifyTrack> {
      const id = this.extractId(trackId);
      return await this.makeRequest<SpotifyTrack>(`tracks/${id}`, token);
    }
  • Instantiates ToolRegistrar with SpotifyService, which registers all tools including get_track for the MCP server
    const spotifyService = new SpotifyService();
    const toolRegistrar = new ToolRegistrar(spotifyService);
Behavior3/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 adds useful context about authentication requirements (Spotify access token) and market availability constraints, but doesn't cover other behavioral aspects like rate limits, error handling, or response format details beyond listing return categories.

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, returns, examples, insights, requirements), but it's verbose with redundant information. Some sections like 'detailed insights' and 'examples' could be more concise, and the core purpose could be stated more directly upfront.

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 the tool's moderate complexity (2 parameters, no output schema, no annotations), the description provides substantial context about what the tool does, use cases, return information, and requirements. It's mostly complete but could benefit from more specific behavioral details like response structure or error scenarios.

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, clearly documenting both parameters (token and trackId). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.

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 specific verbs ('retrieve', 'get') and resources ('track', 'song'), distinguishing it from siblings like get_album, get_artist, or get_track_lyrics. It explicitly mentions retrieving comprehensive information about specific tracks, which differentiates it from search tools or playlist-related operations.

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 description provides clear context through use cases and requirements, indicating when to use it (e.g., for research, analysis, verification). However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, such as using get_album_tracks for album-level details instead.

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