Skip to main content
Glama

dialogbrain

by io.github.saloprj
OverviewDiscussionsAdmin

widgets_update

Update an existing livechat widget configuration.

You can change name, theme, auto-reply mode, and other settings. Only provided fields will be updated.

Use this when user wants to modify their chat widget settings.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoNew name for the widget
positionNoWidget position on screen. OMIT to leave the position unchanged.
is_activeNoEnable or disable the widget. OMIT to leave the active flag unchanged.
widget_idYesID of the widget to update
allow_voiceNoMaster switch for voice on this widget — set true to show the mic and let visitors talk to the agent. Everything else voice-related (greeting, button label, STT/TTS from the agent's own config) is inert until this is on. The mic also needs a voice-capable agent in the workspace: one with an enabled incoming_call trigger. OMIT to leave the setting unchanged.
website_urlNoWebsite URL for product/site search integration
calendly_urlNoBooking URL for calendar action (e.g., 'https://calendly.com/yourname')
color_schemeNoWidget color scheme. 'auto' follows the visitor's OS dark/light mode preference. OMIT to leave the color scheme unchanged.
display_modeNoVisual mode of the widget. Pick exactly one: - 'chat': full chat panel + voice mic — default for support / sales / general. - 'voice_only': mic-only bubble that launches a voice call directly — pick only when the user explicitly asks for a voice-only widget. - 'headless': no UI; customer drives via window.DialogBrain JS API — pick only when the user explicitly says 'embed in our own design'. OMIT to leave the display mode unchanged.
header_titleNoTitle shown in chat header
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
greeting_textNoCustom greeting message shown when visitor opens the chat (e.g., 'Hello! How can I help you today?')
primary_colorNoPrimary color for widget theme (hex, e.g., '#2563eb'). Paints the header, the visitor's message bubbles and the send button — and the launcher bubble too unless launcher_color overrides it.
launcher_colorNoColor of the closed launcher bubble ONLY (hex, e.g., '#ffffff'). Use when the site pairs a light button with a dark panel and one colour cannot express both. Pass an empty string to clear it and let the launcher follow primary_color. Text and glyphs pick themselves from the background, so a light value stays readable.
voice_greetingNoSpoken opening line when a visitor starts a voice call through this widget. Played via TTS before the AI model runs. Empty string disables the greeting. Requires allow_voice=true to be audible.
allowed_domainsNoList of allowed domains for the widget
auto_reply_modeNoAuto-reply mode: 'draft' or 'auto'. OMIT to leave the auto-reply mode unchanged.
header_subtitleNoSubtitle shown in chat header
greeting_enabledNoEnable or disable the proactive greeting. OMIT to leave this flag unchanged.
greeting_behaviorNonotification = show badge after delay; auto_open = open widget automatically after delay; on_open = greet only when visitor manually opens. OMIT to leave the greeting behavior unchanged.
enable_form_actionNoEnable or disable the contact form action button. OMIT to leave this flag unchanged.
voice_button_labelNoLocalized aria-label and hover tooltip for the voice-only mic bubble (only used when display_mode='voice_only'). ≤ 100 chars. Defaults to 'Talk to agent' if not set.
contact_form_fieldsNoFields to collect in contact form (e.g., ['name', 'email', 'phone'])
enable_search_actionNoEnable or disable the search action button. OMIT to leave this flag unchanged.
show_visitor_historyNoShow full chat history to returning visitors. OMIT to leave this flag unchanged.
identification_fieldsNoFields to require for visitor identification (e.g., ['name', 'email'])
enable_calendar_actionNoEnable or disable the calendar booking action button. OMIT to leave this flag unchanged.
greeting_delay_secondsNoDelay in seconds before the proactive greeting appears (0–300). 0 = send immediately on page load. Default: 30.
require_identificationNoRequire visitor to identify before chatting. OMIT to leave the identification policy unchanged.
returning_greeting_textNoGreeting for returning visitors who already have chat history (e.g., 'Welcome back! How can I help you today?'). Falls back to greeting_text if not set.
max_voice_duration_secondsNoHard cap on a single voice call from this widget, in seconds (default 300). OMIT to leave the cap unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
+  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
+  "type": "integer"
+}
  2. Added
  3. Removed
  4. Changed3 schema fields changed
    • addedInput schema / properties / allow_voice
      Added value: +{
+  "description": "Master switch for voice on this widget — set true to show the mic and let visitors talk to the agent. Everything else voice-related (greeting, button label, STT/TTS from the agent's own config) is inert until this is on. The mic also needs a voice-capable agent in the workspace: one with an enabled incoming_call trigger. OMIT to leave the setting unchanged.",
+  "type": "boolean"
+}
    • addedInput schema / properties / max_voice_duration_seconds
      Added value: +{
+  "description": "Hard cap on a single voice call from this widget, in seconds (default 300). OMIT to leave the cap unchanged.",
+  "type": "integer"
+}
    • changedInput schema / properties / voice_greeting / description
      Previous value: -"Spoken opening line when a visitor starts a voice call through this widget. Played via TTS before the AI model runs. Empty string disables the greeting."New value: +"Spoken opening line when a visitor starts a voice call through this widget. Played via TTS before the AI model runs. Empty string disables the greeting. Requires allow_voice=true to be audible."
  5. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already indicate a non-destructive, non-idempotent, non-read-only update. The description adds a useful contextual detail: 'Only provided fields will be updated' (partial update semantics). However, it omits other relevant behavioral aspects such as required permissions, side effects, or response format. Since annotations cover the safety profile, this partial disclosure is adequate but not thorough.

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 concise, front-loading the core action (update widget configuration) in the first sentence, followed by scope and usage context. No superfluous information, though it could be slightly more structured.

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?

For a 31-parameter update tool with full schema documentation, no output schema, and clear annotations, the description provides the essential high-level purpose and partial-update behavior. It is largely complete given the rich structured data, though it could include more on permissions or side effects.

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

Parameters3/5

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

The input schema fully documents all 31 parameters with comprehensive descriptions, enums, and OMIT semantics. The description only lists a few example fields ('name, theme, auto-reply mode, and other settings') without adding any new semantic insight. With 100% schema coverage, the description meets the baseline of 3 by not contradicting or degrading parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states a specific verb (update) and resource (livechat widget configuration) and directly names which fields can be modified. Does not explicitly differentiate itself from sibling tools like widgets_create or widgets_delete, but the purpose is otherwise unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a single usage cue ('Use this when user wants to modify their chat widget settings'), which is helpful but vague. It does not specify when to choose this tool over alternatives such as widgets_create or when not to use it. There is no mention of prerequisites like widget ownership.

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

All dialogbrain toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources