de en es ja ko ru zh

mcp-bideetmusique

Name: mcp-bideetmusique
Author: smeet666

by smeet666

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

mcp-bideetmusique

Un servidor MCP para Bide & Musique, la emisora en línea y el catálogo artesanal de canciones francesas que la fama pasó por alto. Sin clave de API, sin cuenta, solo lectura.

La colección ha sido catalogada desde el año 2000 por la asociación voluntaria que gestiona la emisora: año, sello, referencia de catálogo, autores y compositores, para decenas de miles de discos que ninguna otra base de datos describe así.

Lo que hace

Cinco herramientas.

search_songs busca en un solo eje a la vez. El eje debe ser nombrado, porque cada uno plantea una pregunta diferente y una respuesta en uno no dice nada sobre los demás.

`search_type`	Encuentra
`performer`	el artista acreditado en el disco
`title`	el nombre de la canción
`writer`	quién la escribió o compuso
`lyrics`	las palabras cantadas en ella
`label`	el sello en el que salió
`year`	el año impreso en ella

get_song resuelve un identificador de una búsqueda en la ficha misma: el año, los autores y compositores, la duración, el sello y su referencia de catálogo, la carátula, el día en que se catalogó en la colección, la clasificación de la emisora, y cuántas personas la guardaron como favorita. Una ficha cuya página lleva una transcripción devuelve las palabras y quién las escribió; include_lyrics las omite cuando la pregunta es sobre el disco.

get_artist lee la página de un artista: quién es, los nombres bajo los que también grabó, y lo que la colección tiene de él.

get_random_song responde con una ficha que nadie eligió. El sitio no publica ninguna ruta hacia una aleatoria, así que el sorteo se hace sobre los identificadores que sirve, desde el primero hasta el más reciente que nombra su feed de nuevas entradas, y un identificador que la colección no sirve se sortea de nuevo.

list_new_songs lee lo que la colección acaba de catalogar. El feed detrás contiene un número fijo de entradas y no ofrece segunda página, por lo que su cuenta es una ventana a los discos más recientes, no un recuento de la colección.

Related MCP server: mcp-gouv-fr

Lo que no afirmará

Cada respuesta está construida para que un llamante sepa lo que el sitio dijo realmente:

Un fallo nunca es un resultado vacío. Seis códigos de error, y una búsqueda que el sitio rechazó no es una colección que no contiene nada.
El contador es el propio del sitio, que cuenta las canciones de todas las páginas, por lo que suele superar las filas de una página. Un contador que el sitio no imprimió es null, nunca 0.
La página servida se lee, no se asume. Pedir una página más allá de la última devuelve la última página sin error, y la respuesta lo indica.
La coincidencia se da dentro de las palabras. Buscar Bino devuelve discos de Bambino, y la respuesta señala que ninguna fila lleva la consulta como palabra.
Varias palabras clave se combinan con Y, por lo que cada palabra extra reduce la búsqueda. Una frase entre comillas no devuelve nada, sea cual sea el formulario del sitio.
Las filas vienen en el orden del sitio, por intérprete y luego por título, nunca por relevancia, y cualquier truncamiento lo indica.

Instalar

npm install -g mcp-bideetmusique

Luego regístrelo con su cliente MCP:

{
  "mcpServers": {
    "bideetmusique": {
      "command": "mcp-bideetmusique"
    }
  }
}

Configuración

Todas las variables son opcionales.

Variable	Por defecto	Qué hace
`BIDE_USER_AGENT`	el propio del proyecto	El nombre de su aplicación. Se le añade la identidad del proyecto, para que el tráfico siga siendo atribuible.
`BIDE_MIN_INTERVAL_MS`	`3000`	Intervalo mínimo entre solicitudes. Se rechazan valores inferiores a 2000.
`BIDE_TIMEOUT_MS`	`20000`	Tiempo de espera por solicitud.
`BIDE_MAX_RETRIES`	`3`	Reintentos en fallos transitorios.
`BIDE_CACHE_TTL_MS`	`900000`	Vida útil de la caché en memoria. No se escribe nada en disco.
`BIDE_CACHE_MAX_ENTRIES`	`200`	Tamaño de la caché.
`BIDE_LOG_LEVEL`	`error`	`silent`, `error`, `info` o `debug`, en stderr.

Lo que este servidor debe al sitio

