@jam-jam/convert-mcp

List my notebook playlists

jj_list_playlists

Lists playlists in the calling account's notebook with pagination and updatedSince filtering, returning ordered song IDs so you can sync or export multi-membership playlists incrementally.

Instructions

Lists the playlists of the calling account's notebook. Playlists are FLAT and allow multi-membership: songIds is the ORDERED list of song ids, and one song can appear in several playlists. Same cursor pagination and same updatedSince incremental filter as jj_list_songs. Consumes one unit of the daily read quota.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "jj_list_playlists"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Page size, default 30, hard cap 100 (25 when fields="full").
`cursor`	No	Opaque cursor from a previous call's `nextCursor`. Replay it verbatim; never build one.
`updatedSince`	No	ISO 8601 date. Returns only objects STRICTLY newer (updatedAt > updatedSince). Keep the largest updatedAt you received and pass it back next time for an incremental export.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.2Nov 13, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that playlists are FLAT with multi-membership, that songIds is an ordered list, that pagination mirrors jj_list_songs, and that each call consumes one unit of the daily read quota. It does not explicitly state the operation is read-only or describe the returned object shape, keeping it short of a 5.

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?

Three tight sentences, front-loaded with the resource and scope, then data-model facts, then cost. Every sentence carries information an agent needs and none is filler.

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 read-only, three-param list tool with no annotations and no output schema, the description covers scope, data model, pagination behavior, and quota. The remaining gap is return-shape detail (what fields each playlist object exposes besides songIds), which is not fully covered elsewhere.

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 coverage is 100%, so the baseline is 3; the description adds value by tying cursor/updatedSince semantics to jj_list_songs, reinforcing the incremental-export idiom. It adds nothing about `limit` and gives no format hints beyond what the schema already documents.

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?

States a specific verb and resource with an explicit scope: "Lists the playlists of the calling account's notebook." The "calling account's notebook" qualifier helps distinguish it from the profile-oriented sibling, though it never names or contrasts jj_list_profile_playlists directly.

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?

Usage context is implied rather than stated: it points to jj_list_songs for the pagination/incremental-export pattern and notes the quota cost, which tells an agent how to use it efficiently. However, there is no explicit when-to-use / when-not guidance versus jj_list_profile_playlists or jj_get_playlist.

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