Skip to main content
Glama

Update widget

update_widget
Destructive

Change a widget. Only the fields sent are changed, with one exception: sending ANY of questions, quizQuestions, quizTiers or calcInputs replaces ALL FOUR with exactly what is sent, so send the complete set you want to end up with. Publishing is a separate action. Views and completions cannot be set — they are counted from real traffic. The result lists issues — what is still missing before it could go live. What each kind needs (send only name and kind and the rest starts from sensible defaults): lead-magnet — headline, description, buttonText, contentUrl (a link to the file), optional questions; type "ai" personalises the delivery and needs at least one question. popup — headline, description, buttonText, plus trigger (immediate | exit-intent | scroll | time) with triggerValue (seconds for time, percent for scroll) and placement (center | bottom-right | bottom-left | top-right | top-left); a popup defaults to a time trigger of 8 seconds. For more than one condition, or a click/hover trigger, send triggers (an array of {type: immediate | exit-intent | scroll | time | click | hover, value, selector}; selector is a CSS selector on the host page, only meaningful for click/hover) with triggerMode "any" (the default — opens on the first one met) or "all" (waits for every one). startAt/endAt (epoch milliseconds) bound when a widget runs at all; leave both unset to run with no date limit. survey — questions, each {text, type: short | long | single | multi, options: [] (labels, only for single and multi)}; asks for an email afterwards only if requireEmail is true. quiz — quizQuestions [{text, options: [{label, score}]}] with at least two options each, and quizTiers [{minScore, maxScore, label, message}]; the visitor's total is the sum of the chosen options' scores, and the tiers must cover every possible total from the lowest to the highest with no gap. calculator — calcInputs [{label, min, max, step, default}] (integers), calcFormula using the inputs BY POSITION as a, b, c… with + - * / and brackets (e.g. "a * b * 12"), and calcOutputTemplate where {{result}} is replaced by the answer (e.g. "You could save ${{result}} a year"). announcement-bar — barMessage, barCtaText (the link label), barCtaUrl, barPosition (top | bottom). Popups and bars load sitewide from the one install snippet and can be kept off pages: hideOnValue lists URL pieces they never show on (e.g. "/checkout, /thank-you"), and showOn "url" with showOnValue limits them to pages whose URL contains one of the pieces; showOn "all" is every page. Style is optional and inherits the account's brand when omitted: theme, accentColor, backgroundColor, textColor (hex), cornerStyle, logoUrl.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo
nameNo
typeNo
endAtNo
themeNo
layoutNo
showOnNo
articleNo
logoUrlNo
projectNoA project id from list_projects. Runs this call in that project instead of the connection default.
startAtNo
subjectNo
triggerNo
headlineNo
positionNo
triggersNo
widgetIdYes
barCtaUrlNo
emailBodyNo
firstStepNo
placementNo
questionsNo
quizTiersNo
textColorNo
barCtaTextNo
barMessageNo
buttonTextNo
calcInputsNo
contentUrlNo
popupWidthNo
rewardCodeNo
rewardTypeNo
senderNameNo
accentColorNo
barPositionNo
buttonStyleNo
calcFormulaNo
consentTextNo
cornerStyleNo
descriptionNo
emailFormatNo
hideOnValueNo
showOnValueNo
triggerModeNo
cooldownDaysNo
hookQuestionNo
requireEmailNo
triggerValueNo
audienceRulesNo
maxDismissalsNo
quizQuestionsNo
rewardPercentNo
wheelSegmentsNo
floatingButtonNo
questionRoutesNo
successMessageNo
backgroundColorNo
successHeadlineNo
calcOutputTemplateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior5/5

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

The description discloses critical update behavior beyond the annotations: only sent fields are changed, except that sending questions, quizQuestions, quizTiers, or calcInputs replaces all four as a complete set. It also explains that publishing is separate, views/completions are traffic-derived, and the result includes an `issues` list. These details are highly valuable for a destructive/update tool.

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

Conciseness3/5

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

The most important rule—partial update plus the four-array replacement exception—is front-loaded. However, the remaining content is a dense block of text without structural grouping, and for a 59-parameter tool the lack of headings or bullets makes it harder to scan.

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?

For a complex 59-parameter update tool with almost no schema descriptions, the description covers the main widget kinds and critical mutation behavior well. It is not fully complete: many optional parameters are absent, and while it mentions the `issues` result, there is no output schema to clarify return structure.

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 description coverage is only 2% across 59 parameters, so the description must carry most parameter meaning. It does this well for the core and kind-specific fields, including trigger/triggers semantics, quiz tier coverage, calculator formula positional references, and URL show/hide behavior. It still leaves many optional parameters (e.g., layout, article, reward fields, routing fields) unexplained.

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 begins with a specific verb and resource: "Change a widget." It also clarifies important boundaries, such as publishing being a separate action and views/completions being read-only, which helps distinguish it from sibling actions. However, it does not explicitly contrast itself with create_widget or read_widget.

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 gives substantial per-kind guidance for what fields each widget type needs and says to send only name and kind to rely on defaults. It also notes that publishing is separate and views/completions cannot be set. It stops short of explicitly saying when to use update_widget versus create_widget/read_widget/request_widget_publish.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.