What can you do with this server?

This server connects a chat client to the Bide & Musique catalogue of forgotten French songs, letting you search, read, browse, and discover records. * Search the collection along one axis at a time: performer, title, writer, lyrics, label, or year. * Read a full song record: title, artist, year, writers, duration, labels, catalogue reference, sleeve credits, chart placings, lyrics, and more. * Look up an artist’s page and their discography. * Draw a random record for browsing. * List the most recently catalogued records. * Use returned song IDs and URLs to go from a search result to a full record or artist page. * No API key or account is needed.

How do I use mcp-bideetmusique?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-bideetmusique search for songs by Françoise Hardy" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

mcp-bideetmusique

by smeet666

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

mcp-bideetmusique

npm license MCP Registry Glama M8ven LobeHub Install in Cursor Install in VS Code

Bide & Musique is a French web radio and the collection of records it plays, catalogued by hand by the volunteer association that runs it. Its subject is the forgotten song: the flop, the novelty record, the television theme, the single nobody reissued. A record's page carries the performer, the writers and composers, the year, the label and its catalogue reference, the sleeve, the duration, the station's own chart placings, and the words when a listener transcribed them.

This server connects a chat client to that collection. You can search it along one axis at a time, by performer, title, writer, lyrics, label or year; read one record in full; read what the site holds about an artist with their discography; draw a record at random; and see what has just been catalogued. It needs no API key and no account.

Version française

Install

One-click install

Install in Cursor Install in VS Code

Claude Code

claude mcp add bideetmusique -- npx -y mcp-bideetmusique

Claude Desktop, Cursor, and any client using the standard config format

{
  "mcpServers": {
    "bideetmusique": {
      "command": "npx",
      "args": ["-y", "mcp-bideetmusique"]
    }
  }
}

Node 24 or later is required, and no environment variable has to be set.

With Docker

{
  "mcpServers": {
    "bideetmusique": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "ghcr.io/smeet666/mcp-bideetmusique:2.0.1"]
    }
  }
}

-i keeps stdin open, which is where the protocol travels, and -t is left out because a TTY rewrites the stream. The container needs outbound HTTPS to www.bide-et-musique.com, and nothing else: no volume, no port, no credential.

Bundle, without npm

Download mcp-bideetmusique-2.0.1.mcpb from the latest release and open it. A client that supports MCP bundles installs it on its own, with no npm and no configuration file to edit. The bundle carries its dependencies, so nothing is fetched at install time.

Related MCP server: mcp-gouv-fr

What you can ask

« Qu'est-ce que Bide & Musique a de Jacques Dutronc ? »
"Which songs mention a submarine in their words?"
"Read me that record: the label, the year, who wrote it."
"Play me something at random from the collection."
"What has been catalogued lately?"

The ordinary path runs from a search to a record: a row carries a song_id, and get_song reads it.

Tools

Tool	What it does
`search_songs`	Searches the collection along one axis at a time.
`get_song`	Reads one record in full, words included.
`get_artist`	Reads an artist and the records the collection holds of theirs.
`get_random_song`	Draws a record nobody chose.
`list_new_songs`	Reads what the collection has just catalogued.

`search_songs`

Searches along one axis, which has to be named: each asks a different question, and an answer on one says nothing about the others. A name that returns nothing as a performer may still be a title.

Argument	Type	Required	What it does
`query`	string, up to 200 characters	yes	What to look for on that axis.
`search_type`	`performer`, `title`, `writer`, `lyrics`, `label` or `year`	yes	The axis to search along.
`page`	integer, 1 to 200, default `1`	no	Which page of rows.
`limit`	integer, 1 to 50, default `20`	no	Rows to serve.

`search_type`	Finds
`performer`	the artist credited on the record
`title`	the name of the song
`writer`	who wrote or composed it
`lyrics`	the words sung in it
`label`	the label it came out on
`year`	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. Several keywords are combined with AND and each is matched inside words, so every extra word narrows the search, and a quoted phrase returns nothing whatever the site's own form offers.

In return: rows carrying song_id, which get_song takes; title; url; and the artist. total_matches is the number the site prints, counting matching songs across every page, so it exceeds the rows of one page. page_served is the page the site actually served, since it answers a page past the last one with the last page and no error: read it rather than assuming the page asked for. page_count and has_more_pages are null where the site printed neither.

`get_song`

Reads one record in full.

Argument	Type	Required	What it does
`song_id`	string, up to 20 characters	yes	The id a search row carries.
`include_lyrics`	boolean, default `true`	no	Carry the transcribed words when the page has them.

In return: title, artist, credited_performer, year, writers, duration with the text exactly as the record prints it and its precision, labels with one entry per label, catalogue_reference, presentation, sleeve_credits, image_url, added_on as an ISO date, the station's chart placings, favourites and comments. The title, the artist and the duration are always stated; the rest is absent on some records and comes back null rather than guessed, and a counter the page prints nothing for is unknown rather than zero. lyrics.available says whether the page carries a transcription, and lyrics.text holds the words with the transcriber who wrote them down.

