Cactal

Get an item

cms_items_get

Read-onlyIdempotent

Returns one item, looked up by itemId or by the collectionId + slug pair (provide exactly one of the two). The data object is complete and schema-shaped: every currently-defined field is present and missing optional values read as null. depth (0–3, default 0) embeds referenced items in place of their ids, one level per unit; referenced items that were deleted read as null (single reference) or are omitted from arrays (multi-reference). Set published to "true" or "false" to match only a published or only a draft item (a mismatch reads as not found). List items that reference it with cms.items.backreferences.list.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cms_items_get"
  }
}

Input Schema

Name	Required	Description
`slug`	No	Item slug within the collection. Pair with `collectionId`.
`depth`	No
`itemId`	No	Item id. Provide either this or the `collectionId` + `slug` pair.
`published`	No	Only match a published (`"true"`) or draft (`"false"`) item; a mismatch reads as not found. Omit to match either.
`collectionId`	No	Collection to look the item up in by slug. Pair with `slug`.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses that `data` is always complete and schema-shaped with `null` for missing optionals, that `depth` embeds one level per unit, that deleted references surface as `null` in single-reference fields and are omitted from arrays, and that a `published` mismatch reads as not found. These are exactly the non-obvious behaviors an agent needs before interpreting results.

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?

Four dense sentences with no filler, front-loaded with the lookup contract before the depth and published details. Slightly packed — the depth/embedding sentence carries several clauses — but every sentence contributes information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description compensates by describing the returned `data` shape, null semantics, and embedding behavior. Combined with the annotation safety profile, an agent has everything needed to call this correctly and interpret the response.

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 80%, so most parameters are already documented, but the description adds the crucial meaning for `depth` (one embedding level per unit, 0–3, default 0) that the bare schema min/max/default does not convey, and restates the `published` mismatch semantics. The mutually exclusive itemId vs collectionId+slug pairing is also clarified beyond the schema's per-field notes.

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 ("Returns one item") and immediately defines the two lookup keys, which cleanly separates it from the plural `cms_items_list` and from `cms_items_backreferences_list`. An agent can identify the operation and its dual addressing mode without opening the schema.

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

Usage Guidelines4/5

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

Explicitly states the either/or constraint ("provide exactly one of the two") and routes the agent to `cms_items.backreferences.list` for the related reverse-lookup case. It does not say what to do when the item is unknown beyond the `published` mismatch case, but the calling context is clear.

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

All Cactal tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?