mcp-lrclib

Search tracks

search_tracks

Read-onlyIdempotent

Find tracks in LRCLIB by title, artist, album, or free text to obtain the ID needed for fetching lyrics. Returned metadata reveals duration and synced-lyrics availability to distinguish versions.

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.

Input Schema

TableJSON 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

TableJSON 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.

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

Behavior5/5

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds meaningful behavioral context beyond that: results are metadata-only, tracks are indexed by metadata rather than lyric content, and has_synced_lyrics indicates whether timed lyrics exist before fetching. This is exactly the kind of non-obvious behavior an agent needs to know.

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?

The description is front-loaded with the core purpose, then parameter guidance, then result interpretation, then a key limitation. Each sentence earns its place and none are filler, making it informative without being bloated.

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?

Given the annotations, output schema, and sibling tools, the description is complete enough to select and invoke the tool correctly. It explains the two search modes, the metadata-only nature of results, how to disambiguate releases, how to check for synced lyrics, and the limitation around lyric-text search. The only minor gap is not addressing get_track directly, but the overall context is still strong.

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 the baseline is 3, but the description adds value by explaining the relationship between parameters: 'query' is free text, while 'track_name' and 'artist_name' provide a narrower structured search. It also explains how result fields like duration_seconds and album_name can be used for disambiguation, going slightly beyond 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 states a specific verb and resource: 'Search LRCLIB for tracks by title, artist or album', and clarifies that the purpose is to obtain 'the id needed to fetch lyrics with get_lyrics'. This clearly differentiates it from the sibling tools by positioning search as the discovery step before retrieval.

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 gives solid usage guidance: use 'query' for free text or 'track_name' and 'artist_name' for a narrower search, and it explicitly warns that LRCLIB cannot search lyric content. It names get_lyrics as the downstream consumer, though it does not explicitly contrast search_tracks with get_track or state when get_track would be preferred.

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

Deploy Server