Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

updateForm

Idempotent

Update an existing form record by ID, changing only the fields you specify while leaving all other settings untouched. Changes are applied live.

Instructions

Update a form - Update an existing form record by ID. Fields omitted are untouched. Writes live data.

Required: form_id.

Cross-refs same as createForm — see Rule: Forms § Form-level recipe / § Lead-match / § Member-dashboard. Before flipping form_action_type to a public-facing value, run listFormFields to confirm the tail pattern exists.

Wrapper-enforced refusal: form_action_type=redirect AND empty form_target → call refused.

See also: createForm, deleteForm, listFormFields / createFormField.

Returns: { status: "success", message: {...updatedRecord}, _admin_edit_url: "..." }. _admin_edit_url is a centralized-admin deep-link to the Form Builder editor for this form's form_name — surface it to the user so they can jump straight to the admin edit screen for the form just updated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
form_idYes
form_urlNoSave Action URL. Canonical value: `/api/widget/json/post/Bootstrap%20Theme%20-%20Function%20-%20Save%20Form`. If a form was created via this API with the correct value, leave this field alone on update - only touch it to repair a form that was created without it.
form_titleNo
form_targetNoDestination URL, required when `form_action_type=redirect`, ignored otherwise. Full URL with `https://`.
table_indexNoPrimary key column matching `form_table`: `website_contacts` → `ID`, `leads` → `lead_id`, `users_data` → `user_id`. Leave alone on update unless repairing a broken form.
_clear_fieldsNoColumn names to clear to empty string. Available on every `update*` operation. Works on base columns AND EAV/`users_meta` rows (rows preserved with `value=""`). To actually clear a field you MUST use this parameter — sending the field with `""` alone is a no-op (BD drops empty values). To remove a `users_meta` row entirely, use `deleteUserMeta`. See **Rule: Clearing fields**. Example: `_clear_fields: ["h2", "hero_link_url"]`.
form_email_onNoSend admin notification email on each submission. `0` = OFF, `1` = ON.
form_action_divNoTarget element ID (CSS selector with `#`) swapped on submit by the `widget` action type; harmlessly ignored on `notification` / `redirect`. Canonical value: `#main-content`. Override only when the user explicitly names a different target.
form_action_typeNoPost-submit behavior. `widget` = success pop-up, `notification` = success alert banner, `redirect` = send user to `form_target` URL (wrapper-enforced: `form_target` required, see `form_target` field), `default` = member-dashboard class (admin-clone-only), `""` = no behavior (internal-only forms). When flipping FROM empty TO a public-facing value, verify the tail pattern (Button-last is agent-side, NOT wrapper-enforced) via `listFormFields`. See **Rule: Forms** § Form-level recipe.
form_success_messageNoPost-submit success copy. Canonical default for Standard public AND Lead-saving classes: `Your Message has been Received`. If the existing record already has a value and the user hasn't flagged the message as a problem, leave it alone. Only set this on update when (a) the user asks for different copy, or (b) the field is empty and you're filling in the canonical default. Applies to `form_action_type` ∈ {`widget`, `notification`, `redirect`}; not used by `default` class.
label_to_placeholderNoForm-level toggle. When `"1"`, BD collapses each field's `field_text` (label) into placeholder text inside the input. Per-field `field_placeholder` is overridden when this is on.
Behavior5/5

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

The description goes beyond the annotations by disclosing partial-update semantics ('Fields omitted are untouched'), live data writes, and a specific refusal rule. It also details the return format and the meaning of `_admin_edit_url`, giving the agent full awareness of side effects and post-update actions. This aligns with the annotations (readOnlyHint=false, destructiveHint=false) without contradiction.

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 well-structured: a one-sentence summary, a required-field note, behavioral rules, cross-references, and a return-value specification. Every sentence earns its place without redundancy. The formatting with bold headings and bullet-like separators improves scannability for an AI agent.

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 complex update tool with 11 parameters and no output schema, the description covers all critical aspects: required field, partial updates, prerequisites, refusal conditions, return structure, and how to surface the admin link. Cross-references to shared 'Rule: Forms' are acceptable given the schema's thoroughness and the presence of sibling tools.

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?

The input schema already covers 82% of parameters with rich descriptions. The tool description adds cross-parameter context, such as the dependency between `form_action_type=redirect` and non-empty `form_target`, and the prerequisite to run `listFormFields` before certain changes. It also highlights `_clear_fields` as a special parameter, which is useful operational knowledge beyond the schema's per-field explanation.

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-resource pair: 'Update an existing form record by ID.' It clearly distinguishes from sibling tools like createForm and deleteForm by emphasizing partial updates ('Fields omitted are untouched') and live writes. The 'See also' list reinforces its role as an update operation.

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 states when to use the tool (updating existing forms) and provides actionable prerequisites, such as running `listFormFields` before flipping `form_action_type` to a public-facing value. It also names the wrapper-enforced refusal condition. While it doesn't explicitly say 'use this instead of X', the context and cross-references effectively differentiate it from create/delete operations.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/brilliantdirectories/brilliant-directories-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server