WebinarIgnition

Rewrite the webinar texts after the facts changed

wi_rewrite_webinar_texts

Destructive

Rewrites the campaign's own texts around facts that already changed, and only the parts you picked: the copy on the registration page and the emails. Take it when a date or a name moved and several lines still carry the old facts. A host says: "The whole page still talks about March, make it fit the new date." It needs the session, the webinar and the parts to rewrite. Without a clear yes nothing is written; the answer is a preview of which parts would change, one line each, so the host can pick. With the yes the picked parts are rewritten and the rest stays exactly as it was. The thank-you page, the webinar name and the room info text are not written here; a single wording is better changed with wi_change_webinar_text. Side effect: it acts on your connected WordPress site; nothing else is touched. Words hosts use: rewrite the page, texts out of date, fix all the dates, refresh the copy

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": {
      "targets": "<targets>"
    },
    "name": "wi_rewrite_webinar_texts"
  }
}

Input Schema

Name	Required	Description
`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.
`topic`	No	The topic, if it changed and the new copy should know it.
`confirm`	No	true actually rewrites the chosen parts. Leave it out to get the preview first and let the host pick.
`targets`	Yes	Which parts to rewrite: the registration page copy, the emails, or all of them. These are the only parts this tool can write.
`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.
`primary_goal`	No	What should be different for the participants afterwards, if that changed.
`target_audience`	No	Who the webinar is for, if that changed.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026

changedInput schema / properties / targets / description

Previous value: -"Which parts to rewrite: registration page copy, thank-you page, the emails, the title, the room info text, or all of them."New value: +"Which parts to rewrite: the registration page copy, the emails, or all of them. These are the only parts this tool can write."

changedInput schema / properties / targets / items / enum

Previous value: -[
-  "registration",
-  "thankyou",
-  "mails",
-  "title",
-  "room",
-  "all"
-]New value: +[
+  "registration",
+  "mails",
+  "all"
+]

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.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, and the description adds the key behavioral gate: without confirm nothing is written and the answer is a per-line preview, while with confirm only the picked parts change and everything else stays exactly as it was. It also names the side effect (acts on the connected WordPress site, nothing else touched). It stops short of saying whether a rewrite can be undone or what happens on partial failure.

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?

Purpose, trigger, preview/confirm behavior, exclusions and side effect are all front-loaded in a logical order. It runs long and includes a host quote plus a trailing vocabulary line; both aid routing, but the passage is denser than strictly necessary.

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

Completeness5/5

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

For a destructive multi-parameter write with an output schema available, the description covers the prerequisites, the preview-versus-write protocol, the exact scope of what is and isn't written, the sibling alternative, and the site side effect. Nothing an agent needs in order to call it safely is missing.

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 coverage is 100%, so all eight parameters are already documented in the schema. The description only adds that it 'needs the session, the webinar and the parts to rewrite', which loosely signals the essential inputs but adds no format or selection semantics beyond the schema, so the baseline of 3 applies.

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+resource: it rewrites the campaign's own texts (registration page copy and emails) around facts that already changed, and only for the parts picked. It explicitly contrasts with sibling wi_change_webinar_text for a single wording, so an agent can distinguish it without opening any schema.

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 states when to take it ('a date or a name moved and several lines still carry the old facts'), gives a concrete host utterance as a trigger, and names exclusions (thank-you page, webinar name, room info) with the alternative tool to use instead. When/when-not/alternative are all present.

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.