Skip to main content
Glama

update_field

Destructive

Update one custom field on a checkout page, form, or event: label, element, type, options, required, hidden, disabled, default value, visibility rules and more. Only supplied properties change; options are replaced wholesale. Set disabled: true to switch a field off without deleting it (the customer email field cannot be disabled). Get field IDs from get_checkout_page, get_form, or get_event. Mutating. formLayout on the page decides the form's order. Each field's order is its position among the page's fields and follows the layout: saving a layout (in the dashboard or through the API) rewrites every field's order. On a page that has never saved a layout, setting order moves the field; once a layout is saved, move fields with formLayout instead.

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": {
      "pageId": "<pageId>",
      "pageType": "<pageType>",
      "fieldId": "<fieldId>"
    },
    "name": "update_field"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeNoUsed to store field data in a predictable manner. Please note that you must use Customer Name and Shipping Address if you wish to use any of the shipping address data types. Do not set `type` when `element` is one of: `checkbox`, `quantity`, `tax-id`, `po-number`, `multiple-choice`, `multi-select`, `date-time`, `date`, `time`, `textarea`.
labelNoForm label for the input element.
orderNoPosition of this field among the page's fields, from 0. When omitted, a new field goes after the current ones, or follows its position in `fields` when a page is created. `formLayout` on the page decides the form's order. Each field's `order` is its position among the page's fields and follows the layout: saving a layout (in the dashboard or through the API) rewrites every field's `order`. On a page that has never saved a layout, setting `order` moves the field; once a layout is saved, move fields with `formLayout` instead.
hiddenNoWhether this field is hidden from customers at checkout.
layoutNoHow a multi-select field is drawn at checkout: `dropdown` (the default) or `list`, a list of checkboxes. Ignored on other elements.
pageIdYesThe ID of the page the field belongs to.
collectNoWhether to collect only a billing address or both billing and shipping. Applies to `address` elements. Defaults to `billing`.
elementNoInput control used to render this field in checkout. Defaults to `text`.
fieldIdYesThe ID of the field. Field IDs are listed under `fields` in the page detail response from get_checkout_page, get_form, or get_event.
optionsNoSelectable options for `select`, `multi-select` and `multiple-choice` elements. Replaced wholesale: every option gets a new ID, so re-point any other field whose showHideLogic references one of these options afterwards. Options on a `multi-select` need different values (an option without a value uses its label), and options on a `multiple-choice` need different labels.
disabledNoWhether this field is switched off. A disabled field keeps its settings but is removed from the page entirely: it is not rendered, cannot be revealed with `show_fields`, is not prefilled and is never submitted.
maxValueNoMaximum allowed value settings for this field.
minValueNoMinimum allowed value settings for this field.
pageTypeYesThe kind of page the field belongs to: `checkout`, `form`, or `event`. Use the type of the tool you fetched the page with (get_checkout_page, get_form, get_event).
requiredNoWhether this field must be completed before checkout can continue.
referenceNoStable key that exports, Zapier, Google Sheets and webhooks use for this field's answers. Generated from the field type or label when omitted, and not updated when the label changes. Changing it breaks integrations that match on the old key, so only send it when the seller asks.
descriptionNoOptional helper text shown below the field label.
placeholderNoSpecifies a short hint that describes the expected value of an input element
defaultValueNoDefault value settings for the field.
showHideLogicNoConditional visibility rules for this field. `element.elementId` must be the ID of another field on the same page, and `value` an option ID on that field (or `TRUE`/`FALSE` for a checkbox). Read the IDs from the page detail response; create-time keys are rejected here.
defaultCountryNoISO 3166-1 alpha-2 country code used as the default for `address` elements. Defaults to `US`.
collectShippingPhoneNoWhether to collect a phone number alongside the shipping address. Applies to `address` elements when `collect` is `billing_and_shipping`. Defaults to `false`.
showSelectedDialCodeNoWhether to display the selected international dial code in phone inputs.
limitAllowedCountriesNoCountry restriction settings for country-based fields.
limitBillingCountriesNoRestrict the billing country list. Applies to `address` elements.
limitShippingCountriesNoRestrict the shipping country list. Applies to `address` elements when `collect` is `billing_and_shipping`.

