Cactal

Create an item

cms_items_create

Creates an item at the end of the collection’s manual order. Scalar values go in data keyed by field key and are validated against the field types — unknown keys are rejected, required fields must be present, plain_text and markdown are capped at 1,048,576 bytes (markdown must not contain raw HTML), date values are ISO 8601 with timezone, and color values are normalized to hex. Relationship and asset values go in the side maps: references (reference: an item id; multi_reference: an ordered array of up to 1,000 ids), images (image: an asset id or { assetId, altText }; gallery: an ordered array of up to 25 of those), and files (file: an asset id or { assetId }). slug is optional — it is derived from data.title or data.name when omitted. Set a non-future publishedAt to create an already-published item, or a future publishAt to schedule it; the two fields are mutually exclusive.

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_create"
  }
}

Input Schema

Name	Required	Description
`data`	No
`slug`	No
`files`	No
`images`	No
`publishAt`	No	Future absolute timestamp for scheduled publication. Cannot be combined with `publishedAt`.
`references`	No
`publishedAt`	No	Initial publication timestamp. Must not be in the future. Omit for a draft, or use `publishAt` to schedule publication.
`collectionId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already establish non-read-only, non-idempotent, non-destructive, open-world behavior; the description adds substantial behavior beyond them. It discloses validation rules, rejection of unknown keys, required-field enforcement, text size caps, date/color normalization, relationship/asset limits, slug derivation, and publication scheduling semantics.

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 description is long but justified by eight parameters and nested validation rules, and it front-loads the core creation behavior. It is a dense single paragraph, however, so the semicolon-heavy structure is less scannable than grouped or bullet-like formatting would be.

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?

For a complex create operation with no output schema, the description covers the invocation-critical semantics: scalar validation, relationship/asset payload shapes, slug fallback, and publication timing. It omits return-shape and permission details, but the annotations and schema cover the safety and type baseline sufficiently.

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 low at 25%, so the description carries the burden and does so thoroughly. It explains how data keys map to field types, how references/images/files side maps work with per-field shapes and limits, slug derivation, and the mutually exclusive publishedAt/publishAt semantics.

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 first sentence gives a specific verb and resource — creates an item — and adds the placement detail 'at the end of the collection’s manual order.' It is clearly a creation operation, but it does not explicitly name or contrast with siblings such as cms_items_update or cms_items_setPublished.

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?

The description establishes clear usage context for creating a draft, an already-published item, or a scheduled item via publishedAt/publishAt, and notes their mutual exclusivity. It does not give explicit when-not guidance or point to sibling tools for later updates or publication changes.

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?