Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

createForm

Create a new form record in Brilliant Directories, setting slug, title, layout, and target table. Writes live data; add fields separately with createFormField.

Instructions

Create a form - Create a new form record. Writes live data. Add fields afterward via createFormField.

Required: form_name, form_title, form_action, form_layout, form_table, form_url, form_class, table_index, form_action_div, form_email_on, form_success_message.

Class selection — see Rule: Forms § Form classes before picking form_table. Follow § Form-level recipe for the canonical creation recipe.

Mandatory form_name pre-check per Rule: Pre-check natural keys — BD does NOT enforce uniqueness; duplicate form_name produces ambiguous [form=…] shortcode resolution.

Wrapper-enforced refusal: form_action_type=redirect AND empty form_target → call refused (see Rule: Forms § Wrapper-enforced invariants).

See also: updateForm, createFormField, listFormFields.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
form_urlYesSave Action URL - overrides default `action=` on the rendered form. **Required exact value for every form an agent creates:** `/api/widget/json/post/Bootstrap%20Theme%20-%20Function%20-%20Save%20Form`. This is the BD Save Form widget endpoint; without it, submit wiring breaks. Do NOT decode the `%20` - BD needs the URL-encoded form verbatim./api/widget/json/post/Bootstrap%20Theme%20-%20Function%20-%20Save%20Form
form_nameYesSystem slug (lowercase alphanumerics + hyphens + underscores; NO spaces). Hyphens and underscores are NOT interchangeable — the stored value is the lookup key, byte-exact, in `[form=<form_name>]` shortcodes and on `createFormField` parent references. Immutable post-create. Must be unique per site. For the human-readable nickname use `form_title`. Example: `form_name=strength_blueprint_ebook`.
form_classYesCSS class applied to every field — UI consistency insurance. Canonical: `form-control`. Per-field `input_class` layers extra CSS on top.form-control
form_tableYesDatabase table the form submissions post into. `website_contacts` = Standard public class (default for ALL public capture; free-create with this tool). `leads` = Lead-saving class (BD's Get-Matched member-routing ONLY) — never free-create from scratch; clone `bootstrap_get_match` per **Rule: Forms** § Lead-match special case. `users_data` = Member-dashboard class — never free-create from scratch; clone-and-assign one of the 3 canonical dashboard forms per § Member-dashboard special case. See § Form classes for the picking rule. Once set on create, treat as immutable.website_contacts
form_titleYesHuman-friendly nickname (free text — spaces and any characters allowed). Surfaced in admin UI and form-listing screens. Example: `form_title="Strength Blueprint Ebook"`. NOT the same as `form_name` (the system slug).
form_actionYes**post** = form submits via POST body (default, most forms). **get** = form submits as URL query string (use for bookmarkable search/filter forms).post
form_layoutYes**bootstrapvertical** = Labels Above Inputs (canonical default). **bootstrap** = Labels Left of Inputs (canonical default for Member-dashboard class — `form_action_type=default`). User override wins in either case.bootstrapvertical
form_targetNoDestination URL. **Required when `form_action_type=redirect`** — wrapper refuses the call without it. Full URL with `https://`, e.g. `https://mysite.com/thanks`.
table_indexYesPrimary key column matching `form_table`: `website_contacts` → `ID`, `leads` → `lead_id`, `users_data` → `user_id`. Required exact match — BD uses this to look up individual submissions.ID
form_email_onYesSend admin notification email on each submission. `0` = OFF (default when an agent creates a form - safer: spammy forms won't flood the admin inbox). `1` = ON. Admin UI defaults this to ON; agents default it to OFF unless user explicitly requests notifications.
form_action_divYesTarget element ID (CSS selector including `#`) swapped in the DOM on form submit by the `widget` (Success Pop-Up) action type; harmlessly ignored on `notification` / `redirect`. **Always send `#main-content`** unless the user explicitly names a different target — it's the canonical default for every `form_action_type`. Must include leading `#`.#main-content
form_action_typeNoPost-submit behavior: - `widget` = Success Pop-Up (agent default). - `notification` = Inline Success Alert Banner. - `redirect` = Redirect to URL (wrapper-enforced: `form_target` required, see `form_target` field). - `default` = Member-dashboard class (admin-clone-only; do not create from scratch). - `""` (empty) = no post-submit behavior (valid only for internal/programmatic forms, NOT public-facing). For public-facing values (`widget` / `notification` / `redirect`), Button-last is the agent-side tail-pattern responsibility (NOT wrapper-enforced). See **Rule: Forms** § Form-level recipe.widget
form_email_recipientNoComma-separated email list to receive submission notifications. Used only when `form_email_on=1`. Empty = site default admin recipient.
form_success_messageYesPost-submit success copy. Canonical default for Standard public AND Lead-saving classes: `Your Message has been Received`. Override only on explicit user request. Applies to `form_action_type` ∈ {`widget`, `notification`, `redirect`}; not used by `default` (member-dashboard) class.Your Message has been Received
label_to_placeholderNoForm-level toggle. When `"1"`, BD collapses each field's `field_text` (label) into placeholder text inside the input — saves vertical space, removes the explicit `<label>` element above each field. Per-field `field_placeholder` is overridden when this is on. Default `"0"`.0
Behavior5/5

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

Beyond annotations (readOnly=false, openWorld=true), the description discloses that the tool 'Writes live data', flags BD's lack of uniqueness enforcement on form_name causing ambiguous shortcodes, and reveals a wrapper-enforced refusal when form_action_type=redirect with empty form_target. These are actionable behavioral constraints not present in structured 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 long but well-structured, using bolded required fields, rule references, and a clear return contract. Each section contributes to parameter constraints or usage context, though the heavy reliance on external 'Rule: Forms' references and the sheer length prevent a perfect score.

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?

With 15 parameters and no output schema, the description fully compensates by defining the return shape ({status, message, _admin_edit_url}) and instructing the agent to surface _admin_edit_url to the user. It also covers prerequisites, exclusions, and wrapper enforcement, making the tool's behavior predictable in 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?

Schema description coverage is 100%, so the schema already documents all 15 parameters. The description adds extra semantic value by highlighting form_name uniqueness pre-checks, form_target's conditional requirement based on wrapper rules, and form_table's clone-vs-create guidance. This exceeds the baseline for high schema coverage.

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 uses a specific verb-resource pair ('Create a form - Create a new form record') and immediately distinguishes itself from the later step 'Add fields afterward via createFormField'. It also lists sibling tools (updateForm, createFormField, listFormFields) in a 'See also' section, making differentiation clear.

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 provides explicit when-to-use and when-not-to-use guidance: it instructs agents to add fields via createFormField, warns against free-creating leads and users_data forms ('never free-create from scratch'), and directs consultation of 'Rule: Forms § Form classes before picking form_table'. It also names alternatives via 'See also'.

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