`get_artist`

Reads what the collection holds about one artist, with the records it has of theirs.

Argument	Type	Required	What it does
`artist_id`	string, up to 20 characters	yes	The artist id a record carries.
`limit`	integer, 1 to 200, default `100`	no	Records of theirs to serve.

In return: name, aliases, surname, first_name, nationality, birth_date, presentation, see_also, links and photo_url, each null or empty where the page states nothing. discography carries their records, each with its song_id for get_song, its title, url, year and how often the station programmed it. discography_count counts the records served and songs_on_page the records the page held, so a truncated discography is visible.

`get_random_song`

Draws a record nobody chose, over the ids the site serves. It is for browsing the collection when no particular song is being asked about.

Argument	Type	Required	What it does
`include_lyrics`	boolean, default `true`	no	Carry the transcribed words when the page has them.

In return: the record get_song returns.

`list_new_songs`

Reads what the collection has just catalogued.

Argument	Type	Required	What it does
`limit`	integer, 1 to 50, default `20`	no	Rows to serve.

In return: rows carrying song_id, title read off the line the feed publishes, artist_name, listed_as, url and published_at. entries_in_feed is the number of entries the feed holds, which is a fixed number and says nothing about how many records the collection holds.

Configuration

Every variable is optional. Set them in the env block of your client config.

Variable	Default	What it does
`BIDE_USER_AGENT`	the project identity	Names your application to the site, with an address where a person can be reached.
`BIDE_MIN_INTERVAL_MS`	`3000`	Gap between two requests, from 2000 to 60000.
`BIDE_TIMEOUT_MS`	`20000`	Deadline for one request, from 1000 to 120000.
`BIDE_MAX_RETRIES`	`3`	Attempts after a transient failure, from 0 to 10.
`BIDE_CACHE_TTL_MS`	`900000`	How long a page stays in memory, from 0 to 86400000.
`BIDE_CACHE_MAX_ENTRIES`	`200`	Pages held in memory at once, from 0 to 10000.
`BIDE_LOG_LEVEL`	`error`	`silent`, `error`, `info` or `debug`, written to stderr.

A value outside its range falls back to the default, and the reason is written to stderr.

Errors

Every failure carries one of six codes, a message, and where it helps a hint naming the next move.

Code	What happened	What to do
`not_found`	The site answered, and holds no such record.	Check the id with `search_songs`.
`invalid_input`	The arguments were refused before any request went out.	Read the message, which names the argument.
`rate_limited`	The site asked this client to slow down.	Wait the number of seconds the hint names and call again with the same arguments. The record is still there.
`parse_failure`	The page loaded and the expected content was absent.	Report it at the issue tracker.
`network_error`	The request did not complete.	Try again shortly.
`timeout`	The request passed its deadline.	Raise `BIDE_TIMEOUT_MS`, or ask for fewer rows.

As a library

The layer reading the site is published on its own, with its pacing, its cache and its errors, and with no protocol attached.

import { BideEtMusiqueClient } from "mcp-bideetmusique/client";

const client = new BideEtMusiqueClient();
const { data, cached } = await client.getSong("1234");
console.log(data.title, data.labels, cached);

search, getSong, getArtist and getNewSongs each answer { data, cached }, and throw an error carrying one of the six codes. The two-second floor between two requests holds here as well.

Pacing and attribution

Requests go out one at a time with at least three seconds between them, and the floor of two seconds holds however the server is configured. Bide & Musique is run by a volunteer association on its own means, and this pacing is what the collection is owed. The User-Agent always ends with the project identity and an address where a person can be reached.

Every result carries the address of the record's page. The catalogue is the work of the association and of the listeners who built it, transcriptions included.

This MCP server is an unofficial project, with no affiliation to Bide & Musique.

Privacy

This server collects nothing about you and sends nothing to its author. It runs on your machine, contacts www.bide-et-musique.com and nothing else, holds its answers in memory while it runs, and writes nothing to disk. PRIVACY.md states what a request carries and which settings change any of it.

Development

npm install
npm run build:fixtures
npm test
npm run check

Tests run against generated fixtures and make no network request. The live suite, npm run test:live, makes one request per route and runs nightly against the site itself.

Contributing

Bugs, questions and ideas belong in the issue tracker. Pull requests are welcome; opening an issue first helps agree on the shape of the change. See CONTRIBUTING.md.

License

MIT, see LICENSE. The catalogue belongs to Bide & Musique and to the listeners who built it.

mcp-bideetmusique (français)

English version

