Skip to main content
Glama

get_play_queues_by_play_queue_id

Read-onlyIdempotent

Retrieve a specific play queue by ID to view its items, with options to adjust the visible window or transfer ownership for remote control.

Instructions

Retrieve a play queue.

GET /playQueues/{playQueueId}

Args: play_queue_id: The ID of the play queue. own: If the server should transfer ownership to the requesting client (used in remote control scenarios). center: The play queue item ID for the center of the window - this doesn't change the current selected item. window: How many items on each side of the center of the window include_before: Whether to include the items before the center (if 0, center is not included either), defaults to 1. include_after: Whether to include the items after the center (if 0, center is not included either), defaults to 1.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ownNo
centerNo
windowNo
include_afterNo
play_queue_idYes
include_beforeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate safety. It adds useful behavioral context for parameters, such as ownership transfer, the center/window mechanism, and that center does not change the current selection. No contradiction with annotations.

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?

The purpose is front-loaded in one sentence, the endpoint is given, and the argument list is compact and information-dense. It is slightly longer than strictly necessary but contains no 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?

All parameters are documented, return values are covered by the output schema, and annotations convey the safety profile. It is not a 5 because usage guidance and some value formats are left vague, but an agent could call this tool correctly with the information provided.

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?

With 0% schema description coverage, the description compensates well by explaining all six parameters, including defaults and the include_before/include_after edge case. Minor gaps remain: accepted values for own/include_before/include_after are not specified, and window has no stated default.

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?

The opening line 'Retrieve a play queue' uses a specific verb and resource, reinforced by the explicit GET /playQueues/{playQueueId} endpoint. This clearly distinguishes it from sibling list, create, update, and delete play-queue tools.

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

Usage Guidelines2/5

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

The description gives no explicit guidance on when to use this tool versus list_play_queues_1, update_play_queues_by_play_queue_id, or other play-queue endpoints. The only usage signal is inferred from the name and GET verb, so the agent must guess the appropriate context.

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