Skip to main content
Glama

FoxForm

by app.foxform.mcp

Update a FoxForm form

foxform_update_form

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

TDQS

A4.7/5.0
Behavior5/5

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

The description goes far beyond the annotations by disclosing partial-update semantics, full replacement of questions, validation rejection, warnings for unresolved variables, legacy logic migration, and detailed conditional-navigation behavior. It also states the authentication requirement, which is not in the annotations. There is no contradiction with readOnlyHint=false or idempotentHint=false.

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 well-structured, with an Args section, return value, validation notes, and a dedicated CONDITIONAL LOGIC section. It is front-loaded with the most important behavioral facts. Some minor redundancy exists around unknown fields being rejected, mentioned both before and after the conditional logic section, but every part contributes to correct invocation of a complex tool.

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 and the absence of an output schema, the description is remarkably complete: it covers parameters, return shape, validation rules, operator alternatives, expression syntax, display logic, auto-advance, legacy behavior, and error-prone edge cases. An agent has enough information to construct valid update payloads and avoid common failure modes.

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?

Schema description coverage is only 33%, but the description compensates fully by explaining every parameter in the Args block. The questions parameter receives especially rich semantics: it replaces the FULL screen list, has no per-screen patch, and includes detailed structure for conditional logic. It also adds meaning to theme, title, description, and thank_you_message beyond their raw schema types.

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 each screen's conditional logic (branching).' This clearly identifies the tool's action and distinguishes it from create/get/export/list/publish/unpublish siblings. The requirement of a WRITE-scoped API key further clarifies the operation type.

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 gives clear context for use: updating an existing form, requiring a WRITE-scoped key, and only changing passed fields. It also explicitly routes to foxform_get_form for partial edits ('To add logic to one screen: call foxform_get_form...'). It does not explicitly contrast with foxform_create_form, but 'existing form' plus sibling names make the distinction clear.

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.4/5.0
Disambiguation5/5

Each tool pairs a unique action with a unique resource: forms have create/get/update/list/publish/unpublish, responses have list/get/export, and analytics is separate. The only near-overlap (export vs list responses) is explicitly differentiated by truncation and pagination.

Naming Consistency5/5

All tool names share the foxform_ prefix and follow a strict verb_noun pattern (create_form, list_responses, publish_form). No mixed casing or synonym verbs create ambiguities.

Tool Count5/5

Ten tools is a well-scoped surface for a form management API: form lifecycle, response access, and analytics each have dedicated operations. None feel redundant, and the count stays comfortably within the ideal range.

Completeness4/5

The core form lifecycle is covered: create, read, update, publish, unpublish, and list. The only notable gap is delete_form (and no response deletion/update), which agents can work around but is still a real missing lifecycle op.

Resources