Cactal

Add a field to a collection

cms_fields_create

Adds a typed field at the end of the collection’s field order. key is lowercase snake_case (max 64 characters), must be unique in the collection, and cannot use the reserved metadata names id, slug, publishedAt, publishAt, createdAt, updatedAt, or position; type is immutable after creation. reference and multi_reference fields require a targetCollectionId in the same website, and option fields require config.choices (1–1,000 choices). A collection can hold at most 100 fields, and required: true is rejected while the collection has active items — add the field as optional, backfill every item, then mark it required.

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": {
      "key": "<key>",
      "displayName": "<displayName>",
      "type": "<type>",
      "collectionId": "<collectionId>"
    },
    "name": "cms_fields_create"
  }
}

Input Schema

Name	Required	Description	Default
`key`	Yes
`type`	Yes
`config`	No
`example`	No
`isUnique`	No
`required`	No
`description`	No
`displayName`	Yes
`collectionId`	Yes
`targetCollectionId`	No

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 declare a non-readonly, non-destructive, non-idempotent mutation, and the description adds substantial context beyond that: type immutability, a 100-field hard cap, uniqueness and reserved-name rejection, cross-website restriction on reference targets, and the required-with-active-items failure mode. Those are exactly the preconditions an agent would otherwise discover only by failing.

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 action and placement, then constraints ordered by risk. It is dense — a single long block mixing naming rules, type rules, and the required-field workflow — but no clause is filler; the density slightly hurts scanability.

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-param nested mutation with no output schema and zero schema coverage, the description covers the failure-prone surface thoroughly. The remaining gap is the quieter optional parameters (isUnique, example, config.multiple), which an agent could mis-set without the description warning it.

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 0%, so the description must carry the burden, and it does for the high-risk parameters: key format and uniqueness, the reserved-name list, targetCollectionId for reference/multi_reference, and config.choices with its 1–1,000 bound. It leaves displayName, description, example, isUnique, and config.multiple unexplained, so coverage is strong but not complete across 10 parameters.

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?

States a specific verb and resource plus non-obvious scoping behavior: 'Adds a typed field at the end of the collection's field order.' The clause 'type is immutable after creation' implicitly separates this from cms_fields_update, so an agent can distinguish create from modify without opening the sibling 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?

Gives explicit operational routing for a hard case: 'required: true is rejected while the collection has active items — add the field as optional, backfill every item, then mark it required.' It does not explicitly say when to prefer this over cms_fields_update or cms_collections_create, but the create-vs-modify boundary is implied by the immutability note.

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?