Bide & Musique est une radio web française et la collection de disques qu'elle diffuse, cataloguée à la main par l'association bénévole qui la tient. Son sujet est la chanson oubliée : le bide, le disque de fantaisie, le générique de télévision, le 45 tours que personne n'a réédité. La page d'un disque porte l'interprète, les auteurs et compositeurs, l'année, le label et sa référence de catalogue, la pochette, la durée, les classements du hit-parade de la station, et les paroles quand un auditeur les a transcrites.

Ce serveur relie un client de conversation à cette collection. On peut y chercher selon un axe à la fois, par interprète, titre, auteur, paroles, label ou année ; lire une fiche en entier ; lire ce que le site contient sur un artiste avec sa discographie ; tirer un disque au hasard ; et voir ce qui vient d'être catalogué. Aucune clé d'API, aucun compte.

Installation

Installation en un clic

Install in Cursor Install in VS Code

Claude Code

claude mcp add bideetmusique -- npx -y mcp-bideetmusique

Claude Desktop, Cursor, et tout client au format de configuration standard

{
  "mcpServers": {
    "bideetmusique": {
      "command": "npx",
      "args": ["-y", "mcp-bideetmusique"]
    }
  }
}

Node 24 ou plus récent est nécessaire, et aucune variable d'environnement n'est à renseigner.

Avec Docker

{
  "mcpServers": {
    "bideetmusique": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "ghcr.io/smeet666/mcp-bideetmusique:2.0.1"]
    }
  }
}

-i garde l'entrée standard ouverte, qui est le canal du protocole, et -t est omis parce qu'un TTY réécrit le flux. Le conteneur a besoin d'un accès HTTPS sortant vers www.bide-et-musique.com, et de rien d'autre : aucun volume, aucun port, aucun identifiant.

Bundle, sans npm

Téléchargez mcp-bideetmusique-2.0.1.mcpb depuis la dernière publication et ouvrez-le. Un client qui gère les bundles MCP l'installe seul, sans npm et sans fichier de configuration à modifier. Le bundle emporte ses dépendances, donc rien n'est téléchargé à l'installation.

Ce qu'on peut demander

« Qu'est-ce que Bide & Musique a de Jacques Dutronc ? »
« Quelles chansons parlent d'un sous-marin dans leurs paroles ? »
« Lis-moi cette fiche : le label, l'année, qui l'a écrite. »
« Fais-moi écouter quelque chose au hasard dans la collection. »
« Qu'est-ce qui a été catalogué récemment ? »

Le chemin ordinaire va d'une recherche à une fiche : une ligne porte un song_id, et get_song la lit.

Les outils

Outil	Ce qu'il fait
`search_songs`	Cherche dans la collection selon un axe à la fois.
`get_song`	Lit une fiche en entier, paroles comprises.
`get_artist`	Lit un artiste et les disques que la collection a de lui.
`get_random_song`	Tire un disque que personne n'a choisi.
`list_new_songs`	Lit ce que la collection vient de cataloguer.

`search_songs`

Cherche selon un axe, qu'il faut nommer : chacun pose une question différente, et une réponse sur l'un ne dit rien des autres. Un nom qui ne rend rien comme interprète peut très bien être un titre.

Argument	Type	Requis	Ce qu'il fait
`query`	chaîne, jusqu'à 200 caractères	oui	Ce qu'on cherche sur cet axe.
`search_type`	`performer`, `title`, `writer`, `lyrics`, `label` ou `year`	oui	L'axe de recherche.
`page`	entier, 1 à 200, défaut `1`	non	Quelle page de lignes.
`limit`	entier, 1 à 50, défaut `20`	non	Lignes à servir.

`search_type`	Trouve
`performer`	l'artiste crédité sur le disque
`title`	le nom de la chanson
`writer`	qui l'a écrite ou composée
`lyrics`	les mots qui y sont chantés
`label`	le label qui l'a publiée
`year`	l'année imprimée dessus

L'axe year prend une année à quatre chiffres et rien d'autre : le site laisse tomber tout autre mot au lieu de filtrer dessus. Plusieurs mots-clés sont combinés par ET et chacun est cherché à l'intérieur des mots, donc chaque mot supplémentaire resserre la recherche, et une expression entre guillemets ne rend rien, quoi qu'en propose le formulaire du site.

En retour : des lignes portant song_id, que get_song reprend ; title ; url ; et l'artist. total_matches est le nombre que le site imprime, comptant les chansons correspondantes sur toutes les pages, donc il dépasse les lignes d'une page. page_served est la page que le site a réellement servie, puisqu'il répond à une page au-delà de la dernière par la dernière page et sans erreur : lisez-la plutôt que de supposer la page demandée. page_count et has_more_pages valent null là où le site n'a imprimé ni l'un ni l'autre.

`get_song`

Lit une fiche en entier.

