Skip to main content
Glama
NovaLux12

SpotifyMCP

by NovaLux12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_followed_artists

Read-onlyIdempotent

Retrieve the list of artists a Spotify user follows. Supports pagination and fetching all followed artists in one request.

Instructions

Get the artists the user follows. fetch_all=true walks every page; limit/after page manually.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
afterNoArtist ID cursor for pagination (from previous response)
limitNo1–50. Default: 20
fetch_allNoWalk every page instead of one page (ignores limit)
max_resultsNoMax items to return (default: SPOTIFY_MCP_MAX_ITEMS env or 50)
response_formatNo'concise' = human prose, 'detailed' = more fields in prose, 'json' = raw API objectconcise

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.1.2
    • addedInput schema / properties / fetch_all
      Added value: +{
+  "description": "Walk every page instead of one page (ignores limit)",
+  "type": "boolean"
+}
  2. Changed2 schema fields changedv1.31.0
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed3 schema fields changedv1.26.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / max_results
      Added value: +{
+  "description": "Max items to return (default: SPOTIFY_MCP_MAX_ITEMS env or 50)",
+  "exclusiveMinimum": 0,
+  "maximum": 2000,
+  "type": "integer"
+}
    • addedInput schema / properties / response_format
      Added value: +{
+  "default": "concise",
+  "description": "'concise' = human prose, 'detailed' = more fields in prose, 'json' = raw API object",
+  "enum": [
+    "concise",
+    "detailed",
+    "json"
+  ],
+  "type": "string"
+}
  4. First observedv1.0.1

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds pagination behavior, but this largely restates the fetch_all schema description ('Walk every page') rather than offering new behavioral context like rate limits or result-size caps.

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?

Two sentences with no filler; the primary purpose is front-loaded and the pagination note is a single compact clause. Every word earns its place.

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

Completeness3/5

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

For a read-only list tool with strong parameter documentation, the description covers the main pagination modes. However, it does not explain how fetch_all interacts with max_results, nor describe the return shape — and there is no output schema to compensate.

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%, so every parameter already has documented meaning. The description mentions fetch_all, limit, and after, but adds no new semantic detail beyond the schema's own descriptions.

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?

Description states the verb and resource explicitly: 'Get the artists the user follows.' The scope is clear and matches the tool name. It does not explicitly contrast with sibling tools like export_followed_artists or check_following_artists, so it lacks explicit sibling differentiation.

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?

Provides clear pagination guidance ('fetch_all=true walks every page; limit/after page manually'), which tells the agent when to use the fetch_all mode vs manual paging. However, it does not address when to prefer this tool over related siblings such as export_followed_artists or check_following_artists.

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