WebinarIgnition

Change the call to action in the webinar room

wi_change_webinar_cta

Destructive

Changes one call to action in the live room: the offer or booking box, its tab name, its text, its button and whether it is shown. For an evergreen webinar it also sets the moment the box appears. Take it when the box should say something else. A host says: "The button text is wrong, and it should show after twelve minutes." It needs the session and the webinar. Leave the slot out to add a new box at the end, or name a slot to change exactly that one and leave the others untouched. It writes on your site and participants see it in the room; nothing else on the campaign changes. Removing a slot deletes the whole box and cannot be undone, so it needs a clear yes. Side effect: it acts on your connected WordPress site; nothing else is touched. Words hosts use: change the button, add an offer box, tab name, show the offer

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "wi_change_webinar_cta"
  }
}

Input Schema

Name	Required	Description
`on`	No	Show this CTA in the room (true) or hide it (false).
`site`	No	Which connected site is meant when this chat has more than one: the address exactly as wi_get_connector_status lists it under sites. Leave it out while only one site is connected.
`slot`	No	Which CTA slot (1, 2, 3). Leave it out to add a new CTA at the end.
`text`	No	The body of the CTA: HTML or shortcodes, e.g. an [advanced_iframe src="..."] for an embedded page.
`width`	No	Overlay box width, e.g. 60% or 500px (overlay only).
`iframe`	No	Show the body inside an iframe.
`remove`	No	true deletes this whole CTA slot. Cannot be undone, needs the host's clear yes.
`timing`	No	Evergreen only: when the CTA appears, as MM:SS after the start, e.g. 20:00.
`confirm`	No	Must be true together with remove, and only after the host said that this CTA may be deleted.
`position`	No	outer is the sidebar tab on the right, overlay lies over the video.
`tab_text`	No	The name of the sidebar tab for this CTA.
`copy_from`	No	Copy this existing slot first, then apply the other fields on top.
`button_url`	No	Where the button goes. An empty string removes the link.
`session_id`	No	From an earlier turn (weiter · texte · stand).
`webinar_id`	No	The webinar (campaign) id, as wi_list_webinars returned it. Never invent an id.
`button_text`	No	The button label. An empty string removes the label, together with button_url it removes the button.
`button_color`	No	Button colour as hex, e.g. #6BBA40.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

addedInput schema / properties / site

Added value: +{
+  "description": "Which connected site is meant when this chat has more than one: the address exactly as wi_get_connector_status lists it under sites. Leave it out while only one site is connected.",
+  "type": "string"
+}

AddedOct 26, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already flag a destructive, open-world write, and the description goes well beyond them: it says the write lands on the connected WordPress site, that participants see the change in the room, that nothing else on the campaign is touched, and that removing a slot deletes the whole box irreversibly and requires a clear yes. That is exactly the extra behavioral context an agent needs before calling a destructive tool, with no contradiction of the hints.

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 core rule about slot omission versus naming a slot is front-loaded, which is good, but the ending repeats itself: 'nothing else on the campaign changes' and then 'Side effect: it acts on your connected WordPress site; nothing else is touched' say the same thing twice. The tool-name keyword list at the end is low-density filler for an agent reader.

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 17-parameter destructive write with an output schema and no required fields, the description supplies the necessary framing: prerequisites, slot semantics, destructive removal, side-effect scope, and evergreen timing. What it omits is minor – how an agent should discover which slots already exist, and how the site parameter interacts with multi-site chats beyond the schema text.

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 coverage is 100%, so 3 is the baseline, and the description still adds real meaning: slot omission appends while naming a slot leaves other slots untouched, confirm must accompany remove, timing applies only to evergreen webinars, and session plus webinar are prerequisites. It stops short of explaining copy_from or the overlay-only nature of width, but the schema carries those.

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 names a specific verb and resource (change a call-to-action in the live room) and enumerates exactly what that CTA contains: tab name, text, button, visibility. It is clear enough to act on, but it does not distinguish itself from the nearby sibling wi_change_webinar_offer, which an agent could easily confuse with the 'offer or booking box' wording used here.

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

Usage Guidelines4/5

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

Usage is stated plainly with a concrete host scenario ('The button text is wrong, and it should show after twelve minutes') plus a clear branching rule: omit slot to append a new box, name a slot to edit exactly that one. What is missing is an explicit when-not-to-use or a named alternative tool for the offer/booking case.

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

All WebinarIgnition 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.