Skip to main content
Glama

Update form

update_form
Destructive

Change a form's title, description, questions or settings. Call get_form first so you send the complete question list — "fields" replaces the whole array, it does not merge.

You may add questions, reorder them, and edit any label, help text, required flag, options or validation. Questions are required unless you set required to false — except a rating, which is optional unless you set it to true. "required": false — confirm with the person before making a question required that not everyone can answer. You may not make a question's "key" disappear: keys are how answers already collected are identified, so renaming one would silently change what past answers mean. To rename, add a new question and leave the old one. To genuinely delete a question, list its key in "remove_fields" so the deletion is deliberate.

Changing the questions creates a new version; existing responses stay pinned to the version they were answered against. To open or close a form use set_form_status instead.

Settings merge, so send only the ones that change. To lock a form behind a password set "settings.password"; to add payment buttons to the thank-you page set "settings.payment_links". Send null and [] to remove them.

Input Schema

NameRequiredDescriptionDefault
titleNo
fieldsNo
form_idYesThe form id from create_form or list_forms, or the slug from its share link (the part after /f/).
settingsNo
descriptionNo
remove_fieldsNo

Output Schema

NameRequiredDescriptionDefault
idNo
refusedNo
versionNo
version_createdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / refused
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "message": {
      +      "type": "string"
      +    },
      +    "reason": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "reason",
      +    "message"
      +  ],
      +  "type": "object"
      +}
    • removedOutput schema / required
      Removed value: -[
      -  "id",
      -  "version",
      -  "version_created"
      -]
  2. Changed4 schema fields changed
    • addedOutput schema / additionalProperties
      Added value: +false
    • removedOutput schema / anyOf
      Removed value: -[
      -  {
      -    "additionalProperties": false,
      -    "properties": {
      -      "id": {
      -        "type": "string"
      -      },
      -      "version": {
      -        "type": "number"
      -      },
      -      "version_created": {
      -        "type": "boolean"
      -      }
      -    },
      -    "required": [
      -      "id",
      -      "version",
      -      "version_created"
      -    ],
      -    "type": "object"
      -  },
      -  {
      -    "additionalProperties": false,
      -    "properties": {
      -      "refused": {
      -        "additionalProperties": false,
      -        "properties": {
      -          "message": {
      -            "type": "string"
      -          },
      -          "reason": {
      -            "type": "string"
      -          }
      -        },
      -        "required": [
      -          "reason",
      -          "message"
      -        ],
      -        "type": "object"
      -      }
      -    },
      -    "required": [
      -      "refused"
      -    ],
      -    "type": "object"
      -  }
      -]
    • addedOutput schema / properties
      Added value: +{
      +  "id": {
      +    "type": "string"
      +  },
      +  "version": {
      +    "type": "number"
      +  },
      +  "version_created": {
      +    "type": "boolean"
      +  }
      +}
    • addedOutput schema / required
      Added value: +[
      +  "id",
      +  "version",
      +  "version_created"
      +]
  3. Changed4 schema fields changed
    • removedOutput schema / additionalProperties
      Removed value: -false
    • addedOutput schema / anyOf
      Added value: +[
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "id": {
      +        "type": "string"
      +      },
      +      "version": {
      +        "type": "number"
      +      },
      +      "version_created": {
      +        "type": "boolean"
      +      }
      +    },
      +    "required": [
      +      "id",
      +      "version",
      +      "version_created"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "refused": {
      +        "additionalProperties": false,
      +        "properties": {
      +          "message": {
      +            "type": "string"
      +          },
      +          "reason": {
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "reason",
      +          "message"
      +        ],
      +        "type": "object"
      +      }
      +    },
      +    "required": [
      +      "refused"
      +    ],
      +    "type": "object"
      +  }
      +]
    • removedOutput schema / properties
      Removed value: -{
      -  "id": {
      -    "type": "string"
      -  },
      -  "version": {
      -    "type": "number"
      -  },
      -  "version_created": {
      -    "type": "boolean"
      -  }
      -}
    • removedOutput schema / required
      Removed value: -[
      -  "id",
      -  "version",
      -  "version_created"
      -]
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the destructive/openWorld annotations: 'fields' replaces the whole array rather than merging, settings do merge, removals must be deliberate via remove_fields, keys cannot be renamed because past answers are keyed on them, and editing questions creates a new version with existing responses pinned to the old one. These are exactly the mutation semantics an agent cannot infer from structured fields.

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 core action and the critical non-merge warning, and every subsequent paragraph carries distinct operational information. It is dense and slightly run-on in places, but no sentence is filler.

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?

An output schema exists so return values need no explanation, and the annotations already flag the destructive/open-world nature; the description supplies the versioning, merge, and deletion semantics that a mutation tool of this complexity needs. Nothing required to call it correctly appears to be 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 description coverage is only 17%, so the description must compensate and largely does: it defines the replace-vs-merge behaviour of fields and settings, the role of remove_fields, required-flag defaults (including the rating exception), and null/[] for clearing password and payment_links. It still leaves the inner field object (type enum, options, validation, visible_when) largely to the schema, so it is not fully compensating.

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 (Change) and resource (a form) plus the exact surfaces it touches: title, description, questions, settings. It also differentiates from siblings by naming get_form and set_form_status as the tools for reading and for open/close, so an agent can route without opening schemas.

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?

Explicitly instructs 'Call get_form first so you send the complete question list' and routes open/close to set_form_status. It also gives a when-not rule (do not make a question required without confirming) and prescribes the alternative workflows for renaming (add new + leave old) and deleting (list key in remove_fields).

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