Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official
by brilliantdirectories
OverviewSchemaRelated ServersScoreDiscussions(1)
JavaScript
Remote

createLead

Create a lead record with required submitter details. Optionally send email notifications and auto-match to members or specified users.

Instructions

Create a lead - Create a new lead record. Writes live data.

Use when: importing leads from an external form, CSV, or web-scrape. Default is SILENT - no notification emails fire unless you pass send_lead_email_notification=1, and no member routing happens unless you pass auto_match=1 (inline) or call matchLead afterward. top_id (category) is required - look it up via listTopCategories.

Required: lead_name, lead_email, lead_phone, lead_message, lead_location, top_id.

Parameter interactions:

  • top_id - category ID; discover via listTopCategories

  • All 6 required fields (lead_name, lead_email, lead_phone, lead_message, lead_location, top_id) must be supplied together

  • Response includes lead_id AND token - token may be needed for customer-facing URLs

  • After creating, call matchLead to trigger member notifications

See also: updateLead (modify existing).

Operational rules (from BD support article 12000091106):

  • send_lead_email_notification=1 - activates lead email notifications to the site admin and/or matched members. Default is off: leads created via API are silent unless this flag is set. For the full auto-matching flow (finds members by category/location and emails them), call matchLead separately after creating the lead (or pass auto_match=1 on this call to run inline).

Targeting specific members (override auto-match): set users_to_match to a comma-separated list of member IDs or emails (e.g. 6099,6100 or user1@example.com,user2@example.com, mixed OK). This BYPASSES the normal category/location/service-area matching and routes the lead to ONLY those members. Typically paired with auto_match=1 (to run the match step inline) and send_lead_email_notification=1 (to fire the matched-member email). Common pattern when an external system already knows who should receive the lead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lead_nameYesSubmitter's full name.
lead_emailYesSubmitter email address.
lead_phoneYesSubmitter phone number.
lead_messageYesSubmitter's detailed request — what they typed describing their needs.
lead_locationYesGeocoded location string. BD computes the derived geocode columns (`lat`/`lng`/bounding box/`country_sn`/`adm_lvl_1_sn`/`location_type`) from this.
top_idYesTop category ID. Discover via `listTopCategories`.
send_lead_email_notificationNoSet `1` to fire lead notification emails on create. Default `0` - API-created leads are silent. - With `auto_match=1` or `users_to_match` populated -> matched-member notification fires (if this flag = `1`) - Without a match step -> only admin notification fires (if configured) **For matched-member notifications:** combine this flag with a matching trigger (`auto_match=1` and/or `users_to_match`) - neither alone is sufficient.
auto_matchNoSet to `1` to run the match step inline during create (equivalent to calling `matchLead` immediately after). Default `0` = no match step fires. When combined with `users_to_match`, the match step still fires but the category/location/service-area matching ALGORITHM is bypassed — the lead routes ONLY to the specified members.
users_to_matchNo**ADVANCED - OVERRIDES auto-match.** Comma-separated list of `user_id` values OR member email addresses (mixable) to route this lead to directly. When set, BD skips normal category/location/service-area auto-matching and routes ONLY to these members. Examples: `239` | `6099,6100` | `user1@example.com,user2@example.com` | `239,user1@example.com`. Typically paired with `auto_match=1` (triggers match inline) AND `send_lead_email_notification=1` (fires matched-member email - without the flag, matches record but no email sends).

Tool Definition Quality

A4.8/5.0
Behavior5/5

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

Annotations are readOnlyHint=false (write operation) and destructiveHint=false (not destructive). The description adds: 'Writes live data', default silent behavior (no notifications unless flags), no automatic member routing without auto_match or matchLead, response includes lead_id and token, and operational rules from support article. This goes well beyond annotations, providing essential behavioral context.

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

Conciseness5/5

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

Description is long but well-structured with headings, bullet points, and clear sections. It front-loads the core purpose and usage, then dives into details. Every sentence adds value—no fluff. The structure aids readability for an AI agent parsing instructions.

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?

For a tool with 9 parameters, 2 enums, no output schema, and complex workflow (notifications, matching, member overrides), the description is remarkably complete. It covers operational rules, parameter interactions, response fields (lead_id, token), recommends sibling tools (listTopCategories, updateLead, matchLead), and even references a support article. No gaps identified.

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%, yet description adds substantial meaning: explains default values (0 for flags), parameter interactions (auto_match and users_to_match combinations), and patterns (e.g., 'Typically paired with auto_match=1 AND send_lead_email_notification=1'). It clarifies that required fields must be supplied together. Description compensates fully despite 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?

Description starts with 'Create a lead - Create a new lead record. Writes live data.' which clearly states the verb (create) and resource (lead). It distinguishes from siblings like updateLead and createLeadMatch by explaining the default silent behavior and the optional matching workflow. The purpose is specific and actionable.

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?

Description explicitly states when to use: 'importing leads from an external form, CSV, or web-scrape.' It explains default silent mode, when to pass flags (send_lead_email_notification, auto_match), and references sibling tool matchLead. It does not explicitly say when NOT to use, but context is clear enough. A slight improvement would be an explicit contraindication.

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