Skip to main content
Glama

update_form_logic

DestructiveIdempotent

Replace a form draft’s logic document with the given calculations — the ONLY valid logic structure; any other shape is stored but silently ignored by the engine and invisible in the builder. A calculation runs on every change of the submission: when every conditions[].expression is true, the then effects apply; otherwise the otherwise effects. Expression syntax (identical for field formulas): field references MUST be wrapped in backticks and text values quoted — amount > 1000, region = "west" AND age >= 18. Bare identifiers are rejected. Functions: MAX, MIN, ROUND, ABS, FLOOR, CEIL, and for multi-value/composite fields CONTAINS(group, "option") (membership; substring on text; any cell of a table's rows), CONTAINS(table, "column", "value") (membership in one column), COUNT(group) (items or table rows), SUM(table, "column") or SUM(list), PART(address, "city") (absent parts are ""), ISBLANK(field) (true while the field has no answer; the one function tolerant of a missing reference — use it for is-empty/is-filled conditions, with = FALSE for filled). No others. Effect operators: VARIABLE {target, expression} computes into a field slug; SHOW/HIDE {fields: [slugs]} for rule-driven visibility (the static field property visible is separate); FUNCTION {target, function e.g. FORMAT_TO_CURRENCY, fields: [source slug]}; SET_OUTCOME {target, message?, severity?}; SET_WORKFLOW_STATE {target}; SEND {notification, documents?, emails?}; REFERENCE_NUMBER {target, generator: sequence slug}; SEND_TO_ZAPIER {connection: slug of a connection the organization configured under Settings → Integrations — NOT a URL, and you cannot create connections; queued only when a submission actually saves, never on previews}; COLLECT_PAYMENT {payment: {amountExpression: formula for the total, currency?, description?, recipients: [{account: payment-account slug from Settings → Payments, percent? XOR amountExpression?}]} — at most ONE per form; amounts are always priced server-side and the customer pays before the submission lands}; DELIVER_OBJECT {objects: [numeric ids from list_objects]} — hands the submitter the named library files through a per-submission download link (and a {{download_link}} merge value in notification templates); when the form also collects a payment the files unlock only after it succeeds, automatically. SEND.emails entries may be literal addresses or the recipient descriptors assignee|owner|creator|field: — field: is how an anonymous submitter’s own address is reached. Slugs come from get_form_fields; read get_form_logic first because this replaces the whole document. To change or delete individual calculations on a form that already has logic, prefer patch_form_logic — it applies a diff and cannot drop the calculations you did not mention. Requires form:write.

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": {
      "formId": "<formId>",
      "calculations": "<calculations>"
    },
    "name": "update_form_logic"
  }
}

Input Schema

NameRequiredDescriptionDefault
formIdYesThe form id.
calculationsYesThe complete list of calculations for this form.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Goes far beyond the annotations (readOnlyHint=false, destructiveHint=true) by detailing silent storage of invalid shapes, expression syntax, function constraints, effect operators, and special behaviors like SEND_TO_ZAPIER only queuing on actual saves and COLLECT_PAYMENT being limited to one per form. No contradiction with annotations.

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 long and dense, but every sentence contributes critical information for a complex DSL. It is front-loaded with the most important caveat about the only valid structure. Slightly less concise due to the single-paragraph format, but justifiably detailed.

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?

Given the tool's complexity, minimal schema, and no output schema, the description is exceptionally complete. It covers all effect types, functions, edge cases, permissions, and cross-tool references, leaving nothing essential for correct invocation unexplained.

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?

While schema coverage is 100%, the description adds extensive meaning to parameters: it explains the structure of calculations, conditions, then/otherwise effects, and the full DSL for expressions and operators, far exceeding the minimal schema descriptions.

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 clearly states it replaces the form draft's logic document with the provided calculations, naming the resource and action. It also differentiates from siblings by emphasizing it is the ONLY valid logic structure and later contrasts with patch_form_logic.

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 to read get_form_logic first and to prefer patch_form_logic for partial changes, providing clear when-to-use vs. alternative guidance. Also notes the permission requirement (form:write).

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