Skip to main content
Glama

Create widget

create_widget
Destructive

Create a widget in the current project. Six kinds: lead-magnet, popup, survey, announcement-bar, quiz, calculator. It is always created as a draft, and the result lists issues — what is still missing before it could go live (empty when nothing is); fix them with update_widget. Going live is a separate step, request_widget_publish. 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
kindYes
nameYes
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
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

A4.7/5.0
Behavior5/5

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

Beyond the annotations, it discloses key behavior: widgets are created as drafts, the result includes an issues list for missing go-live requirements, publishing is a separate step, defaults apply when fields are omitted, and popups/bars load sitewide unless URL rules are supplied. This is rich behavioral context for a create tool.

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 long but appropriately front-loaded: it starts with creation, draft state, issues, and publish separation before going into per-kind requirements. The dense single-paragraph format makes it harder to scan, but most sentences add necessary detail for a 58-parameter tool.

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 no output schema, sparse annotations, and minimal schema descriptions, the description is unusually complete for the main creation workflow and per-kind requirements. It still leaves gaps for advanced optional parameters and only briefly mentions the returned issues list rather than the full result shape.

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?

With only 2% schema description coverage, the description carries most parameter meaning and does so well for core and kind-specific fields, including nested shapes, defaults, enum-like choices, and formulas. However, many of the 58 parameters, such as layout, article, firstStep, popupWidth, reward fields, audienceRules, and questionRoutes, are not explained.

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 opens with a specific verb and resource: 'Create a widget in the current project.' It also identifies the six widget kinds and explicitly distinguishes this operation from update_widget and request_widget_publish, so an agent can separate it from sibling tools without inspecting schemas.

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?

It explicitly routes post-creation fixes to update_widget and publishing to request_widget_publish, and explains that creation is always draft-only. It also tells the agent it can send only name and kind while the rest defaults, which is clear usage guidance.

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.