Skip to main content
Glama

Update form settings

formSettings_update

Update form settings. Only provide fields to change. Use this for form BEHAVIOR — email notifications, scheduling/limits, redirects. For the form's name/folder/cover/logo use form_update; for colors/fonts/visual theme use formTheme_set; for questions and content use the editor_* tools.

Three independent email flows: self-notification (form owner/team on submit), respondent notification (confirmation to respondent), respondent reminder (when respondent abandons mid-form, Pro tier). Each is gated by its own *Enabled flag and accepts a custom subject + body. Respondent-targeted flows require *To to point at an email-input field ID (find via editor_getDocument).

Localization: customizing a respondent confirmation/reminder subject or body makes it translatable — the keys appear in translationDraft_get immediately (no form publish needed); localize via translationDraft_get → translationDraft_update. Self-notification (owner) emails are NOT translatable; write them directly in the target language here.

Custom From domain: pass emailDomainId from formSettings_get → availableEmailDomains; null resets to noreply@formbase.so.

{{variable}} placeholders for subjects/bodies: {{email.formName}} - Form name {{email.submittedAt}} - Submission date/time {{email.submissionId}} - Submission ID {{email.submissionType}} - "New", "Updated", or "Partial" {{metadata.formId}} - Form ID {{metadata.authorizedEmail}} - Respondent email (if auth enabled) {{metadata.pin4}} - 4-digit PIN per submission {{metadata.pin6}} - 6-digit PIN per submission {{metadata.code4}} - 4-char code per submission {{metadata.code6}} - 6-char code per submission Plus any answer by its field key: {{}} (the key fields_list shows and requests, callbacks and submissions use; the input node id from form_get questions[].id also works). Keys read back as {{}}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formIdYesForm ID to update settings for
languageNoBCP-47 language tag (e.g. "en", "en-US", "pt-BR"). Defaults to "en".
maxEditsNoMax post-submit edits allowed per submission (requires editAfterSubmit). 0 = unlimited; max 3.
passwordNoForm access password (≥4 chars). Setting a string implies passwordEnabled:true. Pass null to clear the gate (sets passwordEnabled:false).
redirectUrlNohttp(s) URL respondents land on after submission. null or empty string clears. Mutually exclusive with allowAnotherResponse:true.
showBrandingNoShow formbase branding on the form.
emailDomainIdNoVerified email domain ID for custom From address. Read availableEmailDomains from formSettings_get for valid IDs. null resets to default.
reminderStepsNoReminder schedule as idle offsets from the respondent's last activity, e.g. ["1d","3d","1w"]. Max 5 steps, sorted and deduped on save; [] = no automatic reminders. Applies to both abandoned public-link responses and requests.
captchaEnabledNoEnable Turnstile bot protection.
editAfterSubmitNoAllow respondents to edit a submission after sending.
passwordEnabledNoGate form with a password. Auto-set to true when `password` is provided. Setting true requires a stored password.
draftRetentionDaysNoDays to keep abandoned drafts (0–36500). null reverts to runtime default.
notificationEmailsNoEmail addresses receiving submission notifications. At most 10; duplicates are collapsed case-insensitively.
notifyOnSubmissionNoEmail form owner/team on new submissions.
redirectQueryParamsNoMap form field values as query parameters on the redirect URL. Each entry maps a URL param name to a field ID.
allowAnotherResponseNoAfter submitting, loop respondents back to a fresh empty form. Mutually exclusive with a non-empty redirectUrl.
pdfGenerationEnabledNoAttach submission PDF to self-notification emails.
respondentReminderToNoField ID of an email-type question. Set to null to clear.
requireAuthenticationNoRequire respondents to be logged in.
respondentReminderBodyNoCustom body for the reminder email. Plain text with optional {{variable}} placeholders; newlines become paragraphs.
selfNotificationSubjectNoCustom subject for self-notification emails. Plain text with optional {{variable}} placeholders.
submissionRetentionDaysNoDays to keep submissions (0–36500). null reverts to runtime default. Setting a value also clears any fixed deletion date configured in the form builder (the two retention modes are mutually exclusive). Business plan.
respondentNotificationToNoField ID of an email-type question. Respondent email is extracted from their answer to this field. Set to null to clear.
showViewSubmissionButtonNoShow "View Submission" button in self-notification emails.
respondentReminderEnabledNoEnable reminder email to respondents who started but did not complete the form. Pro tier.
respondentReminderSubjectNoCustom subject for the reminder email. Plain text with optional {{variable}} placeholders.
selfNotificationEmailBodyNoCustom body for self-notification emails. Plain text with optional {{variable}} placeholders; newlines become paragraphs.
respondentNotificationBodyNoCustom body for respondent confirmation email. Plain text with optional {{variable}} placeholders; newlines become paragraphs.
maxSubmissionsPerRespondentNoMax submissions one respondent may make via "Submit another response" (requires allowAnotherResponse). 0 = unlimited; max 1000. Hard-enforced for signed-in respondents; client-gated for anonymous.
respondentReminderIdleWindowNoSingle-step form of `reminderSteps`, kept for forms authored before multi-step schedules. Ignored when `reminderSteps` is set.
respondentNotificationEnabledNoEnable confirmation email sent to the respondent after submission.
respondentNotificationSubjectNoCustom subject for respondent confirmation email. Plain text with optional {{variable}} placeholders.
respondentNotificationPdfEnabledNoAttach submission PDF to respondent confirmation email.
respondentReminderRequiredFieldIdsNoMinimum fields a respondent must have answered for the reminder to fire. Each item is a field ID from editor_getDocument. Empty array = remind any partial response.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the safe-mutation annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false): it discloses tier gating (Pro tier reminder, Business plan retention), localization side effects (subject/body edits become translatable immediately, self-notification is not translatable), mutual exclusions (redirectUrl vs allowAnotherResponse), and that submissionRetentionDays clears a builder-configured fixed deletion date.

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 the routing sentence, then progressively finer detail; every block (email flows, localization, placeholders) is load-bearing for a 34-parameter tool. It is long, and some parameter-level facts duplicate the schema descriptions, but there is no padding prose.

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 34-param mutation tool with no output schema, the description covers the cross-parameter interactions an agent cannot infer (flow gating, mutual exclusions, tier requirements, where to obtain IDs). Return-value behavior is the only omission and is low-stakes for a settings update.

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 is 3, but the description adds real semantics the schema lacks: the three independent email flows and their gating flags, the requirement that *To point at an email-input field ID, and most importantly the full {{variable}} placeholder vocabulary including answer-by-field-key resolution. A few lines (e.g. emailDomainId null reset) merely restate schema text.

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+resource ('Update form settings') and immediately scopes it to form BEHAVIOR, explicitly naming the sibling tools that handle the excluded concerns (form_update, formTheme_set, editor_*). An agent can select this tool without opening a 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?

Provides explicit routing rules: this tool for behavior, form_update for name/folder/cover/logo, formTheme_set for visual theme, editor_* for questions and content. It also states cross-tool prerequisites (emailDomainId from formSettings_get, field IDs from editor_getDocument, localization via translationDraft_get/update).

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.