Argument	Type	Requis	Ce qu'il fait
`song_id`	chaîne, jusqu'à 20 caractères	oui	L'identifiant que porte une ligne.
`include_lyrics`	booléen, défaut `true`	non	Porter les paroles transcrites quand la page en a.

En retour : title, artist, credited_performer, year, writers, duration avec le texte exactement comme la fiche l'imprime et sa precision, labels avec une entrée par label, catalogue_reference, presentation, sleeve_credits, image_url, added_on en date ISO, les classements du hit-parade de la station, favourites et comments. Le titre, l'artiste et la durée sont toujours indiqués ; le reste est absent sur certaines fiches et revient null plutôt que deviné, et un compteur que la page n'imprime pas est inconnu plutôt que nul. lyrics.available dit si la page porte une transcription, et lyrics.text contient les mots avec le transcriber qui les a notés.

`get_artist`

Lit ce que la collection contient sur un artiste, avec les disques qu'elle a de lui.

Argument	Type	Requis	Ce qu'il fait
`artist_id`	chaîne, jusqu'à 20 caractères	oui	L'identifiant d'artiste que porte une fiche.
`limit`	entier, 1 à 200, défaut `100`	non	Disques de lui à servir.

En retour : name, aliases, surname, first_name, nationality, birth_date, presentation, see_also, links et photo_url, chacun null ou vide là où la page n'indique rien. discography porte ses disques, chacun avec son song_id pour get_song, son title, url, year et le nombre de fois où la station l'a programmé. discography_count compte les disques servis et songs_on_page ceux que la page contenait, si bien qu'une discographie tronquée se voit.

`get_random_song`

Tire un disque que personne n'a choisi, parmi les identifiants que le site sert. Il sert à parcourir la collection quand aucune chanson précise n'est en question.

Argument	Type	Requis	Ce qu'il fait
`include_lyrics`	booléen, défaut `true`	non	Porter les paroles transcrites quand la page en a.

En retour : la fiche que rend get_song.

`list_new_songs`

Lit ce que la collection vient de cataloguer.

Argument	Type	Requis	Ce qu'il fait
`limit`	entier, 1 à 50, défaut `20`	non	Lignes à servir.

En retour : des lignes portant song_id, title lu sur la ligne que le flux publie, artist_name, listed_as, url et published_at. entries_in_feed est le nombre d'entrées que le flux contient, qui est un nombre fixe et ne dit rien du nombre de disques que la collection contient.

Configuration

Chaque variable est facultative. Elles se posent dans le bloc env de la configuration du client.

Variable	Défaut	Ce qu'elle fait
`BIDE_USER_AGENT`	l'identité du projet	Nomme votre application auprès du site, avec une adresse où joindre une personne.
`BIDE_MIN_INTERVAL_MS`	`3000`	Écart entre deux requêtes, de 2000 à 60000.
`BIDE_TIMEOUT_MS`	`20000`	Délai d'une requête, de 1000 à 120000.
`BIDE_MAX_RETRIES`	`3`	Tentatives après un échec passager, de 0 à 10.
`BIDE_CACHE_TTL_MS`	`900000`	Durée pendant laquelle une page reste en mémoire, de 0 à 86400000.
`BIDE_CACHE_MAX_ENTRIES`	`200`	Pages gardées en mémoire à la fois, de 0 à 10000.
`BIDE_LOG_LEVEL`	`error`	`silent`, `error`, `info` ou `debug`, écrit sur la sortie d'erreur.

Une valeur hors de sa plage retombe sur le défaut, et la raison est écrite sur la sortie d'erreur.

Erreurs

Chaque échec porte un des six codes, un message, et quand cela aide une indication du geste suivant.

Code	Ce qui s'est passé	Que faire
`not_found`	Le site a répondu, et n'a pas cette fiche.	Vérifiez l'identifiant avec `search_songs`.
`invalid_input`	Les arguments ont été refusés avant toute requête.	Lisez le message, qui nomme l'argument.
`rate_limited`	Le site demande à ce client de ralentir.	Attendez les secondes indiquées et rappelez avec les mêmes arguments. La fiche est toujours là.
`parse_failure`	La page a chargé et le contenu attendu est absent.	Signalez-le sur le suivi d'incidents.
`network_error`	La requête n'a pas abouti.	Réessayez sous peu.
`timeout`	La requête a dépassé son délai.	Augmentez `BIDE_TIMEOUT_MS`, ou demandez moins de lignes.

Comme bibliothèque

La couche qui lit le site est publiée seule, avec son rythme, son cache et ses erreurs, sans protocole attaché.

import { BideEtMusiqueClient } from "mcp-bideetmusique/client";

const client = new BideEtMusiqueClient();
const { data, cached } = await client.getSong("1234");
console.log(data.title, data.labels, cached);

