Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

updateLead

Idempotent

Update a lead record by its ID. Only specified fields are modified; omitted fields stay unchanged. Use _clear_fields to clear specific fields to empty.

Instructions

Update a lead - Update an existing lead record by ID. Fields omitted are untouched.

Required: lead_id.

Custom (form-defined) lead fields — e.g. wizard-style hidden match_* fields — live in users_meta with database=leads and database_id=<lead_id>. Use updateUserMeta / createUserMeta for those. Rule: Forms § Form classes → Custom-field storage covers the pattern.

See also: createLead, deleteLead, matchLead, updateUserMeta.

Returns: { status: "success", message: {...updatedRecord} }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lead_idYes
lead_nameNoSubmitter's full name.
lead_emailNoSubmitter email address.
lead_phoneNoSubmitter phone number.
lead_messageNoSubmitter's detailed request — what they typed describing their needs.
lead_locationNoGeocoded location string. BD recomputes the derived geocode columns (`lat`/`lng`/bounding box/`country_sn`/`adm_lvl_1_sn`/`location_type`) when this changes.
lead_moreNoMatch-broadcast flag from the submitter's form input (radio/select). `0` = contact only the single matched member (default). `1` = broadcast to multiple matching members.
lead_priceNoLead price (decimal). `0.00` = free.
top_idNoTop category ID. Changing this orphans existing `lead_matches` rows — re-run `matchLead` to re-route.
sub_idNoSub-category ID. Same `lead_matches` consideration as `top_id`.
lead_notesNoOwner-to-member notes about the lead (e.g. "phone number verified"). Visible to the matched member; never shown to the submitter. Leave blank unless the user asks.
lead_statusNoLead status (integer). NON-SEQUENTIAL enum - `3` does NOT exist; do not assume gaps are fillable: - `1` = Pending (received, awaiting action) - `2` = Matched (assigned to members) - `4` = Follow-Up (in progress) - `5` = Sold Out (no capacity) - `6` = Closed (resolved - converted or won't convert) - `7` = Bad Leads (spam/invalid) - `8` = Delete (soft-delete - hides from views) "Sold" / "won" -> `6` (Closed). Spam -> `7`. BD does NOT validate this enum - out-of-set integers are accepted and stored with undefined render behavior. Always use documented values.
_clear_fieldsNoColumn names to clear to empty string. Available on every `update*` operation. Works on base columns AND EAV/`users_meta` rows (rows preserved with `value=""`). To actually clear a field you MUST use this parameter — sending the field with `""` alone is a no-op (BD drops empty values). To remove a `users_meta` row entirely, use `deleteUserMeta`. See **Rule: Clearing fields**. Example: `_clear_fields: ["h2", "hero_link_url"]`.
Behavior4/5

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

Annotations already indicate idempotentHint=true. The description adds behavioral context: fields omitted are untouched, and the return format is specified. It does not repeat side-effect warnings from the schema (e.g., top_id orphan matches), which is acceptable since the schema covers those. However, a brief mention of idempotent behavior could further enhance transparency.

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?

The description is concise and well-structured with bullet points and sections. It front-loads the main purpose and keeps each sentence purposeful. No unnecessary content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (13 parameters, no output schema), the description provides necessary context: return format, custom field handling, and links to related tools. It does not cover every behavioral edge case, but the schema with 92% coverage fills gaps. A note about lead_matches impact could improve completeness, but overall it is sufficient.

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 coverage is high (92%), so baseline is 3. The description adds value by highlighting the required lead_id, explaining the return format, and clarifying custom field storage. It does not describe each parameter, but the schema already provides detailed descriptions. Overall, it supplements the schema effectively.

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 ('Update') and resource ('lead'), clearly states it updates an existing lead record by ID, and distinguishes itself from sibling tools like createLead, deleteLead, matchLead, and updateUserMeta by mentioning them in 'See also'.

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 explicitly states when to use this tool ('Update an existing lead record by ID'), notes that omitted fields are untouched, indicates the required parameter (lead_id), and provides guidance on handling custom fields via updateUserMeta/createUserMeta, including a reference to related rules.

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