Bide & Musique está gestionado por una asociación voluntaria, en un solo servidor, de forma gratuita. Las solicitudes salen de una en una, con tres segundos de intervalo, y ese suelo no puede reducirse mediante configuración. El User-Agent siempre lleva el proyecto y una dirección donde se pueda contactar a alguien. El servidor lee, nunca escribe.

Licencia

MIT, para el código. Lo que contiene la colección pertenece a Bide & Musique: acredite el sitio y enlace la ficha cuando muestre un resultado.

mcp-bideetmusique (français)

Un serveur MCP pour Bide & Musique, la webradio et le catalogue, bâti à la main, des chansons françaises que la gloire a manquées. Sans clé d'API, sans compte, en lecture seule.

La collection est cataloguée depuis 2000 par l'association bénévole qui tient la station : année, label, référence de catalogue, auteurs et compositeurs, pour des dizaines de milliers de disques qu'aucune autre base ne décrit ainsi.

Ce qu'il fait

Cinq outils.

search_songs cherche sur un axe à la fois. L'axe doit être nommé, parce que chacun pose une question différente et qu'une réponse sur l'un ne dit rien des autres.

`search_type`	Trouve
`performer`	l'interprète crédité sur le disque
`title`	le nom du morceau
`writer`	qui l'a écrit ou composé
`lyrics`	les mots chantés dedans
`label`	le label qui l'a sorti
`year`	l'année imprimée dessus

get_song résout un identifiant rendu par une recherche en la fiche elle-même : l'année, les auteurs et compositeurs, la durée, le label et sa référence de catalogue, la pochette, le jour où la collection l'a catalogué, le classement maison et le nombre de personnes qui l'ont mis en favori. Une fiche dont la page porte une transcription revient avec les paroles elles-mêmes et qui les a saisies ; include_lyrics les laisse de côté quand la question porte sur le disque.

get_artist lit la page d'un artiste : qui il est, les noms sous lesquels il a aussi enregistré, et ce que la collection tient de lui.

get_random_song répond par une fiche que personne n'a choisie. Le site ne publie aucune route vers une fiche au hasard, donc le tirage se fait sur les identifiants qu'il sert, du premier au plus récent que son flux des nouveautés nomme, et un identifiant que la collection ne sert pas donne lieu à un nouveau tirage.

list_new_songs lit ce que la collection vient de cataloguer. Le flux derrière porte un nombre fixe d'entrées et n'offre pas de seconde page, donc son compteur est une fenêtre sur les fiches les plus récentes et non un compte de la collection.

Ce qu'il refuse d'affirmer

Chaque réponse est construite pour qu'un appelant sache ce que le site a réellement dit :

Une panne n'est jamais un résultat vide. Six codes d'erreur, et une recherche refusée par le site n'est pas une collection qui ne contient rien.
Le compteur est celui du site, qui compte les morceaux de toutes les pages, donc il dépasse presque toujours les lignes d'une page. Un compteur que le site n'a pas imprimé vaut null, jamais 0.
La page servie est lue, pas supposée. Demander une page au-delà de la dernière rend la dernière, sans erreur, et la réponse le dit.
La correspondance se fait à l'intérieur des mots. Chercher Bino ramène des disques de Bambino, et la réponse signale qu'aucune ligne ne porte le mot.
Plusieurs mots-clés se combinent en ET, donc chaque mot ajouté restreint. Une expression entre guillemets ne rend rien, quoi qu'en propose le formulaire du site.
Les lignes viennent dans l'ordre du site, par interprète puis par titre, jamais par pertinence, et toute troncature le rappelle.

Ce que ce serveur doit au site

Bide & Musique est tenu par une association bénévole, sur un seul serveur, gratuitement. Les requêtes partent une à la fois, à trois secondes d'intervalle, et ce plancher ne se descend par aucune configuration. Le User-Agent porte toujours le projet et une adresse où joindre quelqu'un. Le serveur lit, il n'écrit jamais.

Licence

MIT, pour le code. Ce que contient la collection appartient à Bide & Musique : créditez le site et liez la fiche quand vous montrez un résultat.

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.

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

Deploy Server

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A4.8/5.0

Scored 2026-08-22 02:41 across 5 tools

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

ActivityActive

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
264
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
3123
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
D
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
A
license
A
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 6 months ago (2026-04-10 10:42 UTC)
11
MIT
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-10-06 01:49 UTC)
3
49 npm
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 2 months ago (2026-08-06 17:44 UTC)
4 npm
1
MIT