Skip to main content
Glama

dialogbrain

by io.github.saloprj
OverviewDiscussionsAdmin

widgets_create

Create a new livechat widget for your website.

The widget will be created with default settings. You can customize theme, auto-reply mode, and more.

Use this when user wants to add a chat widget to their site.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName for the widget (e.g., 'Website Chat', 'Support Widget')
positionNoWidget position on screenbottom-right
allow_voiceNoMaster switch for voice — set true to show the mic so visitors can talk to the agent. Everything else voice-related 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 voice off (the default).
display_modeNoVisual mode of the widget. Pick exactly one: - 'chat' (default): full chat panel + voice mic — use 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 (e.g. 'just a voice button', 'no chat, just call'). - 'headless': no UI; customer drives via window.DialogBrain JS API — pick only when the user explicitly says 'embed in our own design' / 'no widget chrome'.chat
header_titleNoTitle shown in chat headerChat with us
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
primary_colorNoPrimary color for widget theme (hex, e.g., '#2563eb')#2563eb
auto_reply_modeNoAuto-reply mode: 'draft' (review before sending) or 'auto' (send immediately)draft
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 omitted.

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. Changed1 schema field changed
    • addedInput schema / properties / allow_voice
      Added value: +{
+  "description": "Master switch for voice — set true to show the mic so visitors can talk to the agent. Everything else voice-related 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 voice off (the default).",
+  "type": "boolean"
+}
  5. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, giving a clear safety profile. The description adds that the widget is created with default settings and can be customized later, which is useful context about post-creation behavior. However, it does not disclose any additional traits beyond what annotations provide (e.g., no mention of required permissions or side effects), so it meets but does not exceed expectations.

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 three brief sentences, front-loading the core action ('Create a new livechat widget') and then adding contextual details. It is well-structured and wastes no words, though the third sentence about customization is somewhat redundant with the schema.

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

Completeness3/5

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

Given the tool's simplicity (9 parameters, most optional, no nested objects, no output schema), the description covers the essential purpose and a basic usage scenario. However, it lacks details on what happens on failure, whether the widget is immediately live, or any versioning/undo considerations. It is adequate but not rich enough to be fully self-contained.

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?

Schema description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds no extra parameter semantics; it only vaguely mentions customizable aspects like theme and auto-reply mode, which are already covered in the schema. A baseline score of 3 is appropriate when the schema carries the full semantic load.

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?

The description states a specific verb and resource ('Create a new livechat widget for your website'), making the purpose immediately clear. It is distinguishable from sibling tools like widgets_list, widgets_update, and widgets_get by the create verb, but it adds no explicit differentiation in the text itself.

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?

The description provides a usage scenario ('Use this when user wants to add a chat widget to their site'), which gives context for when to invoke it. However, it does not mention alternatives (e.g., widgets_update for modifying existing widgets) or prerequisites, so it is only minimally adequate.

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