mcp-bideetmusique

Search songs

search_songs

Read-onlyIdempotent

Search French songs in the Bide & Musique catalogue by performer, title, writer, lyrics, label, or four-digit year.

Instructions

Search the Bide & Musique collection: French songs, mostly forgotten ones, catalogued by hand since 2000 by the association that runs the station. Bide & Musique is a French site, so French terms work best. 'search_type' picks the axis and has to be stated: 'performer' for the artist credited on the record, 'title' for the name of the song, 'writer' for who wrote or composed it, 'lyrics' for the words sung in it, 'label' for the label it came out on, 'year' for the year printed on it. Each asks a different question and they are never merged, so a name that finds nothing as a performer may still be a title. 'year' takes one four-digit year and nothing else: the site drops any other word on that axis instead of filtering on it, and the ranges its own form documents return nothing. To combine a year with words, search the words on their own axis and read each record's year from its page. Use 'lyrics' to find a song from a line someone remembers. It answers with the songs whose words match, without showing what matched; read the words themselves with get_song on the id. Several keywords are combined with AND, each matched inside words, so every extra word narrows the search and never widens it. Quoting a phrase returns nothing, whatever the site's own form says. Results carry the song id, the artist and the page to read, which is where the song's own record lives: year, label, catalogue reference and writers. The count returned counts matching songs across every page, so it is usually larger than the rows of one page; ask for the next page with 'page'. When you show a song to a user, credit Bide & Musique and link the source URL.

Input Schema

Name	Required	Description
`page`	No	Which page of results to read. The answer states which page the site served.
`limit`	No	Maximum songs to return from that page.
`query`	Yes	What to search for, in French, for example 'Pierre Bachelet' or 'vacances'.
`search_type`	Yes	Which axis to search: 'performer' for the artist credited on the record, 'title' for the name of the song, 'writer' for who wrote or composed it, 'lyrics' for the words sung in it, 'label' for the label it came out on, 'year' for the year printed on it. The 'year' axis takes one four-digit year and nothing else: the site drops any other word there instead of filtering on it.

Output Schema

Name	Required	Description
`notes`	Yes
`query`	Yes
`source`	Yes
`results`	Yes
`page_count`	Yes
`page_served`	Yes	The page the site actually served, read from its pagination bar. Asking for a page past the last one returns the last page, so this can differ from 'page_requested'.
`search_type`	Yes
`result_count`	Yes	Songs returned, after 'limit'.
`rows_on_page`	Yes	Songs this page held, before 'limit'.
`total_matches`	Yes	The number Bide & Musique prints above the results, counting matching songs across every page. Null when the site printed none, which is different from zero.
`has_more_pages`	Yes
`page_requested`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv2.1.0Oct 30, 2026
- removedOutput schema / properties / has_more_pages / anyOf
```
Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / has_more_pages / type
```
Added value: +[
+  "boolean",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / artist / properties / alias_of / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / artist / properties / alias_of / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / image_url / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / image_url / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / programming / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / programming / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / thumbnail_url / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / thumbnail_url / type
```
Added value: +[
+  "string",
+  "null"
+]
```
First observedv0.3.0Aug 18, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations declaring a safe read-only idempotent operation, the description discloses important quirks: the year axis accepts only one four-digit year, ranges return nothing, quoted phrases return nothing, keywords are ANDed within words, and count spans all pages rather than one page.

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?

The description is front-loaded and most sentences carry operational value, but it repeats the search_type enum definitions at length even though the schema already describes them fully. Slightly tighter editing would improve it without losing the important caveats.

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?

For a search tool with an output schema and read-only annotations, the description covers the remaining gaps an agent needs: query semantics, paging, result count meaning, result fields, attribution, and where to read full song details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds critical semantics not captured by the schema: the axes are never merged, extra words narrow rather than widen, the year axis silently drops other words, and lyrics matches without showing the matched text.

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: searching the Bide & Musique song collection. It also clearly separates this from siblings by explaining that records are read with get_song on the returned id.

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?

It gives explicit when-to-use guidance for each axis, especially lyrics for finding a song from a remembered line, and explains why a failed performer search does not mean the name is absent. It also handles the year-combination limitation and points to get_song for record details.

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

Deploy Server