tidal_get_album_videoRetrieve an album's video-art URL from TIDAL when available, using an album ID and optional dimensions.
Return the album's video-art URL when available.
| Name | Required | Description | Default |
|---|---|---|---|
| album_id | Yes | ||
| dimensions | No |
| Name | Required | Description | Default |
|---|---|---|---|
| item | No | ||
| text | No | ||
| count | No | ||
| items | No | ||
| limit | No | ||
| value | No | ||
| offset | No | ||
| has_more | No | ||
| warnings | No | ||
| operation | Yes | ||
| next_offset | No |
Changes observed during successful MCP inspections.
v1.0.1Does 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 one genuine behavioral fact — the URL may not exist ('when available') — but says nothing about auth requirements, rate limits, or fallback behavior when the video-art is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with no filler, and the qualifier 'when available' is placed where it matters. It is efficient, though efficiency here comes partly from omitting necessary detail rather than from disciplined editing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return-value explanation is not needed, but the tool has an undocumented 'dimensions' parameter and is surrounded by many similar lookup tools with no differentiation. For a 2-parameter tool with zero schema coverage, the description is too thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden and fails: it never mentions the 'dimensions' parameter (default 1280, range 80-3000) that controls the returned image size, nor the constraints on album_id. 'The album's' only loosely implies the album_id input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns the album's video-art URL. However it does not distinguish itself from near-identical siblings such as tidal_get_album_image or tidal_get_video_image, and the phrase 'album video-art' remains ambiguous versus a regular album image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage cue is 'when available', which describes a possible outcome rather than a usage condition. There is no guidance on when to prefer this over tidal_get_album_image, tidal_get_video_image, or tidal_get_video_url.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.