Skip to main content
Glama
NovaLux12

SpotifyMCP

by NovaLux12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_saved_audiobooks

List audiobooks saved in your Spotify library. Paginate results, adjust limits, and choose between concise, detailed, or raw JSON output.

Instructions

List the audiobooks saved in the current user's Spotify library. Requires the user-library-read scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoResults per page, 1–50. Default: 20
offsetNoIndex of the first audiobook to return. Default: 0
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. Changed4 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 / offset / maximum
      Added value: +9007199254740991
    • 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"
+}
  2. First observedv1.0.1

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral disclosure burden. It adds a valuable detail about the required 'user-library-read' scope, but it does not explicitly confirm the operation is read-only, describe pagination behavior, or explain how the response_format parameter affects output. The verb 'List' implies a safe read operation, but coverage is only partial.

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?

The description is two concise sentences with no wasted words. The action is front-loaded in the first sentence, and the second sentence adds an essential auth requirement. Every part earns its place.

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?

For a low-complexity list tool with a fully documented parameter schema, the description covers the essential invocation context: what it lists, whose library it targets, and what auth scope is needed. Since there is no output schema, a bit more detail about response shape or pagination could be added, but the core information an agent needs to select and invoke the tool is present.

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?

All four parameters (limit, offset, max_results, response_format) have their own descriptions in the input schema, giving 100% schema description coverage. The tool description adds no parameter-specific meaning, so the baseline of 3 applies without needing to compensate for gaps.

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?

The description uses a specific verb ('List') and a specific resource ('audiobooks saved in the current user's Spotify library'), clearly distinguishing it from sibling tools like get_saved_tracks, get_saved_shows, and get_audiobook. The scope requirement further anchors its purpose without ambiguity.

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 gives a clear context for when to use this tool—listing the current user's saved audiobooks—and explicitly states the required OAuth scope. However, it does not mention alternatives such as search_saved_audiobooks or get_audiobook, nor any when-not-to-use conditions, leaving usage guidance implied 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