Skip to main content
Glama
sickn33
by sickn33

Browse an artist page

tidal_get_artist_page
Read-only

Fetch a TIDAL artist page by artist ID to access structured profile and catalog details for that artist in an MCP client.

Instructions

Return the structured TIDAL page associated with an artist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
artist_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemNo
textNo
countNo
itemsNo
limitNo
valueNo
offsetNo
has_moreNo
warningsNo
operationYes
next_offsetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it doesn't say what a 'page' payload contains, whether it is a composite layout response, or how it relates to the other artist endpoints. For a tool whose main ambiguity is its output shape, this is thin.

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?

One front-loaded sentence with no filler or redundancy. It is appropriately sized, though its brevity edges toward under-specification rather than efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out, but the description still leaves the tool's core distinction from tidal_get_artist unresolved and gives no guidance on the required artist_id. For a 1-parameter, open-world read tool in a dense sibling cluster, it is not complete enough to route correctly.

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

Parameters2/5

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

Schema description coverage is 0% and the single required parameter artist_id has no description in the schema or the description text. The description never mentions the ID, its expected format, or where to obtain it, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a verb ('Return') and a resource ('the structured TIDAL page associated with an artist'), but the key term 'structured page' is never defined, leaving it unclear how this differs from tidal_get_artist or tidal_get_album_page. An agent cannot confidently tell what a 'page' object is versus the plain artist resource from this sentence alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no exclusion, and no reference to any of the many sibling tools that also return artist data (tidal_get_artist, tidal_get_artist_bio, tidal_get_artist_albums). The agent is left to infer the selection criteria entirely.

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

Deploy Server

Other Tools