FoxForm

Create a FoxForm form

foxform_create_form

Create a new form, including per-screen conditional logic. Requires a WRITE-scoped API key.

Args:

title (string): form title (required)
description (string, optional)
theme (string, optional): one of midnight|ocean|sunset|forest|lavender|minimal (default sunset = Ember)
questions (array, optional): array of screen objects ({ id, type, title, required, variableName?, choices?, logic?, ... }); omit to start empty
thank_you_message (string, optional)

Returns: { form } with the created form (including its id and slug). The form starts as a draft — call foxform_publish_form to make it live.

Screen fields are validated: unknown fields are REJECTED instead of being stored and ignored, and branching rules are cross-checked against the screen ids in the same payload.

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

Name	Required	Description
`theme`	No	Theme key (default sunset/Ember)
`title`	Yes	Form title
`questions`	No	Screen objects; omit for an empty form. Conditional logic goes in each screen's `logic` (see the tool description).
`description`	No	Optional description
`thank_you_message`	No

Schema Changelog

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

First observedSep 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, the description discloses write-key requirements, draft creation, strict unknown-field rejection, cross-validation of branching rules, and legacy conditionalNavigation migration. None of this contradicts the annotations, and it gives the agent important behavioral expectations.

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 opening is front-loaded and the organization is clear (Args, Returns, conditional logic). It is long, but the conditional-logic complexity justifies most of the length; a small amount of redundancy around unknown-field rejection keeps it from a 5.

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 create tool with no output schema and a complex nested questions payload, the description is complete: it covers return shape, draft/publish flow, validation behavior, logic syntax, operators, score variables, and legacy migration. An agent has enough to construct a valid request.

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?

Even though schema coverage is 80%, the description adds substantial meaning: theme enum values with a default, the screen object shape, and a full conditional-logic syntax with operators, expression forms, and examples. The schema only says questions are screen objects, so this detail is valuable.

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 'Create a new form' and specifies the distinguishing capability: per-screen conditional logic. This clearly separates it from foxform_update_form, foxform_publish_form, and the read/list siblings.

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?

It states a WRITE-scoped API key is required and notes that the created form starts as a draft, directing the agent to call foxform_publish_form to make it live. It does not explicitly contrast with foxform_update_form, but 'new form' plus sibling names make the selection clear.

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

All FoxForm tools Inspect

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

Need Help?