Playbook

List group children

list_group_children

Read-only

List the assets inside a group. list_assets and the search tools return only top-level rows, so this is how a group's members are read. A group is a container asset that holds other assets as variants — different formats or crops of the same thing, or a set of colour swatches, which Playbook shows as a palette. The group has no file of its own and takes its preview from its first displayable child. token must be a group — an asset whose is_group is true in get_asset or get_assets; anything else is refused as not a group. Results are paginated, newest first.

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

Input Schema

Name	Required	Description
`page`	No	Page number (1-indexed)
`token`	Yes	Token of the group asset
`fields`	No	Return ONLY these fields on each row. `token` is always included. Valid names: token, title, media_type, text_type, status, approved, approved_after, tags, permalink, display_url, stream_url, collection_token, size, is_skeleton, uploaded_by, source_error, ai_generated, ai_agent_payload. An unknown name is refused, not ignored.
`per_page`	No	Items per page (1-100, default 20)
`organization`	No	Workspace slug, as returned by list_organizations. Omit it when the account has a single workspace — it is then resolved from your token. Pass it only when the account has several, or when you mean a workspace other than the obvious one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 3, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / page / maximum
```
Added value: +9007199254740991
```
AddedOct 7, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds genuinely new behavior: non-group tokens are rejected, groups have no file of their own, the preview derives from the first displayable child, and results are paginated newest-first. The only gap is that it does not say what an empty group returns or what error shape a refusal takes.

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?

Front-loaded with the core action and the sibling contrast, then builds outward to group semantics, token validation, and pagination order. It is somewhat longer than needed — the palette/colour-swatches aside is illustrative rather than operational — but every sentence is relevant and no paragraph buries the key constraint.

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?

With no output schema, the description still conveys return behavior (paginated, newest first) and the `fields` parameter enumerates row-level attributes in the schema. Combined with the strong token precondition, an agent has enough to call this correctly; only the exact row shape and error semantics remain implicit.

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, but the description adds real meaning for the required `token`: it must reference an asset whose is_group is true, verifiable via get_asset/get_assets, and other tokens are refused. It does not elaborate on page, per_page, fields, or organization, but those are fully documented in 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?

Opens with a specific verb and resource ("List the assets inside a group") and immediately contrasts it with list_assets and the search tools, so an agent can tell it apart from siblings without reading schemas. The clarifying sentence about groups being container assets further pins down what is being listed.

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

Usage Guidelines5/5

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

Explicitly states when to use it ("list_assets and the search tools return only top-level rows, so this is how a group's members are read") and names the alternatives it supersedes. It also states the precondition for the token — it must be a group per is_group in get_asset/get_assets — and that anything else is refused, which is exactly the routing guidance an agent needs.

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

All Playbook tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?