Skip to main content
Glama

Update a field

cms_fields_update
Destructive

Updates displayName, description, required, isUnique, example, and (for option fields only) config; type and targetCollectionId are immutable. Setting required: true is rejected until every active item has a valid value for the field. Setting isUnique: true enforces uniqueness on all future writes and fails with a conflict when existing values already collide; unique is not supported for plain_text, markdown, multi_reference, image, gallery, or file fields. Pass key to rename the field’s key: the key is atomically migrated in every stored item’s data in the same transaction (no values are lost), a conflict is returned when the new key is already used in the collection, and when the website has a published version the rename is validated against the published site’s content queries. Pass position: "first" or "last", or "before" / "after" together with anchorFieldId, to move the field within the collection’s display order.

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": {
      "fieldId": "<fieldId>"
    },
    "name": "cms_fields_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyNoNew key for the field — a rename. Omit to keep the current key. Atomically migrates the key in every stored item’s `data`, so no values are lost.
configNo
exampleNo
fieldIdYes
isUniqueNo
positionNoMoves the field within the collection’s display order. Omit to leave the order unchanged. `"before"` / `"after"` require `anchorFieldId`.
requiredNo
descriptionNo
displayNameNo
anchorFieldIdNoSibling field to move against when `position` is `"before"` or `"after"`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond annotations, it discloses critical behavior: required validation against active items, uniqueness conflict behavior and unsupported field types, atomic key migration with conflict handling, published-site validation, and positioning 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 dense and front-loaded, with each clause carrying useful constraints, but the long semicolon-heavy paragraph could be easier to scan if broken into shorter statements.

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 destructive update with no output schema and low schema description coverage, it covers the important mutation and conflict behavior thoroughly; it could be slightly more complete by describing the success response or clarifying `fieldId` semantics.

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?

With only 30% schema description coverage, the description compensates well by explaining `key` rename behavior, `config` being option-field-only, `required` validation, `isUnique` restrictions, and `position`/`anchorFieldId` pairing; only trivial or obvious parameters like `fieldId` and `example` remain unelaborated.

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 uses a specific verb and resource, enumerates the mutable fields, and explicitly names immutable fields (`type` and `targetCollectionId`), making its purpose unambiguous against sibling create/delete tools.

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?

Usage is implied by the update tool name and the field-level constraints, but the description never explicitly says when to use this tool versus `cms_fields_create` or `cms_fields_delete`, nor does it name alternatives for field management decisions.

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