@jam-jam/convert-mcp

List playlists published by an account

jj_list_profile_playlists

Lists playlists published on a user's profile, returning only entries and song counts the caller is permitted to see, with cursor-based pagination.

Instructions

Lists the playlists an account has published on its profile. Same visibility rules as jj_list_profile_songs. songCount already counts only what the caller is allowed to see: a published playlist hides the songs its author did not publish.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "handle": "<handle>"
    },
    "name": "jj_list_profile_playlists"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Page size, default 30, hard cap 100.
`cursor`	No	Opaque cursor from a previous call's `nextCursor`. Replay it verbatim.
`handle`	Yes	Public username of the account, with or without the leading "@".

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.2Nov 13, 2026

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full disclosure burden. It does add genuinely non-obvious context — that results follow the same visibility rules as jj_list_profile_songs and that `songCount` is already filtered to what the caller may see — but it says nothing about authentication requirements, error behavior for unknown or private handles, or pagination semantics beyond what the schema states.

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 short sentences, front-loaded with the core action and followed by the two non-obvious behavioral caveats. Nothing is padded, though the cross-reference to jj_list_profile_songs is only useful if the agent already knows that tool's rules.

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 three-parameter list tool with no output schema, the description covers purpose and the key filtering quirk but omits the return shape (fields on each playlist), the fact that `nextCursor` drives paging, and how this differs from jj_list_playlists. Adequate but with clear gaps an agent would have to discover by calling it.

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 `handle`, `limit`, and `cursor` are already fully documented in the schema, establishing a baseline of 3. The description adds only the mild implication that `handle` can be any account with a profile, without clarifying whether it must be the caller or can be any public user.

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 gives a specific verb and resource — 'Lists the playlists an account has published on its profile' — and scopes it to public profile output rather than the caller's own library. It does not directly name jj_list_playlists or jj_get_playlist as the contrasting alternative, so the boundary with siblings is implied rather than stated.

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?

It points to jj_list_profile_songs only for the visibility rules, which is a reference for behavior rather than a when-to-use rule. There is no explicit guidance on when to pick this over jj_list_playlists or jj_get_playlist, nor any stated precondition about the account being public.

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