Skip to main content
Glama
smeet666

mcp-bideetmusique

Read an artist's page

get_artist
Read-onlyIdempotent

Retrieve an artist's discography from Bide & Musique, including every song, recording alias, and catalogue notes, sorted by release year. Provide an artist_id from a prior search to access the full discography.

Instructions

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 and get_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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum songs of the discography to return.
artist_idYesThe artist id returned by search_songs or get_song, digits only, for example '290'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
nameYes
linksYesAddresses off the site, with the label the page gave them.
notesYes
sourceYes
aliasesYesOther names this artist recorded under, as the page stacks them.
surnameYes
see_alsoYes
artist_idYes
photo_urlYes
birth_dateYesExactly 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_nameYes
discographyYes
nationalityYesAs the catalogue writes it, in its own words: 'suisse', 'franco-espagnole'.
presentationYes
songs_on_pageYesSongs the page held, before 'limit'.
discography_countYesSongs returned, after 'limit'.
Behavior5/5

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

The description goes far beyond the annotations. It explains that null/empty fields are the ordinary state, not a failed read. It details how date of birth and nationality are returned (as raw free text). It states the sorting order (by year of release, never by importance). This adds substantial behavioral context that annotations alone could not convey.

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 fairly long but each sentence adds value: purpose, usage dependencies, behavioral caveats, and attribution requirement. It is front-loaded with the core purpose. Minor deduction because the attribution instruction could be shortened, but overall it earns its length with substantive content.

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 that there is an output schema, the description does not need to detail return format. However, it richly explains what the output represents, edge cases (null fields), data fidelity issues (birth dates as-is), and attribution. The complexity is low (2 params, 1 required), and the description is fully complete for an AI agent to use this tool effectively.

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

Parameters3/5

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

Schema description coverage is 100%, and the input schema already explains both parameters (artist_id with pattern/example, limit with default/max/min). The description reinforces that artist_id comes from specific other tools and explains what limit controls ('Maximum songs of the discography to return'), but does not add new semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.

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 what the tool reads (an artist's page on Bide & Musique), listing specific content: names, catalogue notes, and songs with years. It distinguishes itself from siblings by mentioning that it takes the 'artist_id' returned by search_songs and get_song, and the content differs from a song or search result.

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 tells when to use this tool (when you have an artist_id from search_songs or get_song) and what the tool is not (a biography). It also provides a usage directive: 'When you show an artist to a user, credit Bide & Musique and link the page.' This is clear guidance that goes beyond mere purpose.

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

Install Server

Other Tools

Latest Blog Posts

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