search, getSong, getArtist et getNewSongs répondent chacun { data, cached }, et lèvent une erreur portant un des six codes. Le plancher de deux secondes entre deux requêtes tient également ici.

Rythme et attribution

Les requêtes partent une à une avec au moins trois secondes entre elles, et le plancher de deux secondes tient quelle que soit la configuration. Bide & Musique est tenu par une association bénévole sur ses propres moyens, et ce rythme est ce qu'on doit à la collection. Le User-Agent se termine toujours par l'identité du projet et une adresse où joindre une personne.

Chaque résultat porte l'adresse de la page de la fiche. Le catalogue est l'œuvre de l'association et des auditeurs qui l'ont bâti, transcriptions comprises.

Ce MCP est un projet non officiel, sans affiliation à Bide & Musique.

Confidentialité

Ce serveur ne collecte rien sur vous et n'envoie rien à son auteur. Il tourne sur votre machine, ne joint que www.bide-et-musique.com, garde ses réponses en mémoire le temps qu'il tourne, et n'écrit rien sur le disque. PRIVACY.md dit ce qu'une requête emporte et quels réglages changent cela.

Développement

npm install
npm run build:fixtures
npm test
npm run check

Les tests s'exécutent sur des fixtures engendrées et n'émettent aucune requête. La suite en direct, npm run test:live, émet une requête par route et tourne chaque nuit contre le site lui-même.

Contribuer

Les anomalies, les questions et les idées ont leur place dans le suivi d'incidents. Les propositions de modification sont bienvenues ; ouvrir un ticket d'abord aide à s'accorder sur la forme du changement. Voir CONTRIBUTING.md.

Licence

MIT, voir LICENSE. Le catalogue appartient à Bide & Musique et aux auditeurs qui l'ont bâti.

Available Tools

5 tools

get_artistRead an artist's pageA

Read-onlyIdempotent

Read an artist's page on Bide & Musique: the names they recorded under, what the catalogue notes about them, and every song of theirs the collection holds, each with its year. Takes the 'artist_id' that search_songs, get_song and get_random_song return. An artist page is a way into a discography rather than a biography: half of them state nothing beyond the name, and the median artist has one record here. Fields the page does not state come back null or empty, which is the ordinary state of this catalogue rather than a failed read. The date of birth comes back exactly as written, since the catalogue states a full date, a bare year, or a date with a death beside it. Nationality is free text for the same reason. Rows come in the site's order, by year of release, never by importance. When you show an artist to a user, credit Bide & Musique and link the page.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum songs of the discography to return.
`artist_id`	Yes	The artist id returned by search_songs, get_song or get_random_song, digits only, for example '290'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`name`	Yes
`links`	Yes	Addresses off the site, with the label the page gave them.
`notes`	Yes
`source`	Yes
`aliases`	Yes	Other names this artist recorded under, as the page stacks them.
`surname`	Yes
`see_also`	Yes
`artist_id`	Yes
`photo_url`	Yes
`birth_date`	Yes	Exactly as published, which may be a day, a bare year, a month and a year, or a date with a death beside it. Nothing here is parsed into a date.
`first_name`	Yes
`discography`	Yes
`nationality`	Yes	As the catalogue writes it, in its own words: 'suisse', 'franco-espagnole'.
`presentation`	Yes
`songs_on_page`	Yes	Songs the page held, before 'limit'.
`discography_count`	Yes	Songs returned, after 'limit'.

TDQS

A4.6/5.0

Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: it explains null/empty fields as normal, the exact formatting of date of birth and nationality, the ordering of rows by year, and the requirement to credit Bide & Musique. This fully discloses the tool's behavior and aligns with the readOnlyHint and idempotentHint annotations.

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 longer than minimal but every sentence contributes meaningful information: purpose, input source, null behavior, date format, ordering, and citation. It is front-loaded with the purpose and weaves in necessary context without redundancy.

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 output schema exists, the description does not need to enumerate return fields. It covers all critical behavioral aspects—null handling, field formats, ordering, and attribution—making it complete for the tool's complexity. The explanation of the sparse catalogue helps the agent interpret results appropriately.

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% and both parameters have descriptions. The description adds value by explaining that artist_id is the identifier returned by other search tools, which is not in the schema. However, it does not clarify the limit parameter's behavior relative to the 'every song' claim, so it doesn't fully resolve potential ambiguity.

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 reads an artist's page and enumerates its contents (names recorded under, catalogue notes, and songs with years). It distinguishes itself from siblings like search_songs and get_song by targeting the artist resource specifically.

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?

It explicitly tells the agent that artist_id comes from search_songs, get_song, and get_random_song, providing the necessary context for when to use this tool. It also sets expectations about the sparse nature of artist pages, but does not explicitly state when not to use it or name alternatives for similar queries.

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

get_random_songRead a record drawn at randomA

Read-only

