Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

updateWidget

Idempotent

Modify an existing widget by widget_id, changing only supplied fields such as HTML, CSS, JS, or metadata. Changes go live immediately and cache refresh is automatic.

Instructions

Update a widget - Update an existing widget by widget_id. Fields omitted are untouched. Writes live data.

Cache refresh is automatic. Response includes auto_cache_refreshed: true after successful writes; no manual refreshSiteCache call needed. If auto_cache_refreshed: false, check auto_cache_refresh_error and retry refreshSiteCache once.

Use when: editing widget HTML (widget_data), CSS (widget_style), JS (widget_javascript), or metadata. Any page or email referencing this widget via [widget=Name] shortcode will render the updated content on next view.

Required: widget_id.

Common edits:

  • Content: widget_data, widget_style, widget_javascript

  • Framework: mobile_enabled, ssl_enabled

Renaming via widget_name: DO NOT pass widget_name unless the user explicitly asks to rename the widget. Renaming a widget breaks every [widget=Name] shortcode reference to its old name on every page/email — silently. If the user does ask: same format rules as create ([A-Za-z0-9 -+_]+, runtime-rejected on bad chars); on collision follow the auto-suffix flow (-v2, -v3, ... up to -v10).

See also: createWidget (add new), deleteWidget (remove).

Writes live data: edits go live immediately for new page loads.

Returns: { status: "success", message: {...updatedRecord}, auto_cache_refreshed: true|false, auto_cache_refresh_error?: "..." }.

For the full field list, see listWidgets.

Input Schema

NameRequiredDescriptionDefault
widget_idYes
widget_dataNoHTML. Render strips backslashes here (`\d`→`d`, `\n`→`n`, `\t`→`t`, `\\`→`\`). JS with stripped escapes throws SyntaxError on parse — every handler unbound, widget renders but no clicks/inputs work. Fix: relocate to `widget_javascript`, do not rewrite JS to avoid backslashes. Never relocate existing `<style>`/`<script>` blocks here — only on user-reported breakage. New content: route by type (CSS→`widget_style`, JS→`widget_javascript`). See **Rule: Widget code fields**.
widget_nameNo
widget_styleNoRaw CSS. No `<style>` wrapper — BD wraps at render. Wholly-wrapped value: outer wrapper stripped on storage; concatenated wrappers not stripped. See **Rule: Widget code fields**.
_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"]`.
widget_javascriptNoJS with `<script>...</script>` wrapper required. BD does not auto-wrap; unwrapped content renders as inert text. No backslash-strip on this field — regex literals (`\d`, `\w`, `\s`) AND string escapes (`\n`, `\t`, `\\`) survive intact. See **Rule: Widget code fields**.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv6.55.39
  2. Removedv6.55.19
  3. Addedv6.49.4
  4. Removedv6.48.1
  5. Addedv6.0.19
  6. Removedv6.0.18
  7. Changed1 schema field changedv6.0.15
    • changedInput schema / properties / widget_data / description
      Previous value: -"Description of the tag group. HTML allowed."New value: +"Main HTML/PHP code body of the widget."
  8. Changed1 schema field changed
    • changedInput schema / properties / widget_data / description
      Previous value: -" Pass raw HTML — do NOT wrap in `<![CDATA[...]]>`, do NOT escape as `&lt;` / `&gt;`, and do NOT include tool-call scaffolding tags (e.g. `<parameter name=\"...\">...</parameter>`, `<invoke>`, `<function_calls>`). BD stores the field value verbatim; any wrapper / escape / scaffolding renders as literal visible text."New value: +"Description of the tag group. HTML allowed."
  9. Addedv6.0.7
  10. Removed
  11. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say it is a non-destructive, idempotent, open-world write; the description goes well beyond that by disclosing that writes go live immediately, that cache refresh is automatic with an `auto_cache_refreshed` flag and a documented retry path via `refreshSiteCache`, and that renaming silently breaks every `[widget=Name]` shortcode. These are exactly the side effects an agent must know before calling.

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?

Bold headers make it skimmable and front-loaded (purpose, cache, use-when, required, then caveats). It is on the long side and slightly redundant — 'Writes live data' is stated twice, and the cache-retry passage repeats the point made in the `auto_cache_refreshed` line.

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?

Despite having no output schema, the description documents the response shape (`status`, `message.updatedRecord`, `auto_cache_refreshed`, optional `auto_cache_refresh_error`), the required parameter, the mutation side effects, and the naming hazards. Nothing an agent needs to invoke and interpret the call is missing.

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 67% and the description compensates for the gaps: `widget_name` has no schema description at all, and the description supplies its format rules, collision behavior, and warning; it also groups parameters into 'Content' vs 'Framework' edits. It adds little for `widget_data`/`widget_style`/`widget_javascript`/`_clear_fields`, whose schema descriptions already carry detailed semantics.

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?

States a specific verb and resource ('Update an existing widget by `widget_id`') plus the partial-update semantic ('Fields omitted are untouched'), which an agent cannot infer from the name alone. 'See also' explicitly routes to `createWidget` (add new), `deleteWidget` (remove), and `listWidgets` (full field list), so it is clearly distinguishable from siblings.

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?

Gives an explicit 'Use when:' trigger (editing HTML/CSS/JS/metadata) and names the alternative tools for adjacent operations. It also provides strong negative guidance — 'DO NOT pass `widget_name` unless the user explicitly asks to rename' — plus the fallback procedure on collision (-v2…-v10).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools