@jam-jam/convert-mcp

Create a notebook playlist

jj_create_playlist

Creates a playlist in the calling account's notebook from ordered live song IDs, with songs allowed in multiple playlists.

Instructions

Creates a playlist in the calling account's notebook. Playlists are flat and allow multi-membership: a song can be in several of them. songIds is the ordered content and every id must be a live song of this account. Consumes one unit of the daily write quota.

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": {
      "name": "<name>"
    },
    "name": "jj_create_playlist"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Playlist name as the user will see it.
`songIds`	No	Ordered content of the playlist; the order is what the user will see and is never re-sorted. Every id must be a live song of this account, otherwise the whole call fails: a half-created playlist would be worse than a refusal.
`coverEmoji`	No	Single emoji used as the cover, or null for none.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.2Nov 13, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations present the description carries the full burden, and it does disclose real behavioral traits: playlists are flat, multi-membership is allowed, and the call 'consumes one unit of the daily write quota' — a cost signal not present anywhere else. It also reinforces all-or-nothing validation semantics, though it says nothing about return values, permissions, or what happens on quota exhaustion.

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 purpose before the data-model note and the quota cost. Nearly every clause earns its place; the songIds sentence overlaps with the schema text, which is the only mild redundancy.

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 3-parameter creation tool with no output schema and no annotations, the description covers the important non-schema facts: flat/multi-membership model, quota cost, and validation atomicity. The main remaining gap is what the call returns (an id? the playlist object?), which matters because there is no output schema for the agent to fall back on.

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 the schema already documents name, songIds and coverEmoji thoroughly. The description restates the songIds semantics (ordered content, live songs, whole-call failure) without adding syntax or format detail, and never mentions coverEmoji or name at all, so the baseline 3 is appropriate.

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 opens with a specific verb+resource+scope: 'Creates a playlist in the calling account's notebook,' which tells an agent exactly what is produced and where. It does not name or contrast any sibling (e.g. jj_update_playlist or jj_create_song), so differentiation from the rest of the catalog is left to inference, which keeps it below a 5.

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 is only implied by the phrase 'Creates a playlist' plus the constraint that the account must own the referenced songs. There is no explicit when-to-use guidance, no statement of when not to use it, and no pointer to the alternative tools for the update/list/delete cases that an agent would otherwise have to guess between.

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