Mondovo

Change a form's submission settings

update_form_settings

Idempotent

Change where a form's submissions go and what happens after one: webhook URL, success message, redirect URL, CRM contact creation, notification emails, and the automatic acknowledgement email. Only the settings you name change; the form's fields and design are not touched. A popup form stores only the webhook, success message and notifications — anything else named for one comes back in not_saved. Like any site change it reaches visitors when the site is next published. ON A SITE THAT STILL HOLDS SEVERAL DESIGNS this builds the site: Mondovo copies the chosen design into the working site (or reuses the copy made earlier), adds to that, and the response carries its new site_id and a build_transition — relay its tell_user and use the new site_id from then on. Pass variation_id for the design the user picked; omitted, Mondovo uses the design already built or the only one edited, and otherwise answers choose_design so you can ask the user.

Input Schema

Name	Required	Description
`site_id`	Yes	The site, from list_sites
`form_slug`	Yes	The form, by the slug list_forms returns
`user_goal`	No	Optional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
`webhook_url`	No	Endpoint every submission is also POSTed to. "" or null removes it.
`redirect_url`	No	Page the visitor is sent to after submitting (overrides the success message). "" or null removes it.
`variation_id`	No	variation_id of the design to read or change (from list_variations). Omit for the site's chosen design.
`create_contact`	No	Whether each submission creates or updates a CRM contact
`success_message`	No	Shown to the visitor after submitting
`notification_emails`	No	Who is emailed on each new submission. An empty list turns notifications off.
`auto_response_enabled`	No	Whether the submitter gets an automatic acknowledgement email
`auto_response_subject`	No	Subject of the acknowledgement email

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / user_goal

Added value: +{
+  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
+  "type": "string"
+}

First observedOct 19, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses partial-update semantics, the popup-form restriction and its `not_saved` return field, and the publish-gating of changes. It also explains the non-obvious side effect where changing settings on a multi-design site triggers a build, returns a new `site_id` and a `build_transition` whose `tell_user` must be relayed — exactly the kind of hidden behavior an agent could not infer from `destructiveHint: false` / `idempotentHint: true`.

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?

Front-loaded with purpose and the field list, then layered with caveats in roughly the order an agent needs them. It is dense at ~180 words and the all-caps section header is awkward, but no sentence is filler given the genuine complexity being described.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation with no output schema, the description covers the failure modes an agent must handle (`not_saved`, `choose_design`, `build_transition`, new `site_id`) and the publication side effect. Missing only permission/authorization expectations and a general note on the non-transition success response, which keeps it from a 5.

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%, so the baseline would be 3, but the description adds real meaning: `variation_id` selection logic (named design, else the built/edited one, else `choose_design`) and which settings actually persist for popup forms. It does not add format-level detail for the URL/message params, which the schema already handles.

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?

States a specific verb ('Change') and resource ('a form's submission settings') and then enumerates the exact settings covered: webhook URL, success message, redirect URL, contact creation, notifications, and acknowledgement email. An agent can immediately distinguish this from read-side siblings like get_form or list_forms.

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?

Explicitly scopes the blast radius ('Only the settings you name change; the form's fields and design are not touched') and gives conditional guidance for the multi-design case, including the variation_id fallback logic and what to do on a `choose_design` answer. It stops short of naming sibling alternatives (e.g. update_site_settings vs this tool), so it is strong but not fully comparative.

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

All Mondovo tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?