WebinarIgnition

Write the webinar texts

wi_write_webinar_invitation_emails

Writes the finished webinar texts for a session that is ready: title, invitation email, reminders and the registration copy. Side effect: it starts a text-generation job on the connector (about a minute) and stores the result in the session; nothing is published to a WordPress site and no email is sent to anyone. Needs session_id. A second call with the returned job_id reads the job's state until the texts are there. Optional: invite_type for one of the eight built-in channels, type="custom" with custom_channel for any other channel, direction for an angle or skip_direction for none.

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_write_webinar_invitation_emails"
  }
}

Input Schema

Name	Required	Description	Default
`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.
`type`	No	invites (default), starter, or custom. custom = the invitation is for a channel that is NOT one of the eight built-in platforms — pass the channel name in custom_channel. A channel outside the eight built-ins is written as custom, not as one of the eight.
`job_id`	No	the job number from an earlier call, to check whether the texts are ready. Without job_id a new job is started; only one text job runs at a time.
`language`	No	The language the host writes in.	de
`direction`	No	Optional with this call: the angle/framing of the invitation (natural language), e.g. 'Zeitersparnis und Skalierung ohne neue Mitarbeiter' for an agency. If missing, the invitation is written at once without a special angle.
`session_id`	No	From an earlier turn (weiter · texte · stand).
`invite_type`	No	Only with this call, when the invitation is for a specific platform: list = email list, personal = personal message, facebook = Facebook post, whatsapp = WhatsApp status, instagram = Instagram post, linkedin = LinkedIn post, telegram = Telegram channel, youtube = YouTube post.
`custom_channel`	No	Only with this call and type="custom": the exact name of the channel or format the invitation is for when it is not one of the eight built-in platforms — e.g. Xing, WeChat, Line, KakaoTalk, Viber, Threads, Mastodon, a guest article, or the host's own format. The text is then written for exactly this channel, not for a built-in platform.
`skip_direction`	No	true when the host wants NO special angle — then it generates without an angle.

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 20, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Discloses exactly the traits annotations cannot convey: an async text-generation job on the connector lasting about a minute, results stored in the session, and the reassurance that nothing is published to WordPress and no email is sent. Combined with the annotations (destructiveHint=false), this fully explains what the call does and does not touch.

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

Conciseness5/5

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

Front-loads the purpose, then the side effect and timing, then the job-polling pattern, then the optional knobs. Every sentence carries information an agent needs to decide and to sequence the call.

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?

Covers purpose, side effects, timing, required input, follow-up flow and optional parameters, and an output schema exists so return values need not be described. The only missing piece is explicit disambiguation against the sibling text-writing and text-editing tools in a large tool set.

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 parameter documentation is already complete; the description nonetheless adds the relational semantics that type='custom' must be paired with custom_channel and that direction vs skip_direction are mutually exclusive alternatives. That is genuine added meaning beyond the per-field descriptions, though most of the prose restates the schema.

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?

States a concrete verb and resource plus the exact artifact set produced: title, invitation email, reminders, registration copy, scoped to a session that is ready. It is distinguishable from neighboring edit/rewrite tools by making clear this generates finished texts rather than modifying existing ones, though it never names those siblings.

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?

Gives the precondition ('session that is ready'), the required input (session_id) and the follow-up pattern (second call with returned job_id polls until texts are there). It does not explicitly say when to prefer this over wi_rewrite_webinar_texts or wi_change_webinar_text, so the alternative-selection guidance is implied rather than stated.

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.