Read one record drawn at random from the Bide & Musique collection: same answer as get_song, on a record nobody chose. Use it to browse the collection. For a question about a particular song, use get_song. The draw runs over the ids the site serves, from the first to the newest one its feed of new entries names, and an id the collection does not serve is drawn again. Records whose page carries a transcription come back with the words themselves, as published. When you show a record to a user, credit Bide & Musique and link the page.

ParametersJSON Schema

Name	Required	Description	Default
`include_lyrics`	No	Whether to return the transcription the drawn record's page carries. Browsing chains many calls, and a record with one runs to a few thousand characters.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`year`	Yes
`notes`	Yes
`title`	Yes
`top50`	Yes
`artist`	Yes
`labels`	Yes	One entry per label, two when a record was co-released.
`lyrics`	Yes
`source`	Yes
`song_id`	Yes
`writers`	Yes	Writers and composers as credited, one entry each, empty when the record credits none. A few records name the part someone took, and the entry then reads as the site prints it, for example 'Paroles : Jean-Pierre Lang'.
`added_on`	Yes	The day the collection catalogued it, as an ISO date.
`comments`	Yes
`duration`	Yes
`see_also`	Yes	Other artists the record links to.
`image_url`	Yes
`favourites`	Yes	How many people keep it as a favourite. Null when the page prints no counter.
`presentation`	Yes	What the catalogue wrote about the record.
`thumbnail_url`	Yes
`sleeve_credits`	Yes	Who is credited for the sleeve, when anyone is.
`credited_performer`	Yes	A performer the sleeve credits apart from the artist page, when the record names one.
`catalogue_reference`	Yes	The reference printed on the record. A reference of four digits is not a year.

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true and destructiveHint=false, and the description adds valuable behavior: the draw covers served ids, invalid ids are redrawn, and results include transcriptions if present. It also adds attribution requirements for showing to users, which is beyond the annotations. No contradiction.

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 efficient, front-loading the core purpose, then usage, then behavior, and ends with attribution. Every sentence adds value; the only slight inefficiency is the last sentence about crediting, which could be shorter, but it's necessary context. No wasted words.

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?

