Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

spotify_artist_playlists

Fetch playlists for a Spotify artist using an artist ID, URI, or open.spotify.com URL, returning titles, descriptions, images, and Spotify links.

Instructions

Retrieve Spotify artist playlists. Returns the Spotify playlists associated with an artist, by artist URI, open.spotify.com URL or id. Each playlist has a title, subtitle, description, Spotify URI, external URL and images. Some artists have no playlists, in which case items is empty.

Input Schema

NameRequiredDescriptionDefault
idNoSpotify artist ID
uriNoSpotify artist URI or open.spotify.com artist URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations attached, the description carries the full disclosure burden and does disclose the return shape (title, subtitle, description, Spotify URI, external URL, images) plus a concrete edge case: artists with no playlists yield an empty `items`. It omits auth/rate-limit context, but for a public read this is a solid behavioral account.

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, front-loaded with purpose, followed by input formats, return fields, and the empty-result case. Nothing is redundant with the schema beyond a helpful restatement, and each sentence carries information.

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?

Without annotations or an output schema, the description compensates well by enumerating returned fields and covering the empty-items scenario. It stops short of noting read-only/pagination behavior, but nothing essential for a correct call is missing.

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 coverage is 100% and the schema already documents both `id` and `uri` with their accepted formats. The description restates those formats but adds no new parameter meaning, 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?

States a specific verb and resource ('Retrieve Spotify artist playlists') and immediately scopes it to playlists 'associated with an artist,' which cleanly separates it from spotify_artist_albums and spotify_artist_related. An agent can identify the operation without opening the schema.

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?

The description implies when to use it by naming the accepted artist identifiers (URI, open.spotify.com URL, or id), but it never states when to prefer this over siblings like spotify_profile_playlists or spotify_playlists_search, nor any exclusions. Usage is inferable rather than explicit.

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