mcp-lrclib

Search tracks

search_tracks

Read-onlyIdempotent

Search LRCLIB tracks by title, artist, or album to get the ID required to fetch lyrics; returned metadata helps distinguish releases and check for synced lyrics.

Instructions

Search LRCLIB for tracks by title, artist or album, and get the id needed to fetch lyrics with get_lyrics. Give either 'query' as free text, or 'track_name' and 'artist_name' separately for a narrower search. Results carry metadata only: title, artist, album, duration, and whether plain and time-synced lyrics exist. Use 'duration_seconds' and 'album_name' in the results to tell releases and re-recordings of the same song apart, and 'has_synced_lyrics' to know whether karaoke-style timed lyrics are available before fetching them. LRCLIB indexes tracks by their metadata, so it cannot search for a word appearing inside the lyrics.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_tracks"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum tracks to return. LRCLIB returns up to 20 per search.
`query`	No	Free-text search, for example 'nino ferrer le sud'. Use this or the fields below.
`album_name`	No	Album name, to narrow a structured search.
`track_name`	No	Song title, for a structured search.
`artist_name`	No	Artist name, for a structured search.

Output Schema

Name	Required	Description
`notes`	Yes
`source`	Yes
`results`	Yes
`result_count`	Yes
`total_available`	Yes	Tracks LRCLIB returned before applying 'limit'.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv2.1.0Oct 30, 2026
- removedOutput schema / properties / results / items / properties / album_name / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / album_name / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / duration_seconds / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / duration_seconds / type
```
Added value: +[
+  "number",
+  "null"
+]
```
Changed10 schema fields changedv2.0.0Aug 26, 2026
- addedOutput schema / properties / result_count / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / result_count / minimum
```
Added value: +-9007199254740991
```
- addedOutput schema / properties / results / items / properties / album_name / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / results / items / properties / album_name / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
- addedOutput schema / properties / results / items / properties / duration_seconds / anyOf
```
Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / results / items / properties / duration_seconds / type
```
Removed value: -[
-  "number",
-  "null"
-]
```
- addedOutput schema / properties / results / items / properties / id / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / results / items / properties / id / minimum
```
Added value: +-9007199254740991
```
- addedOutput schema / properties / total_available / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / total_available / minimum
```
Added value: +-9007199254740991
```
First observedv1.0.0Aug 3, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, and the description adds substantive context beyond them: results are metadata only, the specific fields returned, the has_synced_lyrics pre-check, and the indexing limitation. It slightly overlaps the output schema by enumerating return fields, so not quite a 5.

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

Conciseness5/5

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

Four sentences, no filler; the core action and how to call it come first, followed by result interpretation and the key limitation. Every sentence carries distinct information.

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

Completeness5/5

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

With annotations covering safety, a full output schema, and 100% param coverage, the description fills the remaining gaps an agent needs: result shape, disambiguation strategy, and the lyric-text search limitation.

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 coverage is 100%, so baseline is 3, but the description goes further by explaining the either/or relationship between 'query' and the structured fields and what album_name/duration are useful for when interpreting results. It does not clarify limit semantics beyond what the schema states.

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?

States a specific verb (search) and resource (LRCLIB tracks) plus the downstream purpose — getting the id needed for get_lyrics — which cleanly separates it from the siblings get_lyrics and get_track.

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?

Gives explicit input modes ('query' free text vs 'track_name'+'artist_name' for narrower search), practical disambiguation advice (use duration_seconds and album_name to tell releases/re-recordings apart), and a stated limitation (cannot search words inside lyrics). That is when-to-use, how-to-choose, and when-not in one place.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server