Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

updateFormField

Idempotent

Update an existing form field by ID. Fields omitted remain unchanged; writes live data. Requires field_id.

Instructions

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

Required: field_id.

When renaming field_name on a form_table=website_contacts form, use canonical names (yourname / inquiry_email / phone / comments) — see createFormField and Rule: Forms § Form classes.

See Rule: Forms § Field anatomy for field shape, view-flag defaults, validators, and the canonical json_meta skeleton.

Wrapper-enforced refusals: (1) field_required=1 with field_type ∈ {HoneyPot, HTML, Tip, Button} — Hidden is allowed. (2) field_type not in the canonical enum (strict case match; textarea is the lone lowercase value). (3) field_type=Hidden with empty field_name or empty field_text. (4) Non-binary value on any of field_required / field_input_view / field_display_view / field_email_view / field_search_view / field_grid_view / field_input_view_admin_only (empty / omitted accepted — BD applies per-field defaults).

Agent pre-checks (NOT wrapper-enforced): field_name uniqueness within form, single submit element per form. See Rule: Forms § Wrapper-enforced invariants → Agent-side responsibilities.

See also: createFormField, deleteFormField, listFormFields.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
field_idYes
field_textNo
field_typeNoForm field type. Copy spelling exactly — most are TitleCase but `textarea` is lowercase. Grouping + use cases at **Rule: Forms** § Field anatomy → Valid field_type values.
field_orderNoDisplay position (lower = earlier). New forms: multiples of 10 (10, 20, 30…), security tail included. Adding to an existing form: continue its pattern — don't renumber unrelated fields.
field_requiredNo`0` or `1`. Forbidden when `field_type` ∈ {`HoneyPot`, `HTML`, `Tip`, `Button`} — wrapper refuses these combinations because the requirement can't be satisfied at submit. `Hidden` is allowed (its value comes from `field_text`).
field_placeholderNo
field_ldescNoHelper text rendered under the input field. Use for instructions / format hints (e.g. "Use international format").
default_valueNoPrefilled value the field loads with on render. Accepts a static value OR PHP (e.g. `<?php echo date('Y-m-d'); ?>`) — BD evaluates at render time on any field_type.
field_optionsNoFor `field_type` ∈ {`Radio`, `Checkbox`, `Select`}: `system_name=>label,system_name=>label,...`. LHS submitted value, RHS displayed text. Comma and `=>` are reserved separators. `%%%token%%%` translations supported. Silently ignored on other field types.
field_input_viewNoBinary `0`/`1`. For readonly behavior, add the `readonly` CSS class to `input_class` (e.g. `form-control readonly`); do NOT use `field_input_view=2`.
field_display_viewNoShow submitted value on front-end record-detail pages. Binary `0`/`1`.
field_email_viewNoInclude value in notification emails. Binary `0`/`1`.
field_search_viewNoLead Previews flag — value visible in lead-preview cards before purchase. Applies to forms with `form_table=leads`.
field_grid_viewNoTable View flag — value renders in admin-dashboard / front-end data tables.
field_input_view_admin_onlyNoAdmin-only render flag. When `1`, field renders only when an admin is logged-in on the front end with admin-view enabled; members never see it. Use on `form_action_type=default` member-account forms. Default `0`.
json_metaNoJSON-stringified per-field metadata blob (UI rendering + validator config). See **Rule: Forms** § Field anatomy → `json_meta` for the canonical skeleton.
input_classNoHTML `class=` attribute. On `field_type=Button`, must be `btn btn-lg btn-block <variant>` - e.g. `btn btn-lg btn-block btn-secondary`. Variant is one of `btn-primary`/`btn-secondary`/`btn-danger`/`btn-success`/`btn-warning`/`btn-info`/`btn-dark`, OR a custom class targeted by site CSS. See `createFormField`.
_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"]`.
Behavior5/5

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

Annotations indicate readOnlyHint=false (write operation), destructiveHint=false (non-destructive), idempotentHint=true (idempotent), and openWorldHint=true (allows extra fields). The description aligns perfectly: it says 'update' and 'writes live data', confirms non-destructive behavior, and provides details on partial updates ('Fields omitted are untouched') and constraints (wrapper-enforced refusals). No contradictions; the description adds valuable behavioral context beyond 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 longer than average but well-structured. It starts with a concise one-line summary, then organizes information into sections: required field, special case for renaming, external references, wrapper-enforced refusals, agent pre-checks, and see-also. Every sentence adds value, though some sections are dense. It balances detail with clarity, earning a high score for its context.

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 18 parameters, no output schema, and complexity, the description is comprehensive. It covers purpose, usage, behavioral constraints, parameter semantics, and related tools. It references external rules for deeper details. While it doesn't describe return values explicitly (common for update operations without output schema), it provides sufficient context for an agent to use the tool effectively. Slight overhead in length but justified by complexity.

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 description coverage is 83% (high), so baseline is 3. The description adds significant meaning: for field_type, it warns about case sensitivity; for field_required, it explains forbidden combinations; for field_input_view, it clarifies not to use value 2; for _clear_fields, it details usage with examples. While the schema already describes most parameters, the description provides deeper behavioral context and cross-references, justifying a score above baseline.

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 the verb 'Update' and the resource 'form field'. It specifies updating by ID and notes that omitted fields are untouched, distinguishing it from creation or deletion. The phrase 'Writes live data' confirms it's a live operation. This is specific and distinct from siblings like createFormField, deleteFormField, and listFormFields.

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?

The description explicitly notes the required parameter 'field_id' and provides extensive guidance on when to use the tool, including special cases like renaming fields on a specific form, referencing external rules for field anatomy and validators, detailing wrapper-enforced refusals, and listing agent pre-checks. It also lists related tools (createFormField, deleteFormField, listFormFields) as alternatives, offering clear context for choosing this tool.

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