Skip to main content
Glama

Read an artist's page

get_artist
Read-onlyIdempotent

Retrieve an artist's Bide & Musique page from an artist_id to view their recording names, catalogue notes, and discography with release years.

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, 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.

Input Schema

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

Output 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'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed18 schema fields changedv2.1.0
    • removedOutput schema / properties / birth_date / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / birth_date / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / discography / items / properties / image_url / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / discography / items / properties / image_url / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / discography / items / properties / programming / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / discography / items / properties / programming / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / discography / items / properties / thumbnail_url / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / discography / items / properties / thumbnail_url / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / first_name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / first_name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / nationality / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / nationality / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / photo_url / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / photo_url / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / presentation / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / presentation / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / surname / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / surname / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Changed1 schema field changedv1.0.0
    • 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'."
  3. First observedv0.3.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses important data quirks: absent fields return null or empty rather than indicating failure, dates come through exactly as written, nationality is free text, and rows are ordered by release year rather than importance. It also states the attribution and linking requirement when presenting an artist to a user.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is front-loaded with the core action and then adds only relevant caveats about missing fields, date formats, ordering, and attribution. Despite its length, each sentence contributes useful context for invoking and presenting the tool correctly.

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 an output schema exists, the description does not need to spell out return values. It still provides enough behavioral context—null/empty fields, free-text dates, ordering, and attribution—for an agent to use the tool correctly in this catalogue.

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 schema already documents both 'artist_id' and 'limit', including examples and bounds. The description reinforces where 'artist_id' comes from but does not add meaning for 'limit' or other parameter behaviors beyond what the schema provides, so the baseline of 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 states a specific verb and resource: read an artist's page on Bide & Musique, including recorded names, catalogue notes, and held songs with years. It distinguishes the artist page from a biography and explains that it is an entry point into a discography, making its role clear against sibling lookup tools.

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 clearly says the tool takes an 'artist_id' returned by search_songs, get_song, and get_random_song, which gives the agent a concrete usage path. It also frames the page as a discography entry rather than a biography, though it does not explicitly state when not to use this tool or name an alternative for artist search.

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