Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

createFormField

Add a new field to any existing form, specifying its type, label, internal name, display order, and validation settings. Live data is written immediately.

Instructions

Create a form field - Create a new formfield record. Writes live data.

Required: form_name, field_name, field_text, field_type, field_order.

Canonical field_name for form_table=website_contacts: yourname / inquiry_email / phone / comments (NOT name / email / message — those persist but don't surface in the admin inbox columns). Anything else = custom field_name. Full table at Rule: Forms § Form classes.

See Rule: Forms § Field anatomy for field shape, view-flag defaults, validators, and the canonical json_meta skeleton. § Form-level recipe covers the tail pattern. § Lead-match / § Member-dashboard cover special-case forms.

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: updateFormField, listFormFields.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
form_nameYesParent form slug
json_metaNoJSON-stringified per-field metadata blob (UI rendering + validator config). See **Rule: Forms** § Field anatomy → `json_meta` for the canonical skeleton. Pass the full skeleton even when unused; BD's admin form-builder writes all keys. Validators in `field_validate.validators` only fire when `field_validator_enabled` is `"1"`.
field_nameYesInternal system key for this field. **Underscores only, no spaces** - e.g. `first_name`, `company_email`. Used as the HTML `name` attribute.
field_textYesPublic-facing display label shown to the user. Free-form text - e.g. "First Name", "Your Email Address".
field_typeYesForm 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_ldescNoHelper text rendered under the input field. Use for instructions / format hints (e.g. "Use international format").
field_orderYesDisplay 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.
input_classNoHTML `class=` attribute on the rendered input. **Required for `field_type=Button`** - without it, submit button renders unstyled. Canonical Button pattern: `btn btn-lg btn-block <variant>` where `<variant>` is a Bootstrap button class (`btn-primary`/`btn-secondary`/`btn-danger`/`btn-success`/`btn-warning`/`btn-info`/`btn-dark`) or a custom site class. Example: `btn btn-lg btn-block btn-secondary`. Optional on non-Button fields.
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_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_grid_viewNoTable View flag — value renders in admin-dashboard / front-end data tables. Schema default `1`; send `0` to hide.
field_email_viewNoInclude value in notification emails. Binary `0`/`1`.
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_placeholderNo
field_search_viewNoLead Previews flag — value visible in lead-preview cards before purchase. Applies to forms with `form_table=leads`. Schema default empty (treat as `0`); send explicitly when overriding.
field_display_viewNoShow submitted value on front-end record-detail pages. Binary `0`/`1`.
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`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv6.55.39
  2. Removedv6.55.19
  3. Addedv6.49.4
  4. Removedv6.48.1
  5. Addedv6.0.19
  6. Removedv6.0.18
  7. Changed4 schema fields changed
    • changedInput schema / properties / field_name / description
      Previous value: -"Internal system key for this field. **Underscores only, no spaces** — e.g. `first_name`, `company_email`. Used as the HTML `name` attribute."New value: +"Internal system key for this field. **Underscores only, no spaces** - e.g. `first_name`, `company_email`. Used as the HTML `name` attribute."
    • changedInput schema / properties / field_text / description
      Previous value: -"Public-facing display label shown to the user. Free-form text — e.g. \"First Name\", \"Your Email Address\"."New value: +"Public-facing display label shown to the user. Free-form text - e.g. \"First Name\", \"Your Email Address\"."
    • changedInput schema / properties / field_type / description
      Previous value: -"Form field type. See full list grouped by category (Select / Text inputs / Fancy fields) in the tool description."New value: +"Form field type. Authoritative enum values (copy spelling exactly - most are TitleCase but `textarea` is lowercase):\n\n**Select:** `Checkbox` (multi-select), `Select` (dropdown), `Radio` (single-select), `YesNo` (toggle). Require `field_options` list.\n\n**Text inputs:** `Custom` (HTML injection), `Email` (validates format), `HTML` (display heading), `Button` (submit), `Textbox` (single-line), `textarea` (multi-line, lowercase), `Url`.\n\n**Fancy:** `Date`, `DateTimeLocal`, `File`, `FroalaEditor`, `FroalaEditorUserUpload`, `FroalaEditorUserUploadPreMadeElem`, `FroalaEditorAdmin`, `Tip` (help box), `Hidden` (stores value, not rendered), `Country`, `State`, `Number` (integer-only), `Password` (masked), `Phone`, `CountryCodePhone`, `Pricebox`, `ReCaptcha`, `HoneyPot` (anti-spam), `Category`, `Years`.\n\nSimple text -> `Textbox`; paragraphs -> `textarea`; emails -> `Email` (BD validates format)."
    • changedInput schema / properties / input_class / description
      Previous value: -"HTML `class=` attribute applied to the rendered input. **Required for `field_type=Button`** — without it, the submit button renders unstyled. Canonical value: `btn btn-lg btn-block <variant>` where `<variant>` is one of `btn-primary` / `btn-secondary` / `btn-danger` / `btn-success` / `btn-warning` / `btn-info` / `btn-dark` (Bootstrap button variants), OR a custom class the site targets with its own CSS. Example: `btn btn-lg btn-block btn-secondary`. For non-Button fields this is optional — use to apply custom styling if needed; safe to omit."New value: +"HTML `class=` attribute on the rendered input. **Required for `field_type=Button`** - without it, submit button renders unstyled.\n\nCanonical Button pattern: `btn btn-lg btn-block <variant>` where `<variant>` is a Bootstrap button class (`btn-primary`/`btn-secondary`/`btn-danger`/`btn-success`/`btn-warning`/`btn-info`/`btn-dark`) or a custom site class. Example: `btn btn-lg btn-block btn-secondary`.\n\nOptional on non-Button fields."
  8. Addedv6.0.7
  9. Removed
  10. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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

Despite annotations (readOnlyHint=false, etc.), the description adds extensive behavioral context: 'Writes live data', detailed 'Wrapper-enforced refusals', and 'Agent pre-checks'. This goes well beyond annotations to fully disclose validation rules and side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed and well-organized with sections, but it is lengthy due to extensive references and examples. While structured, it could be more concise for efficiency.

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?

Given 18 parameters, no output schema, and complex enums, the description is highly complete. It covers required fields, validation rules, real-world examples, and references to rules. Agent pre-checks and wrapper-enforced refusals ensure agents have full context.

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 94% schema description coverage, the baseline is high. The description adds value by clarifying canonical field names, input_class requirements, and refusals. It provides examples and rule references, enhancing understanding beyond the schema.

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 explicitly states 'Create a form field - Create a new formfield record. Writes live data.' It clearly identifies the resource and action. Mentioning sibling tools (updateFormField, listFormFields) further distinguishes its specific purpose.

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 lists required parameters and provides canonical examples. It references rules and sibling tools, offering context on when to use. However, it lacks explicit 'when not to use' or alternative conditions, so it's slightly below a 5.

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

Deploy Server

Other Tools