Output Schema

NameRequiredDescriptionDefault
dataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / reference / description
      Previous value: -"External reference ID for integration purposes. Generated from the field type or label when omitted."New value: +"Stable key that exports, Zapier, Google Sheets and webhooks use for this field's answers. Generated from the field type or label when omitted, and not updated when the label changes. Changing it breaks integrations that match on the old key, so only send it when the seller asks."
    • changedOutput schema / $defs / Field / properties / reference / description
      Previous value: -"External reference ID for mapping this field in downstream systems."New value: +"Stable key that exports, Zapier, Google Sheets and webhooks use for this field's answers. Not updated when the label changes."
  2. Changed2 schema fields changed
    • changedInput schema / properties / order / description
      Previous value: -"Display order of this field. When omitted, order is determined by the position of the field in the array."New value: +"Position of this field among the page's fields, from 0. When omitted, a new field goes after the current ones, or follows its position in `fields` when a page is created. `formLayout` on the page decides the form's order. Each field's `order` is its position among the page's fields and follows the layout: saving a layout (in the dashboard or through the API) rewrites every field's `order`. On a page that has never saved a layout, setting `order` moves the field; once a layout is saved, move fields with `formLayout` instead."
    • changedOutput schema / $defs / Field / properties / order / description
      Previous value: -"Display order of the field within the form."New value: +"Position of the field among the page's fields, from 0. `formLayout` on the page decides the form's order. Each field's `order` is its position among the page's fields and follows the layout: saving a layout (in the dashboard or through the API) rewrites every field's `order`. On a page that has never saved a layout, setting `order` moves the field; once a layout is saved, move fields with `formLayout` instead."
  3. Changed2 schema fields changed
    • addedInput schema / properties / disabled
      Added value: +{
      +  "description": "Whether this field is switched off. A disabled field keeps its settings but is removed from the page entirely: it is not rendered, cannot be revealed with `show_fields`, is not prefilled and is never submitted.",
      +  "example": false,
      +  "type": [
      +    "boolean",
      +    "null"
      +  ]
      +}
    • addedOutput schema / $defs / Field / properties / disabled
      Added value: +{
      +  "description": "Whether this field is switched off. A disabled field keeps its settings but is removed from the page entirely.",
      +  "example": false,
      +  "type": [
      +    "boolean",
      +    "null"
      +  ]
      +}
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Despite annotations already flagging destructiveHint and openWorldHint, the description adds real behavior: only supplied properties change (PATCH semantics), options are replaced wholesale so showHideLogic references break, the customer email field cannot be disabled, and changing `reference` breaks Zapier/webhook integrations. The disabled-field consequences (not rendered, not prefilled, never submitted) are exactly the kind of blast-radius detail annotations cannot express.

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: purpose, then partial-update semantics, then the disabled switch, then ID sourcing, then mutability. The closing order/formLayout paragraph is long and repeats the schema's `order` text nearly verbatim, which is the main redundancy; otherwise every sentence carries 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?

For a 26-parameter mutation tool with an output schema and annotations in place, the description covers what the schema cannot: partial-update semantics, destructive side effects on options and references, the email-field exception, and the layout/ordering interaction. Nothing an agent needs in order to call it safely is missing.

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 100%, so baseline is 3; the description still adds meaning, notably 'Only supplied properties change' (partial-update contract not obvious from a non-required schema), the wholesale options replacement warning, and the email-field constraint that appears nowhere in the schema. The order/formLayout guidance largely duplicates the schema's own `order` description, which caps it below 5.

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?

Specific verb plus resource and scope: 'Update one custom field on a checkout page, form, or event,' followed by an enumeration of the mutable properties. The phrase 'Set disabled: true to switch a field off without deleting it' implicitly steers the agent away from delete_field, and 'Get field IDs from get_checkout_page, get_form, or get_event' points at the read siblings, so an agent can place it among the 70+ siblings 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?

Gives concrete routing: fetch IDs from get_checkout_page/get_form/get_event, and use formLayout (not order) to move fields once a layout exists. Also warns to only send `reference` when the seller asks. It states context clearly but offers no explicit 'do not use this for X' exclusions, e.g. creating a new field belongs to create_field.

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