Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

createFormField

Create a new form field for a directory site by specifying field name, label, type, and order. Optionally set validation, visibility, and default values.

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
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_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.
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`. Schema default empty (treat as `0`); send explicitly when overriding.
field_grid_viewNoTable View flag — value renders in admin-dashboard / front-end data tables. Schema default `1`; send `0` to hide.
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. 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"`.
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.
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.

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