Skip to main content
Glama

Update variables

update-variables-tool
Destructive

Replace a form's custom variables — named values that logic rules read and write (scores, prices, outcome tallies). Pass the COMPLETE custom list from list-logic-options-tool, excluding entries with built_in true. Names use letters, numbers and underscores only; type is "number" (starts at 0) or "text" (starts empty). Built-in and field names are reserved. Create every variable BEFORE referencing it in set-block-logic-tool. Changes apply to the live form immediately. To remove or change the type of a variable in use, remove its references from the draft and publish first.

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": {
      "form_slug": "<form_slug>",
      "variables": "<variables>"
    },
    "name": "update-variables-tool"
  }
}

Input Schema

NameRequiredDescriptionDefault
form_slugYesThe form's slug.
variablesYesThe complete list of variables, e.g. [{"name": "lion", "type": "number"}, {"name": "owl", "type": "number"}]. Pass an empty array to remove all custom variables.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the mutation and destructive annotations, it discloses full-list replacement semantics, immediate application to the live form, initial values for each type, and special constraints on removing or retyping referenced variables. These details make both the destructive scope and timing of changes clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description front-loads the operation and replacement semantics, then packs validation, defaults, ordering, and safety requirements into short purposeful sentences. It is dense but contains no filler or unnecessary repetition of the schema example.

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 destructive two-parameter mutation, it covers what to pass, how to construct valid entries, prerequisite sibling-tool calls, live-form effects, and the exceptional removal and retyping workflow. No critical selection or invocation information is notably absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds substantial meaning: the list source, the built_in exclusion, allowed name characters, reserved names, valid types, and their starting values. This goes well beyond the schema's parameter summaries and example.

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?

“Replace a form's custom variables” states the exact operation, resource, and full-replacement scope. Explaining that these named values are read and written by logic rules, with examples such as scores and prices, further distinguishes the tool from logic-editing and hidden-field siblings.

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?

It gives an explicit workflow: obtain the complete custom list from list-logic-options-tool, exclude built-in entries, and create variables before referencing them in set-block-logic-tool. It also provides the required procedure for removing or retyping an in-use variable, including removing draft references and publishing first.

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.