Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

spotify_album

Retrieve album details from Spotify by ID, URI, or open.spotify.com URL, including artists, release date, copyrights, cover art, total tracks, duration, and paginated track lists.

Instructions

Retrieve Spotify album details. Returns a Spotify album from uri (a Spotify URI or open.spotify.com URL) or id: name, album type, artists, release date, copyrights, cover images, total tracks and duration. The tracks page is set by offset (default 0) and limit (1 to 50, default 50). A missing or invalid identifier returns 400.

Input Schema

NameRequiredDescriptionDefault
idNoSpotify album ID
uriNoSpotify album URI or open.spotify.com album URL
limitNoTrack limit, clamped to 1-50
offsetNoTrack offset

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It discloses read-style retrieval, returned fields, pagination defaults/clamping, and the 400 error case, but does not cover auth requirements, rate limits, or explicitly state that the operation has no side effects.

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?

Four tight sentences with no filler: purpose first, then return fields, pagination behavior, and error behavior. It is appropriately front-loaded and sized for a simple detail-retrieval tool.

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

Completeness4/5

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

No output schema exists, so listing the returned album fields is valuable, and the error/pagination notes add useful behavior. It remains slightly incomplete because it lacks sibling-routing guidance and auth/rate-limit context.

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 already 100%, so the baseline is 3. The description adds useful meaning beyond the schema: default limit 50, default offset 0, the 1–50 limit range, accepted URI/URL forms, and the fact that offset/limit page through tracks.

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

Purpose4/5

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

States a specific verb and resource: “Retrieve Spotify album details,” and enumerates the album fields returned. It is clearly an album-detail-by-identifier tool, though it does not explicitly contrast itself with sibling tools such as album search or album tracks.

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

Usage Guidelines3/5

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

Implies usage when you already have a Spotify URI/URL or album ID, and notes that a missing or invalid identifier returns 400. It gives no explicit when-not guidance or alternatives, such as using a search tool first to find an album ID.

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