Skip to main content
Glama
SHREESHMAN

Lineupify

by SHREESHMAN
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

New songs from your favourite artists

refresh_taste

Build a draft from your top and followed artists while skipping tracks already in your liked library. A shortcut for turning your listening taste into a ready-to-review playlist.

Instructions

Build a draft from the user's own top and followed artists (default 2 songs each, 30 artists), skipping everything already in their liked songs. Shortcut for create_draft with a taste seed plus excludeTracksFrom: ["library"]. Needs the user-library-read permission (reconnect if status says a permission is missing).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
orderNointerleave (default, spreads artists), lineup (artist by artist), shuffle, by_day, known_first
publicNo
bpmRangeNoKeep only tracks whose tempo (Deezer) is in this range, e.g. running { min: 160, max: 180 }
providerNospotify: needs a connected account, can publish. deezer: no account or login at all, every feature except publishing (export the list instead). Default: spotify when connected, otherwise deezer
maxTracksNo
strictBpmNoWith bpmRange: also drop tracks with no known tempo
yearRangeNoKeep only tracks released in this range, e.g. { from: 1990, to: 1999 }
skipCoversNoDrop a song when a more popular artist has the original (e.g. a Motörhead cover of Enter Sandman). Off by default; costs one Deezer lookup per track
strictYearNoWith yearRange: also drop tracks whose year is unknown or comes from a remaster/compilation
limitArtistsNodefault 30
allowVersionsNoAllow live/remix/edit versions
discoveryOnlyNoSkip artists already in the user's top or followed artists
tracksPerTierNo
excludeArtistsNo
excludeLibraryNodefault true
maxDurationMinNoTotal length cap, e.g. 45 for a commute
excludeExplicitNo
tracksPerArtistNoSame count for every artist; overrides tracksPerTier. Use 1 for "one song per artist"
excludePlaylistsNoAlso skip tracks in these playlists

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds real value beyond them: it discloses the auth requirement (user-library-read), the reconnect remedy, and the library-exclusion behavior that defines the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core behavior and defaults before the create_draft relationship and the permission note. Dense but no filler; a slightly longer version could have separated the permission caveat more cleanly.

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 20-parameter draft-creation tool with no output schema and nested objects, the description covers purpose, key defaults, auth requirements, and the sibling relationship adequately. It does not describe what the draft response looks like or the interaction between the shortcut and the many optional filters.

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 70%, so the schema already documents most parameters (bpmRange, yearRange, provider, skipCovers, etc.). The description contributes only two defaults (2 songs per artist, 30 artists) and the excludeTracksFrom shortcut, leaving many of the 20 parameters unexplained beyond the schema.

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 (build a draft from the user's top/followed artists) and immediately differentiates itself from the sibling create_draft by framing itself as a shortcut with fixed seed behavior. An agent can tell it apart from create_draft without opening either schema.

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

Usage Guidelines4/5

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

Names the general-purpose alternative explicitly ('Shortcut for create_draft with a taste seed plus excludeTracksFrom: ["library"]') and states the prerequisite permission plus the reconnect remedy. It lacks an explicit 'don't use this when...' clause, but the routing condition is clear.

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