Skip to main content
Glama

List items in a collection

cms_items_list
Read-onlyIdempotent

Returns the collection’s active items in manual (drag) order by default, 20 per page (max 100); paginate with cursor or with 1-based page offsets, not both. Filter with published (true / false) and a JSON-encoded filter map of { fieldKey: { operator: value } } — operators eq, neq, in, nin, gt, gte, lt, lte, contains, startsWith, endsWith, and exists, plus slug equality on reference fields; metadata keys are id, slug, publishedAt, publishAt, createdAt, and updatedAt. Combine clauses with filterLogic (and by default, or or). search accepts a query string (1–200 characters) or JSON { "query", "fields" } to restrict which text fields are searched; sort accepts JSON { "kind": "field" | "meta", "field", "direction": "asc" | "desc" }, where sortable metadata fields are id, slug, publishedAt, publishAt, createdAt, updatedAt, and position. depth (0–3, default 0) embeds referenced items in place of their ids, one level per unit.

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

Input Schema

NameRequiredDescriptionDefault
pageNo
sortNo
depthNo
limitNo
cursorNo
filterNo
searchNo
publishedNo
filterLogicNo
collectionIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare this as a read-only, idempotent, non-destructive operation. The description adds meaningful behavioral context beyond annotations: only 'active' items are returned, manual order is the default, pagination caps at 100, cursor and page are mutually exclusive, and depth controls reference embedding.

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?

The description is dense but every sentence earns its place. It front-loads the core return behavior and defaults, then proceeds through pagination, filtering, searching, sorting, and depth in a logical order without wasted prose.

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 10-parameter list tool with no output schema, the description covers invocation semantics thoroughly. The main gap is return-value detail: it does not explicitly describe response shape or whether pagination metadata such as the next cursor is included, though this is a minor limitation for a standard list endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden for 10 parameters. It explains pagination modes, filter JSON structure and supported operators, metadata keys, filterLogic defaults, search formats, sort structure, sortable fields, and depth behavior in detail. This is a strong semantic layer beyond 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?

The description opens with a specific verb and resource: 'Returns the collection’s active items.' It states scope ('active items'), default ordering ('manual (drag) order'), and default page size, which distinguishes this from sibling tools like cms_items_get or cms_items_backreferences_list.

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?

The description gives detailed operational guidance for pagination, filtering, searching, sorting, and depth, but it does not explicitly say when to use this tool rather than cms_items_get, cms_items_backreferences_list, or other item-related siblings. Usage is implied by the tool name and resource scope, but no alternative routing guidance is provided.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources