Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

updateForm

Idempotent

Update an existing form record by its ID. Omitted fields keep their current values; changes are saved 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} }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
form_idYes
form_titleNo
form_email_onNoSend admin notification email on each submission. `0` = OFF, `1` = ON.
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_targetNoDestination URL, required when `form_action_type=redirect`, ignored otherwise. Full URL with `https://`.
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.
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.
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_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.
_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"]`.
Behavior4/5

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

Beyond annotations (idempotentHint, readOnlyHint, etc.), the description adds key behaviors: 'Fields omitted are untouched', a specific refusal case (redirect with empty target), and the special `_clear_fields` parameter behavior for clearing fields. No contradictions with annotations.

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?

The description is well-structured: purpose, required field, cross-references, precondition, refusal note, see also, and return format. Every sentence adds value, though some external rule references could be integrated or explained. It is front-loaded and efficiently organized.

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?

Given the tool's complexity (11 parameters) and no output schema, the description covers the essential context: update mechanics, required parameter, special cases, and return format. It references Rule: Forms for deeper context, which is adequate, though the agent may need those rules for full completeness.

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?

With 82% schema description coverage, the baseline is 3. The description adds value by explaining the interaction between `form_action_type` and `form_target` with a refusal example, and clarifying the `_clear_fields` mechanism. It also references rules that enhance parameter understanding.

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 clearly states 'Update a form - Update an existing form record by ID', specifying the action (update), resource (form), and key scope (by ID). It distinguishes from sibling tools like createForm (creation) and deleteForm (deletion) by its verb and explicit mention of updating an existing record.

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 provides explicit guidance: `form_id` is required, notes that flipping `form_action_type` to public requires prior use of `listFormFields`, and states a wrapper-enforced refusal for specific conditions. It also references related tools and rules, giving the agent context on when to use and prerequisites.

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