Skip to main content
Glama

set_field

Idempotent

Update a single content field in a draft using a plain string. This method ensures long text or Markdown survives client serialization without data corruption.

Instructions

Write ONE field of an item's draft as a plain string; the other fields are kept. It is the safest way to send long text or Markdown, because a flat string survives client serialization that can mangle long strings nested in update_content's data. field is a text, markdown, select, datetime or image field from list_content_types {name} (an image takes an asset documentId), or name for the item's display name; value is the field's whole new value. For richtext, contentArea or reference fields, or several fields at once, use update_content. A value the field can't take is refused with the expected shape and an example; text in another language than the locale branch is refused unless allowLanguageMismatch. Like any agent edit, it cancels a pending scheduled publish. Returns the saved draft in the get_content shape; publish_content separately. Requires the content.update permission (Admin, Editor, Author — an Author only within their own sections).

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": {
      "documentId": "<documentId>",
      "field": "<field>",
      "value": "<value>"
    },
    "name": "set_field"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteNoSite slug or id to act in (multisite). Omit to use this server's default site. Call list_sites to see what exists — an empty tree or search usually means the wrong site, not missing content.
fieldYesField name from the content type (or 'name')
valueYesThe plain string value
localeNoLocale code. Omit for the document's own locale (its site-default variant, else its only variant).
documentIdYesThe item's documentId (stable across locales and versions), e.g. from list_tree, list_content or get_content.
allowLanguageMismatchNoSet true ONLY to deliberately write text whose language differs from the locale branch (the guard otherwise refuses, so e.g. Norwegian text can't silently land on the 'en' branch)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.4
    • changedInput schema / properties / documentId / description
      Previous value: -"The item's documentId (stable across locales and versions), e.g. from tree, list_pages or get_content."New value: +"The item's documentId (stable across locales and versions), e.g. from list_tree, list_content or get_content."
  2. Changed1 schema field changedv0.1.3
    • changedInput schema / properties / documentId / description
      Previous value: -"Content documentId"New value: +"The item's documentId (stable across locales and versions), e.g. from tree, list_pages or get_content."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover only idempotency/safety flags, and the description adds substantial behavior beyond them: it cancels a pending scheduled publish, refuses invalid values with expected shape and example, refuses language mismatches by default, and states the required content.update permission plus the Author-scoped caveat.

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?

Dense but front-loaded: the core action and its safety rationale lead, then alternatives, then side effects and permissions. Six sentences is on the long side, though nearly every clause carries actionable information an agent needs.

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?

With no output schema, the description still closes the loop by saying it returns the saved draft in the get_content shape and that publishing is a separate call. Permissions, refusal behavior, and scheduling side effects are all covered for a mutation tool.

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 already 100%, so the baseline is 3, but the description adds real meaning: which field kinds are legal (text/markdown/select/datetime/image from list_content_types) or 'name', that an image takes an asset documentId, that value is the field's whole new value, and the allowLanguageMismatch guard behavior.

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 precise verb+resource+scope: 'Write ONE field of an item's draft as a plain string; the other fields are kept.' It immediately distinguishes itself from update_content by naming that sibling and the cases it doesn't cover (richtext, contentArea, reference, multiple fields).

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

Usage Guidelines5/5

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

Explicit routing: use this for long text/Markdown because a flat string survives client serialization, and use update_content for richtext/contentArea/reference fields or several fields at once. It also notes when allowLanguageMismatch is needed and that publish_content is separate.

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