Skip to main content
Glama

FoxForm

by io.github.vitorrocha-panda

Update a FoxForm form

foxform_update_form
Destructive

Update an existing form's fields, including each screen's conditional logic (branching). Requires a WRITE-scoped API key. Only the fields you pass are changed.

Args:

  • form_id (string): the form to update (required)

  • title (string, optional)

  • description (string, optional)

  • theme (string, optional)

  • questions (array, optional): replaces the FULL screen list — there is no per-screen patch. To add logic to one screen: call foxform_get_form with response_format 'json', edit that screen's logic, and send the whole array back.

  • thank_you_message (string, optional)

Returns: { form } with the updated form.

Screen fields are validated: unknown fields are REJECTED instead of being stored and ignored (the API accepts arbitrary keys but no renderer reads them), then.targetScreenId must be the id of a screen in the same payload, and {{variables}} that no screen exposes come back as warnings.

CONDITIONAL LOGIC (branching), per screen — stored in questions[].logic:

logic.conditionalNavigationV2 = { enabled: true, groups: [ // groups are OR-joined; FIRST matching group wins { id: "grp-1", conditions: [ // conditions inside a group are AND-joined { id: "cond-1", left: "{{quer_testar}}", operator: "equal_to", right: "Ainda não" } ], then: { type: "specific_screen", targetScreenId: "s-motivos" } } ] }

  • then.type: 'next_screen' | 'previous_screen' | 'specific_screen' (needs targetScreenId = another screen's id) | 'end_form'. Add then.url (+ optional openNewTab) to redirect to an external URL instead.

  • operator: 'equal_to' | 'not_equal_to' | 'greater_than' | 'greater_or_equal_than' | 'less_than' | 'less_or_equal_than' | 'contains'.

  • left/right are EXPRESSION strings: a literal ("10", "Ainda não"), a variable ("{{score}}", "{{minha_var}}" = the screen's variableName), or arithmetic ("calc({{peso}}/(({{altura}}/100)*({{altura}}/100)))").

  • Comparing an ANSWER: use left: "{{<variableName of the deciding screen>}}" and right = the option's label OR its value (both match).

  • {{score}} is the running sum of points on the options picked so far (choices[].points, images[].points) — that is how score-based branching works.

  • A navigation group with no conditions NEVER matches. enabled: false stores the rules but disables them.

  • Screen-level conditional display uses the same group shape: logic.display = { enabled: true, groups: [...], showAfterSeconds?: n } (then is ignored — THEN means "show").

  • Other logic keys: logic.autoAdvance = { enabled, delaySeconds? }, logic.navigationBehavior = { onButtonClick?, onAutoAdvance?, targetScreenId? }.

  • logic.conditionalNavigation (legacy, pre-DEVF-161) is still read and migrated on load — don't author new rules with it.

Unknown fields are REJECTED (they used to be stored and silently ignored): logic as an array, or rules/branching/conditions/goto/jump/nextScreen anywhere, are not read by any renderer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
themeNo
titleNo
form_idYesForm ID
questionsNoReplaces the full screen list. Conditional logic goes in each screen's `logic` (see the tool description).
descriptionNo
thank_you_messageNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

This is exceptionally transparent beyond the annotations: it warns that questions replaces the FULL screen list with no per-screen patch, that unknown fields are REJECTED rather than silently ignored, and that enabled:false stores but disables rules. It also explains validation behavior, legacy migration, and destructive update semantics, all of which align with the destructiveHint annotation.

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 but proportionate to the tool's complexity, with a clear front-loaded purpose followed by structured sections for Args, Returns, validation, and conditional logic. Minor redundancy exists around 'unknown fields are REJECTED,' mentioned twice, which keeps it from a perfect score.

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?

Despite having no output schema and sparse schema descriptions, the description covers return shape, validation rules, auth requirements, the full conditional-logic grammar, and the safe workflow for editing one screen. An agent has enough to invoke the tool correctly and reason about edge cases.

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 only 33%, so the description carries most of the parameter burden. It clearly marks form_id as required, lists all optional fields, and gives deep semantics for questions including the full conditional logic structure. The remaining params like theme and thank_you_message are only labeled optional, but their names and schema types provide enough context.

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 opens with a specific verb and resource: 'Update an existing form's fields,' including conditional logic. It clearly distinguishes from siblings like foxform_create_form by emphasizing 'existing' and the partial-update behavior ('Only the fields you pass are changed').

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?

The description establishes clear usage context: it requires a WRITE-scoped API key, only changes provided fields, and even prescribes a workflow using foxform_get_form to retrieve and edit a screen's logic. It does not explicitly enumerate when not to use it versus create or publish tools, so it stops short of a 5.

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

All FoxForm toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool targets a distinct resource-action pair: forms vs responses vs analytics, and create/update/publish/unpublish/list/get are clearly separated. There is no overlap or ambiguity between any two tools.

Naming Consistency5/5

All tool names follow the uniform foxform_<verb>_<noun> pattern in snake_case, with clear verbs (create, get, list, update, publish, unpublish, export). The convention is perfectly consistent across the entire set.

Tool Count5/5

Ten tools is well-scoped for a form management server, covering form lifecycle, response retrieval, and analytics without redundancy or bloat. Each tool earns its place.

Completeness4/5

The server covers the full form lifecycle (create, read, update, publish, unpublish) and response viewing/export/analytics. The only notable gap is the lack of a delete operation for forms, which is a minor dead end rather than a critical failure.

Resources