WebinarStack

Get Widget Style

webinarstack.webinars.widget_style_get

Read-onlyIdempotent

Read a tenant-owned webinar's widget style: the draft style, the published style that is live, and updatedAt. This changes the widget's style object only. It is not page-builder authoring: it cannot add, remove or edit blocks or form fields. Writable in this version: host.modalWidth (integer 320-1200) and host.triggerColor, plus the form options: surface (bg, maxWidth, borderWidth, borderColor, radius, shadow, padding), typography (headingFont, bodyFont, headingScale, headingWeight, align), header (logoPlacement, kickerStyle, trustStyle), fields (labelStyle, fieldStyle, fieldBorder, fieldRadius, fieldSize, fieldBg), button (buttonStyle, buttonShape, buttonWidth, buttonSize, buttonIcon, buttonColor), session picker (sessionStyle), countdown (countdownStyle) and layout (blockSpacing, blockTitle). Colour values accept hex (#rgb, #rrggbb), rgb() or rgba(), and some colours also take a keyword (bg: transparent, borderColor: auto, fieldBg: auto or translucent). An absent headingFont or bodyFont follows the webinar theme font. null removes an option so it falls back to its default. Options for the modal chrome and the trigger button (Phase 231) and for the surface kind, colour scheme, text tone, layout and panel (Phase 233) return 'not yet available'.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "webinarId": "<webinarId>"
    },
    "name": "webinarstack.webinars.widget_style_get"
  }
}

Input Schema

Name	Required	Description	Default
`webinarId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

C2.1/5.0

Behavior1/5

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

Annotations declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, yet the description says 'This changes the widget's style object only' and then enumerates 'Writable in this version' options for roughly 150 words. An agent reading this would reasonably conclude the tool mutates style settings, directly contradicting the read-only annotation.

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

Conciseness2/5

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

The description is front-loaded correctly with the read behavior, but the bulk of it is a long enumeration of writable style options, colour formats and 'not yet available' phases that belongs to the update tool. For a one-parameter getter this is far oversized, and the irrelevant majority dilutes the one useful sentence.

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

Completeness2/5

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

It does state what is returned, which is needed since there is no output schema. But the description omits anything about the parameter it requires, and the mutation-oriented body misrepresents the tool's contract, so an agent is not equipped to invoke it safely and correctly.

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

Parameters2/5

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

Schema description coverage is 0%, so the single required webinarId parameter is documented only by its type/format/pattern, with no prose meaning. The phrase 'a tenant-owned webinar's widget style' only loosely implies that the parameter selects the webinar; nothing explains scoping, ownership checks, or failure behavior for unknown IDs.

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

Purpose3/5

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

The opening sentence is precise: verb 'Read', resource 'widget style', and the returned pieces (draft style, published style, updatedAt). However, the remaining text describes writable fields, which blurs what the tool actually does, and it never distinguishes itself from the sibling tools widget_style_update and widget_style_publish that it is most easily confused with.

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

Usage Guidelines2/5

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

There is no guidance on when to call this versus widget_style_update or widget_style_publish, and no prerequisite or workflow context is given. The only scoping statement ('It is not page-builder authoring') explains what the style object is not, not when this read tool should be used.

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

All WebinarStack tools Inspect

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

Need Help?