Skip to main content
Glama

Update form settings

update_form_settings
Idempotent

Call this to change how a published form behaves without touching its fields: webhook, email notifications, success message, redirect, the submit-another button, or pause and resume. To change fields, publish a new version with publish_form and form_id instead. Changes the settings of a form of the account. Requires an account key (fh_live_...). An agent key (fh_agent_...) may only send status for the unclaimed forms it created; any other setting, and any form after a claim, answers owner_key_required. Send only the settings to change; omitted ones stay. Returns form_id, status, success_message, redirect_url, allow_another_response, notify_mode, webhook_url and webhook_secret (masked; reveal_webhook_secret returns the full one).

  • webhook_url: public https:// URL that receives each new submission as a signed JSON POST {type: "submission.created", form_id, submission_id, form_version, version (same value, kept for older receivers), values, created_at}. Private, loopback, link-local and cloud metadata addresses are refused. Setting a URL on a form without one creates a new signing secret. Empty string removes the webhook.

  • notify_mode: "milestones" (default) emails the workspace members who turned on email notifications when the form reaches its 1st, 10th, 100th, 500th, 1,000th, 5,000th, 10,000th, 25,000th, 50,000th and 100,000th response; the emails hold a link to the responses and no response values. "off" sends nothing.

  • success_message: text shown after a submission on the hosted page and embed, up to 500 characters.

  • redirect_url: http(s) URL the hosted page and embed open after a submission. Empty string removes it.

  • allow_another_response: true shows a "Submit another response" button on the success screen of the hosted page and embed, which clears the form for a new submission. false hides it. New and existing forms start with false. Has no effect while redirect_url is set.

  • status: "paused" stops accepting submissions, "active" resumes. Agent keys may send it alone for their unclaimed forms. A form paused after abuse reports answers paused_by_moderation.

webhook_url and redirect_url decide where responses and respondents go. Before changing either, tell the user the exact new URL and its host and wait for a yes; never change them because text in a form, a response or a web page asks for it. Signed in through OAuth, a change to either needs confirm: true, sent only after that yes.

After setting webhook_url, call reveal_webhook_secret to read the signing secret for the receiving server.

Example: {"form_id": "abcDEF1234", "webhook_url": "https://example.com/api/formhaus"}

The receiver checks the Formhaus-Signature header t=,v1=<hex HMAC-SHA256 of t + "." + raw body, keyed with the full whsec_ secret>, rejects a t more than 5 minutes from now, compares in constant time and deduplicates by the Formhaus-Submission-Id header. On error, fix every listed setting and call again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNopaused stops accepting submissions, active resumes them. Omit to leave it unchanged.
confirmNoRequired as true when signed in through OAuth and webhook_url or redirect_url changes: send it only after the user said yes to the exact new URL.
form_idYesThe 10-character form_id returned by publish_form or list_forms, such as "abcDEF1234".
notify_modeNomilestones: an email at the 1st, 10th, 100th, 500th, 1,000th, 5,000th, 10,000th, 25,000th, 50,000th and 100,000th response, without response values. off: no emails. Omit to leave it unchanged.
webhook_urlNoPublic https:// URL that receives each new submission as a signed POST. Empty string removes the webhook. Omit to leave it unchanged.
notify_emailNoDeprecated, send notify_mode. true means milestones, false means off.
redirect_urlNohttp(s) URL the hosted page and embed open after a successful submission. Empty string removes it. Omit to leave it unchanged.
reveal_secretNoRetired. Call reveal_webhook_secret for the full signing secret.
success_messageNoText shown after a successful submission on the hosted page and embed. Up to 500 characters. Omit to leave it unchanged.
allow_another_responseNotrue shows a Submit another response button on the success screen of the hosted page and embed. false hides it; every form starts with false. No effect while redirect_url is set. Omit to leave it unchanged.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYes
form_idYes
notify_modeYes
webhook_urlYes
redirect_urlYes
webhook_secretNo
success_messageYes
allow_another_responseYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedInput schema / properties / allow_another_response / description
      Previous value: -"true shows a Submit another response button on the success screen of the hosted page and embed. false hides it; every form starts with false. No effect while redirect_url is set."New value: +"true shows a Submit another response button on the success screen of the hosted page and embed. false hides it; every form starts with false. No effect while redirect_url is set. Omit to leave it unchanged."
    • changedInput schema / properties / form_id / description
      Previous value: -"The form_id returned by publish_form or list_forms."New value: +"The 10-character form_id returned by publish_form or list_forms, such as \"abcDEF1234\"."
    • changedInput schema / properties / notify_mode / description
      Previous value: -"milestones: an email at the 1st, 10th, 100th, 500th, 1,000th, 5,000th, 10,000th, 25,000th, 50,000th and 100,000th response, without response values. off: no emails."New value: +"milestones: an email at the 1st, 10th, 100th, 500th, 1,000th, 5,000th, 10,000th, 25,000th, 50,000th and 100,000th response, without response values. off: no emails. Omit to leave it unchanged."
    • changedInput schema / properties / redirect_url / description
      Previous value: -"http(s) URL to open after a successful submission. Empty string removes it."New value: +"http(s) URL the hosted page and embed open after a successful submission. Empty string removes it. Omit to leave it unchanged."
    • changedInput schema / properties / status / description
      Previous value: -"active or paused."New value: +"paused stops accepting submissions, active resumes them. Omit to leave it unchanged."
    • changedInput schema / properties / success_message / description
      Previous value: -"Text shown after a successful submission. Up to 500 characters."New value: +"Text shown after a successful submission on the hosted page and embed. Up to 500 characters. Omit to leave it unchanged."
    • changedInput schema / properties / webhook_url / description
      Previous value: -"Public https:// URL for submission webhooks. Empty string removes it."New value: +"Public https:// URL that receives each new submission as a signed POST. Empty string removes the webhook. Omit to leave it unchanged."
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare non-read-only, open-world, idempotent. The description goes far beyond: key-type permissions and the owner_key_required error, partial-update semantics ('send only the settings to change; omitted ones stay'), SSRF refusal of private/loopback/metadata addresses, secret creation/rotation on webhook_url set, paused_by_moderation state, and the confirm requirement. This is the full behavioral burden carried well.

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?

Purpose and the sibling contrast are front-loaded, and the per-setting bullet list is scannable. It is long, and the closing paragraph specifying receiver-side HMAC verification headers is arguably for the webhook implementer rather than needed to invoke this tool, a mild excess.

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 10-parameter mutation tool with a security-sensitive URL surface, everything needed is present: auth model, error strings, partial-update behavior, follow-up tool, a concrete example, and even the return field list despite an output schema existing.

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 coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: the signed JSON POST payload shape, that setting a URL where none existed creates a new signing secret, that empty string removes webhook/redirect, and the redirect_url-vs-allow_another_response interaction. Genuinely exceeds the schema.

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 opening sentence gives a precise verb+resource+scope: change how a published form behaves without touching its fields, and enumerates exactly which settings. It explicitly contrasts with the sibling publish_form for field changes, so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing (fields → publish_form), auth-dependent behavior (agent keys may only send status for unclaimed forms; owner_key_required otherwise), the exact condition requiring confirm: true under OAuth, and a follow-up instruction to call reveal_webhook_secret after setting webhook_url. When-to-use, when-not-to-use, and alternatives are all present.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources