Skip to main content
Glama

Change a form's settings

bootform_configure_form
DestructiveIdempotent

Updates a form's name, allowed origins, redirect, or subject template, and turns on the public moderated content feed (Pro plan or higher): set content_feed_enabled to true and list public_fields, then the site can read approved submissions, photos included, from https://f.bootform.com/forms/{form_id}/feed with no API key. item_status_label adds a status visitors can mark (for example "taken") via POST .../feed/{submission_id}/status. honeypot_enabled and honeypot_field change the form's spam trap; the answer's notes then give the exact line the page must carry, so update the page in the same job. retention_days makes BootForm delete the form's submissions that many days after they arrive; if that deletes submissions already stored, the call is refused with the count until you pass confirm_delete: true, so tell the person the count and ask first. CAPTCHA keys are set in the dashboard only. Only fields you pass are changed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "form_id": "<form_id>"
    },
    "name": "bootform_configure_form"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoNew display name
form_idYesThe form's id
redirect_urlNoNew post-submission redirect URL
workspace_idNoMove the form to this workspace (bootform_list_workspaces)
public_fieldsNoContent feed (Pro+): the field names shown publicly, file fields included (e.g. ["description", "photo"]). Replaces the whole list; every other field stays private.
confirm_deleteNotrue confirms that a shorter retention_days may delete submissions already stored. Only pass it after the person agreed to the count the refused call gave.
honeypot_fieldNoRenames the form's hidden honeypot field (1 to 64 characters: a letter, then letters, digits, _ or -). New forms use honeypot; never pick one of the form's real fields. Update the live page first: while the switch is on, posts without the new name land in spam.
retention_daysNoDelete this form's submissions this many days after they arrive (1 up to the plan's period, shown as plan_retention_days). 0 goes back to the workspace default or the plan's period. Deletion is permanent.
allowed_originsNoNew origin allowlist
honeypot_enabledNoThe Honeypot switch. true: a post that leaves the form's hidden honeypot field filled, or does not carry it at all, lands in spam, so the page must carry the field (the answer gives the line). false: no honeypot check.
report_thresholdNoContent feed (Pro+): hide a submission from the feed after this many visitor reports. 0 turns auto-hide off.
subject_templateNoNew notification email subject template
item_status_labelNoItem status (Pro+): what visitors can mark a feed item as, for example "taken", "found" or "sold" (1 to 24 characters). An empty string removes it. Setting it replaces the whole item status, so pass the threshold and hide delay you want with it.
content_feed_enabledNoContent feed (Pro+): true turns on moderation and the public feed, false turns them off. Every submission still needs approval (bootform_moderate_submission) before it appears.
item_status_thresholdNoItem status: how many distinct visitors must mark an item before it counts as set. Default 1.
item_status_hide_after_hoursNoItem status: hide a set item from the feed this many hours after it was set (0 = at once). Omit to keep set items in the feed with their status.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already flag destructive and idempotent behavior; the description adds what gets destroyed (submissions after retention_days), the refusal-with-count confirmation flow, honeypot page-update hazard, feed approval requirement, and dashboard-only CAPTCHA. These details substantially exceed the annotations and do not contradict them.

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-loads the main update and feed feature, then groups related caveats and dependencies. It is dense but mostly earns its length; the single paragraph is heavy for 16 parameters, though no sentence is clearly disposable.

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 a 16-parameter destructive mutation with no output schema, the description covers the high-risk behaviors, plan gate, confirmation flow, and page-update dependency. Some parameter behaviors and the general return shape are left to the very rich schema and annotations, so it is not fully exhaustive.

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 baseline is 3; the description goes further by defining cross-parameter workflows such as content_feed_enabled with public_fields, item_status_label's POST endpoint, retention_days with confirm_delete, and honeypot_enabled with honeypot_field. It omits some settings like workspace_id and item-status thresholds, but adds meaningful semantic relationships.

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 and resource: it updates a form's name, origins, redirect, subject template, and feed settings. The repeated anchoring to 'form' and 'form's settings' clearly separates it from workspace-level configuration.

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?

Gives clear context for Pro-plan feed features, dashboard-only CAPTCHA, and irreversible retention changes requiring confirm_delete. It does not explicitly name when to use this rather than bootform_create_form or bootform_configure_workspace, but the operational conditions are otherwise rich.

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