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 { form, public_url }: the full form object (id, title, description, slug, status, theme, questions[], thank_you_message, timestamps) plus public_url — the public link (https://forms.foxform.app/<slug>), which is live only when status is 'published'. Use public_url verbatim; never build the URL yourself (the public domain is forms.foxform.app, not foxform.app). 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

Schema Changelog

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

First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds substantial behavioral context beyond that: public_url is only live when status is 'published', URLs must not be hand-built, markdown summarizes logic while json exposes exact stored objects, unknown fields are rejected, and legacy conditionalNavigation is migrated on load. These details meaningfully affect how an agent should interpret and use the result.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but meticulously structured: a one-sentence summary, Args, Returns, then clearly labeled conditional-logic detail. Every section earns its place because the returned object is complex and the logic semantics are non-obvious. The most important operational caveats (public_url, response_format, unknown-field rejection) are front-loaded before the deep-dive.

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 must carry the full burden of explaining the return shape. It does so thoroughly: the top-level form object fields, public_url behavior, questions[] structure, logic object shapes, operators, expression semantics, score mechanics, and legacy fields. An agent can call this tool and correctly consume nearly any response without additional documentation.

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 100%, the description enriches both parameters. It tells the agent that form_id comes from foxform_list_forms, and it explains the practical difference between response_format values: markdown summarizes every rule, while json returns exact stored objects matching what foxform_update_form expects. This goes beyond the schema's terse 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 opens with a specific verb and resource: 'Fetch a single form by ID, including its full question list, per-screen conditional logic and settings.' This clearly distinguishes from sibling tools like foxform_list_forms and foxform_get_form_analytics. It also names the source of form_id (foxform_list_forms), reinforcing the tool's exact role.

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 provides clear context: use this tool to retrieve a single full form by ID, and it points users to foxform_list_forms for obtaining valid IDs. It also explains when to choose 'markdown' vs 'json', noting that json returns the exact stored shape that foxform_update_form expects. It does not explicitly state when-not-to-use it relative to analytics or export tools, so it falls just 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 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?