The tool is simple (one param, read-only, no output schema needed as it's described as same as get_song), and the description covers purpose, usage, behavior, parameter purpose, and attribution. Complete for its complexity. The output schema likely mirrors get_song, so no need to detail returns.

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?

The schema covers the single parameter with full description, so the bar for added value is modest. The description adds why the parameter exists (to avoid heavy calls in browsing chains) and what it controls (whether to include transcription), though it doesn't add syntax details. Given full schema coverage, a 4 is justified for the contextual usage guidance.

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 it reads a random record from the Bide & Musique collection, same answer as get_song. It distinguishes itself from siblings by explicitly contrasting with get_song for particular song queries, and from search_songs and list_new_songs by its random selection.

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 explicitly says when to use: to browse the collection, and when not to: for a question about a particular song, use get_song. This direct alternative guidance is among the best evidence for this dimension.

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

get_songRead a song's recordA

Read-onlyIdempotent

Read one song's record on Bide & Musique: the year, the writers and composers, the duration, the label and its catalogue reference, the sleeve, when the collection catalogued it, how it ranked in the station's own chart, and how many people kept it as a favourite. Takes the 'song_id' that search_songs returns. Three things are always there: the title, the artist and the duration. Everything else is absent on some records, and comes back null or empty rather than guessed; a counter the record does not print is unknown, not zero. Records whose page carries a transcription come back with the words themselves, as published, along with who typed them. A record whose page carries none says so. When you show a record to a user, credit Bide & Musique and link the page.

ParametersJSON Schema

Name	Required	Description	Default
`song_id`	Yes	The song id returned by search_songs, digits only, for example '1734'.
`include_lyrics`	No	Whether to return the transcription the page carries. A record whose page has one runs to a few thousand characters, so ask for false when the question is about the record: the year, the label or the writers. 'lyrics.available' still says whether the page has one.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`year`	Yes
`notes`	Yes
`title`	Yes
`top50`	Yes
`artist`	Yes
`labels`	Yes	One entry per label, two when a record was co-released.
`lyrics`	Yes
`source`	Yes
`song_id`	Yes
`writers`	Yes	Writers and composers as credited, one entry each, empty when the record credits none. A few records name the part someone took, and the entry then reads as the site prints it, for example 'Paroles : Jean-Pierre Lang'.
`added_on`	Yes	The day the collection catalogued it, as an ISO date.
`comments`	Yes
`duration`	Yes
`see_also`	Yes	Other artists the record links to.
`image_url`	Yes
`favourites`	Yes	How many people keep it as a favourite. Null when the page prints no counter.
`presentation`	Yes	What the catalogue wrote about the record.
`thumbnail_url`	Yes
`sleeve_credits`	Yes	Who is credited for the sleeve, when anyone is.
`credited_performer`	Yes	A performer the sleeve credits apart from the artist page, when the record names one.
`catalogue_reference`	Yes	The reference printed on the record. A reference of four digits is not a year.

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint), the description reveals key behaviors: missing fields return null or empty rather than guessed, a counter not printed is unknown (not zero), lyrics inclusion can be controlled via a parameter, and the credit requirement. No contradictions with annotations—all align. This is exemplary transparency.

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 well-structured with a clear front-loaded purpose, followed by parameter guidance, behavioral details, and a final usage note. It contains several sentences, but each adds value—no redundancy. It could be slightly tightened (e.g., the credit sentence is somewhat tangential), but overall it efficiently conveys necessary information for an AI agent.

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 tool's complexity (multiple fields, null handling, lyrics behavior) and the presence of an output schema for return structure, the description covers all essential aspects: input source, parameter behavior, data completeness semantics, lyrics control, and attribution requirements. Nothing important is missing, making it fully complete for an AI agent to use correctly.

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 significant value beyond the schema: it explains the source of song_id (from search_songs), the rationale for setting include_lyrics false (to avoid large transcripts when metadata is needed), and mentions an output field ('lyrics.available') that informs decision-making. This goes well beyond the baseline of 3.

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 explicitly states the tool reads one song's record and lists specific fields (year, writers, composers, duration, etc.), with a clear verb ('Read') and resource ('song's record'). It distinguishes from siblings by specifying it takes a 'song_id' from search_songs, implying a targeted lookup. A definitive 5 for clarity and specificity.

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 provides clear guidance on when to use the tool (to read a specific song's record) and offers parameter-level advice (set include_lyrics to false when the question is about metadata like year or label). It connects to search_songs as the source of the song_id. However, it does not explicitly contrast with siblings like get_random_song or list_new_songs, which would earn a 5. A strong 4.

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

list_new_songsRead what was just cataloguedA

Read-onlyIdempotent

Read the records Bide & Musique has just catalogued. The collection is built by hand and grows a few records at a time, so this answers what has been added lately rather than what the station is playing. The feed carries a fixed number of entries and offers no second page, so the count is what it holds and says nothing about how many records the collection has. Entries come in the order the feed publishes them, which runs newest first without being sorted: read 'published_at' rather than the position to date one. Each entry names the song and the artist as one line, which is read apart at the first separator and kept whole under 'listed_as'. Use get_song on the id for the record itself: year, writers, label, duration and the words when the page carries them. When you show a record to a user, credit Bide & Musique and link the page.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum entries to return, taken from the head of the feed.

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	Yes
`source`	Yes
`results`	Yes
`result_count`	Yes
`entries_in_feed`	Yes	How many entries the feed carries, read or not. It is a fixed window on the newest records, never a count of the collection.

TDQS

A4.8/5.0

Behavior5/5

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

The description goes well beyond annotations by explaining behavior not covered: the fixed-size feed with no second page, lack of sorting (despite newest-first appearance), and how entries combine artist/song into one line. It also tells the agent to parse 'published_at' instead of position. All annotations (readOnlyHint, idempotentHint, openWorldHint) are consistent; no contradiction.

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 well-front-loaded with the core purpose, but the middle paragraph includes multiple nuanced behavioral notes (one-entry-per-line parsing, order caveats) that could be restructured for faster scanning. Still, every sentence adds value with no waste.

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 simplicity (1 optional param, no nested objects), the description fully covers return shape (id, listed_as, published_at), subtle ordering behavior, and how to use the result. The presence of an output schema reduces burden further. All agent decision points are addressed.

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% with one parameter (limit) already described. The description adds context that limit takes from the 'head of the feed,' confirming it pulls from the start (newest entries). This adds slight value beyond the schema's default/minimum/maximum descriptions.

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 returns recently catalogued records from Bide & Musique, contrasting with station playlists. It specifies that the feed has a fixed number of entries, no pagination, and entries are ordered by publication date (newest first). This uniquely distinguishes it from siblings like search_songs.

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?

Explicitly states when to use this tool: to see what has been added lately, not what is playing. Provides alternatives: use get_song on the id for full record details. Also warns that count does not reflect total collection size. 'credit Bide & Musique and link the page' gives a when-showing-to-user directive.

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

search_songsSearch songsA

Read-onlyIdempotent

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.

ParametersJSON 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

ParametersJSON 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

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context beyond annotations: the year axis drops extra words, quoting fails, search uses AND matching inside words, results include song id/artist/page/fields but not matched lyrics, count is total across pages, pagination with 'page' parameter. No contradictions with annotations.

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 long but every sentence serves a purpose—it covers the collection nature, axis behaviors, search logic, pagination, and attribution. It is front-loaded with the collection context. Minor structural improvement could be made (e.g., bullet-like separation of axis behaviors), but it remains clear and not verbose.

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 complexity (6 axes, special rules for year and quoting, pagination, output format), the description is remarkably complete. It explains what results contain (song id, artist, page, year, label, catalogue, writers), how to get more pages, and the fact that the count is total. The output schema is not provided in the prompt, but the description covers its key fields. No gaps are apparent.

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?

Schema coverage is 100%, so baseline is 3. However, the description adds deep semantic value: explains the meaning and appropriate uses of each search_type value, that query should be in French, how year axis behaves differently, and that quoting a phrase yields no results. This goes well beyond the schema's bare descriptions.

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 that the tool searches the Bide & Musique collection of French songs, with a specific focus on forgotten ones hand-catalogued since 2000. It distinguishes the tool from siblings like get_song (single retrieval) and get_random_song by focusing on search across multiple axes. The verb 'search' and resource 'collection' are explicit and unambiguous.

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?

Provides extensive guidance: explains that search_type is required, each axis answers a different question, year must be a single four-digit number, how to combine year with other terms, use lyrics to find songs from remembered lines, quoting returns nothing, AND logic for multiple keywords, pagination behavior, and the need to credit the source. Also warns about the count being across all pages, not just the current one. This covers when and how to use the tool effectively.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

2 tool updatesv1.0.0Aug 22, 2026

Changedget_artist1 field changed

changedInput schema / properties / artist_id / description

Previous value: -"The artist id returned by search_songs or get_song, digits only, for example '290'."New value: +"The artist id returned by search_songs, get_song or get_random_song, digits only, for example '290'."

Changedget_random_song1 field changed

addedInput schema / properties / include_lyrics

Added value: +{
+  "default": true,
+  "description": "Whether to return the transcription the drawn record's page carries. Browsing chains many calls, and a record with one runs to a few thousand characters.",
+  "type": "boolean"
+}

5 tool updatesv0.3.0Aug 18, 2026
- First observedget_artist
- First observedget_random_song
- First observedget_song
- First observedlist_new_songs
- First observedsearch_songs

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.8/5.0

Disambiguation5/5

Each tool serves a clearly distinct purpose: artist pages, song search across multiple axes, song details, random browsing, and newest additions. There is no overlap or ambiguity between them; an agent can easily select the right tool for the task.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern: get_artist, get_song, get_random_song, list_new_songs, search_songs. The prefix clearly indicates the action (get/search/list) and the noun indicates the resource, making the API predictable and easy to navigate.

Tool Count5/5

Five tools is an ideal size for this server's purpose—a focused read-only music archive. Each tool serves a distinct user need without redundancy or bloat, and the count is well within the optimal range for a domain-specific MCP server.

Completeness5/5

The tool surface fully covers the apparent domain: searching the catalog, retrieving artist and song details, browsing randomly, and checking new additions. There are no missing operations that would prevent an agent from accomplishing typical tasks like finding a song, learning about an artist, or exploring the collection.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

podcasts A
com.petabloom
An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
Entertainment & Media Search
52
mcp-sunoOAuth
io.github.AceDataCloud
MCP server for Suno AI music generation, lyrics, and covers
Audio Processing Multimedia Processing Entertainment & Media
249
hithereiamaliff-mcp-datagovmy BOAuth
ai.smithery
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
Government Data Open Data
23
RU Books MCP
io.github.books-service
MCP server for Russian books search, details, and recommendation candidates.
Search Art & Culture Entertainment & Media
2

Related MCP Servers

MusicBrainz MCP Server
Search Entertainment & Media Open Data
usercourses63
A
license
Not graded
quality
C
maintenance
A comprehensive MCP server for querying the MusicBrainz database, providing tools to search for artists, releases, recordings, and browse music metadata.
Updated a year ago (2025-09-15 08:44 UTC)
4
MIT
mcp-gouv-fr
Government Data Open Data
gghez
F
license
Not graded
quality
D
maintenance
MCP server for exploring French public open data via APIs like data.gouv.fr, geo.api.gouv.fr, INSEE Sirene, and Radio France.
Updated 5 months ago (2026-04-10 10:42 UTC)
-
mcp-lyricscom
Art & Culture Entertainment & Media Search
smeet666
A
license
A
quality
B
maintenance
MCP server for lyrics.com that enables searching songs by lyrics or title and retrieving full lyrics, with no API key required.
Updated 2 days ago (2026-09-06 12:28 UTC)
3
407
MIT
senscritique-bridge
Search Entertainment & Media Art & Culture
kabylesystem
A
license
Not graded
quality
A
maintenance
MCP server enabling search and retrieval of public SensCritique data, including works, user profiles, and collections.
Updated a month ago (2026-08-06 17:44 UTC)
3
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/smeet666/mcp-bideetmusique'

If you have feedback or need assistance with the MCP directory API, please join our Discord server