FoxForm

Get a FoxForm form

foxform_get_form

Read-onlyIdempotent

Fetch a single form by ID, including its full question list, per-screen conditional logic and settings.

Args:

form_id (string): the form's ID (from foxform_list_forms)
response_format ('markdown' | 'json')

Returns the full form object (id, title, description, slug, status, theme, questions[], thank_you_message, timestamps). Each screen in questions[] carries its own logic (branching / conditional display) and, for choice screens, choices[]/images[] with their points and value. The markdown output summarises every rule; use response_format 'json' to get the exact stored objects (that's the shape foxform_update_form expects back).

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	Default
`form_id`	Yes	Form ID
`response_format`	No	Output format: 'markdown' (human-readable) or 'json' (machine-readable)	markdown

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already mark this as read-only and idempotent, and the description adds substantial behavioral detail: conditional logic semantics (OR/AND joins, first match wins), expression evaluation, score accumulation, legacy conditionalNavigation migration, and rejection of unknown fields. This goes far beyond what the annotations or schema convey.

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 clear sections, a code example, and a front-loaded purpose statement. It contains some unavoidable detail because conditional logic is complex, though it could be slightly tightened without losing value.

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?

There is no output schema, so the description carries the burden of explaining the return value. It lists the full form object fields, describes the questions[] array, choices/images points, and thoroughly documents conditional logic and response_format differences. This is sufficient for an agent to call the tool and interpret its output correctly.

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 100% and already documents both parameters, so the baseline is 3. The description adds real meaning by explaining that form_id is obtained from foxform_list_forms and that response_format='json' returns the exact shape expected by foxform_update_form. This exceeds the schema's minimal 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 first sentence states a specific verb and resource: 'Fetch a single form by ID', and enumerates the exact contents returned: 'full question list, per-screen conditional logic and settings'. This clearly distinguishes it from list_forms (which lists forms), get_form_analytics (analytics), and update_form (mutation).

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 usage context: form_id comes from foxform_list_forms, and response_format 'json' is recommended when the exact stored object shape is needed for foxform_update_form. It does not explicitly state when to avoid this tool in favor of a sibling, but the context is clear enough for correct selection.

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.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

Need Help?