Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

createForm

Create a form record with required fields to collect submissions, send notifications, or redirect users on a Brilliant Directories site.

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} }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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_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_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_classYesCSS class applied to every field — UI consistency insurance. Canonical: `form-control`. Per-field `input_class` layers extra CSS on top.form-control
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_email_recipientNoComma-separated email list to receive submission notifications. Used only when `form_email_on=1`. Empty = site default admin recipient.
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_targetNoDestination URL. **Required when `form_action_type=redirect`** — wrapper refuses the call without it. Full URL with `https://`, e.g. `https://mysite.com/thanks`.
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
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_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_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?

Annotations indicate write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds context: 'Writes live data', notes BD does not enforce uniqueness on form_name leading to ambiguous shortcodes, and warns about wrapper-enforced refusal for redirect without form_target. No contradiction 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 long but well-structured with paragraphs: summary, required fields, class selection, pre-check, wrapper-enforced refusal, see also, and returns. It is front-loaded with the main purpose. Slightly verbose but each section adds value.

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 15 parameters, 11 required, no output schema, the description covers all key aspects: required fields are listed, return format is specified, and important constraints (uniqueness, wrapper enforcement, class selection) are explained. The input schema handles the rest.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant value beyond schema: explains immutability of form_name, differentiates form_name vs form_title, clarifies enum choices for form_action, form_table, form_action_type, provides required exact value for form_url, canonical defaults for form_success_message, and agent vs admin defaults for form_email_on.

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 starts with 'Create a form - Create a new form record. Writes live data.' It clearly states the specific verb (create) and resource (form record), and distinguishes from siblings like createFormField, updateForm, and listForms via the 'See also' section. The title is missing, but the description compensates.

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?

Provides explicit guidance: lists required fields, class selection rules (referencing Rule: Forms), mandatory form_name pre-check for uniqueness, wrapper-enforced refusal for redirect with empty form_target, and directs to add fields afterward via createFormField. Also references rules sections for edge cases.

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