mcp-lyricscom

Search songs by title

search_songs

Read-onlyIdempotent

Find songs by title on lyrics.com, returning artist, album, year, ID, and URL. Filter by artist or use strict matching to distinguish covers, versions, and genuine title matches.

Instructions

Find songs on lyrics.com by their title. Returns candidate songs with artist, album, year, and the lyrics.com id and URL. Use this when someone names a song and you need its id to call get_lyrics, or to tell covers and versions by different artists apart. An optional 'artist' narrows the list. lyrics.com searches titles and lyrics together, so results are ranked and filtered locally by title match; use match="strict" to keep only genuine title matches.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>"
    },
    "name": "search_songs"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No
`limit`	No
`match`	No	'strict' keeps only results whose title matches the query as a whole title, ignoring suffixes such as '(Remastered)'. 'loose' keeps anything lyrics.com returned, best match first.	loose
`title`	Yes	Song title, or part of it.
`artist`	No	Optional artist name, matched case-insensitively against each result.

Output Schema

Name	Required	Description	Default
`page`	Yes
`notes`	Yes
`title`	Yes
`source`	Yes
`results`	Yes
`has_more`	Yes
`next_page`	Yes
`filtered_out`	Yes
`artist_filter`	Yes
`raw_result_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv2.1.0Oct 30, 2026
- removedOutput schema / properties / artist_filter / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / artist_filter / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / album / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / album / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / excerpt / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / excerpt / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Changed14 schema fields changedv2.0.0Aug 26, 2026

addedOutput schema / properties / artist_filter / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / artist_filter / type
```
Removed value: -[
-  "string",
-  "null"
-]
```
addedOutput schema / properties / filtered_out / maximum
```
Added value: +9007199254740991
```
addedOutput schema / properties / filtered_out / minimum
```
Added value: +-9007199254740991
```

changedOutput schema / properties / next_page / anyOf

Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maximum": 9007199254740991,
+    "minimum": -9007199254740991,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

addedOutput schema / properties / page / maximum
```
Added value: +9007199254740991
```
addedOutput schema / properties / page / minimum
```
Added value: +-9007199254740991
```
addedOutput schema / properties / raw_result_count / maximum
```
Added value: +9007199254740991
```
addedOutput schema / properties / raw_result_count / minimum
```
Added value: +-9007199254740991
```

addedOutput schema / properties / results / items / properties / album / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / results / items / properties / album / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

addedOutput schema / properties / results / items / properties / excerpt / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / results / items / properties / excerpt / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

changedOutput schema / properties / results / items / properties / year / anyOf

Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maximum": 9007199254740991,
+    "minimum": -9007199254740991,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

First observedv1.0.0Aug 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower, and the description still adds real behavioral context: lyrics.com searches titles and lyrics together, results are ranked and filtered locally by title, and match="strict" changes that filtering. It does not discuss pagination limits or result-set size, keeping it below 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.

Conciseness4/5

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

Four sentences, front-loaded with purpose and return shape before the usage and filtering details; every sentence carries information. It runs slightly long and packs multiple ideas into the final sentence, but nothing is filler.

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?

An output schema exists, and the description still summarizes the return fields; the mutation/read profile is handled by annotations; the one non-obvious parameter behavior is explained. An agent has everything needed to call it correctly.

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 60%, and the description compensates by explaining the effect of 'artist' (narrows the list) and 'match' (strict keeps only whole-title matches, ignoring suffixes like '(Remastered)') in terms of behavior rather than restating the enum. 'page' and 'limit' get no mention, which is the only gap.

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 and resource ('Find songs on lyrics.com by their title') and enumerates the returned fields (artist, album, year, id, URL). It is clearly distinguishable from get_lyrics (retrieval by id) and search_lyrics (lyric-text search).

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?

Gives an explicit trigger ('when someone names a song and you need its id to call get_lyrics') and a secondary use case (telling covers/versions apart by artist). It does not state when to prefer the sibling search_lyrics instead, which is the one remaining routing gap.

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

Deploy Server