Skip to main content
Glama

search_tracks

Search for individual songs on Spotify using lyrics, artist names, or specific keywords to find tracks, discover versions, and build playlists.

Instructions

Search specifically for individual tracks with targeted filtering for precise song discovery.

🎯 USE CASES: • Find specific songs when you remember lyrics or melodies • Discover tracks by particular artists or from specific albums • Build track-focused music discovery experiences • Find alternative versions, covers, or remixes of songs • Research song catalogs and discographies

📝 WHAT IT RETURNS: • Ranked track results based on search relevance • Song titles, artists, albums, and release information • Track popularity scores and listener engagement • Preview URLs for instant track sampling • Market availability and explicit content flags

🔍 EXAMPLES: • "Search for tracks with 'love' in the title" • "Find acoustic versions of popular songs" • "Look for instrumental jazz piano tracks" • "Search for covers of 'Yesterday' by The Beatles"

🎵 SEARCH PRECISION: • Track-specific results without album/artist clutter • Optimized for individual song discovery • Better for finding specific recordings or versions • Perfect for playlist building and curation • Ideal for karaoke or cover song searches

💡 SEARCH STRATEGIES: • Include specific lyrics: "lyrics hello darkness my old friend" • Search by genre: "indie folk acoustic guitar" • Find versions: "acoustic", "remix", "live", "cover" • Use artist filters: "artist:Taylor Swift love songs" • Include year ranges: "track:dancing year:2020-2023"

⚠️ REQUIREMENTS: • Valid Spotify access token • Search terms should be specific for best results

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesSpotify access token for authentication
queryYesSearch query for tracks (song title, artist, album, keywords)
limitNo

Implementation Reference

  • Defines the 'search_tracks' MCP tool including title, description, input schema, and handler function that delegates to SpotifyService.searchTracks
      search_tracks: {
        title: "Search Tracks",
        description: `Search specifically for individual tracks with targeted filtering for precise song discovery.
    
    🎯 USE CASES:
    • Find specific songs when you remember lyrics or melodies
    • Discover tracks by particular artists or from specific albums
    • Build track-focused music discovery experiences
    • Find alternative versions, covers, or remixes of songs
    • Research song catalogs and discographies
    
    📝 WHAT IT RETURNS:
    • Ranked track results based on search relevance
    • Song titles, artists, albums, and release information
    • Track popularity scores and listener engagement
    • Preview URLs for instant track sampling
    • Market availability and explicit content flags
    
    🔍 EXAMPLES:
    • "Search for tracks with 'love' in the title"
    • "Find acoustic versions of popular songs"
    • "Look for instrumental jazz piano tracks"
    • "Search for covers of 'Yesterday' by The Beatles"
    
    🎵 SEARCH PRECISION:
    • Track-specific results without album/artist clutter
    • Optimized for individual song discovery
    • Better for finding specific recordings or versions
    • Perfect for playlist building and curation
    • Ideal for karaoke or cover song searches
    
    💡 SEARCH STRATEGIES:
    • Include specific lyrics: "lyrics hello darkness my old friend"
    • Search by genre: "indie folk acoustic guitar"
    • Find versions: "acoustic", "remix", "live", "cover"
    • Use artist filters: "artist:Taylor Swift love songs"
    • Include year ranges: "track:dancing year:2020-2023"
    
    ⚠️ REQUIREMENTS:
    • Valid Spotify access token
    • Search terms should be specific for best results`,
        schema: createSchema({
          token: commonSchemas.token(),
          query: commonSchemas.searchQuery(
            "tracks (song title, artist, album, keywords)"
          ),
          limit: commonSchemas.limit(1, 50, 20),
        }),
        handler: async (args: any, spotifyService: SpotifyService) => {
          const { token, query, limit = 20 } = args;
          return await spotifyService.searchTracks(token, query, limit);
        },
      },
  • Core implementation of track search using Spotify's search API endpoint, limited to tracks (type='track')
    async searchTracks(
      token: string,
      query: string,
      limit: number = 20
    ): Promise<SearchResult> {
      const params = {
        q: query,
        type: "track",
        limit: Math.min(limit, 50),
      };
      return await this.makeRequest<SearchResult>("search", token, params);
    }
  • Registers trackTools (including search_tracks) into the central allTools registry used by ToolRegistrar
    export const allTools: ToolsRegistry = {
      ...albumTools,
    
      ...artistTools,
    
      ...trackTools,
    
      ...playlistTools,
    
      ...playbackTools,
    
      ...userTools,
    
      ...searchTools,
    };
  • Zod-based input schema for search_tracks tool defining token, query, and limit parameters
    schema: createSchema({
      token: commonSchemas.token(),
      query: commonSchemas.searchQuery(
        "tracks (song title, artist, album, keywords)"
      ),
      limit: commonSchemas.limit(1, 50, 20),
    }),
  • Generic HTTP request helper used by searchTracks to make authenticated API calls to Spotify
    private async makeRequest<T = any>(
      endpoint: string,
      token: string,
      params: Record<string, any> = {},
      method: "GET" | "POST" | "PUT" | "DELETE" = "GET",
      data: any = null
    ): Promise<T> {
      try {
        const url = endpoint.startsWith("http")
          ? endpoint
          : `${this.baseURL}/${endpoint}`;
    
        const config = {
          method,
          url,
          headers: this.getAuthHeaders(token),
          params: method === "GET" ? params : undefined,
          data: method !== "GET" ? data : undefined,
        };
    
        const response: AxiosResponse<T> = await axios(config);
        return response.data;
      } catch (error: any) {
        if (error.response) {
          const errorMessage =
            error.response.data?.error?.message || error.response.statusText;
          throw new Error(
            `Spotify API Error: ${error.response.status} - ${errorMessage}`
          );
        } else if (error.request) {
          throw new Error("Unable to connect to Spotify API");
        } else {
          throw new Error(`Request error: ${error.message}`);
        }
      }
    }
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 returns (ranked track results with specific metadata), search precision characteristics, and requirements (Spotify access token). It doesn't mention rate limits, error conditions, or authentication details beyond the token requirement, but provides substantial behavioral context.

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, Examples, etc.), but it's quite lengthy with multiple emoji-labeled sections. While all content is relevant, it could be more concise. The front-loading is good with the purpose statement first, but the overall length reduces efficiency.

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 search tool with 3 parameters, no annotations, and no output schema, the description provides substantial context: clear purpose, usage guidelines, return value details, examples, search strategies, and requirements. It effectively compensates for the lack of structured metadata. The main gap is not explicitly describing the output format structure, though it lists what information is returned.

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 description coverage is 67% (2 of 3 parameters have descriptions). The description adds significant value beyond the schema: it explains what constitutes a good query ('Search terms should be specific for best results'), provides numerous examples of query strategies, and contextualizes the search purpose. However, it doesn't provide additional details about the 'limit' parameter beyond what's in the 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 clearly states the tool's purpose: 'Search specifically for individual tracks with targeted filtering for precise song discovery.' It uses specific verbs ('search', 'discover', 'find') and distinguishes this track-focused search from other search tools like search_albums, search_artists, and search_playlists among the siblings.

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 guidance on when to use this tool versus alternatives. The 'Search Precision' section explains this is 'track-specific results without album/artist clutter' and 'optimized for individual song discovery,' distinguishing it from broader search tools. The 'Use Cases' section gives concrete scenarios like finding specific songs, discovering tracks by artists, and building track-focused experiences.

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