Skip to main content
Glama

load_playlists

Copies selected Spotify playlists into the local cache and shows an overview dashboard, skipping unchanged playlists unless a forced refresh is requested.

Instructions

Copy playlists from Spotify into the local cache and show the overview dashboard.

Only load the playlists the user chose. If they haven't said which ones, ask them first (list_my_playlists shows the options); don't load all of them unless they ask for that.

Args: playlists: playlist IDs or Spotify playlist links of the playlists the user chose. force: re-read playlists even if they haven't changed since the last load.

Playlists that haven't changed are skipped. The dashboard covers everything in the cache.

Input Schema

NameRequiredDescriptionDefault
forceNo
playlistsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.1

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does well by explaining caching, skipping unchanged playlists, and the force override. It does not mention prerequisites such as connecting to Spotify or possible failure modes, so it is helpful but not fully comprehensive.

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 front-loaded with purpose and usage guidance, then gives concise parameter notes and a brief caching caveat. The repetition around loading only chosen playlists reinforces an important safety constraint rather than adding noise.

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 two-parameter cache-loading tool with no annotations or output schema, the description covers purpose, selection rules, caching behavior, and the dashboard effect. The main gap is the lack of an explicit Spotify connection prerequisite or error-handling 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 description coverage is 0%, so the description must compensate, and it does: playlists are playlist IDs or Spotify playlist links for the chosen playlists, and force re-reads unchanged playlists. The meaning of both parameters is clear, though format details beyond IDs/links are not expanded.

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?

The description states a specific action: copy chosen Spotify playlists into a local cache and show the overview dashboard. It distinguishes the loading work from the dashboard display, though it could more explicitly contrast with siblings such as show_overview or list_my_playlists.

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

Usage Guidelines5/5

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

It gives explicit usage rules: only load playlists the user chose, ask first if they have not specified any, and do not load everything unless requested. It also points to list_my_playlists for discovering options, which is exactly the alternative an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.