Skip to main content
Glama
Tobias-Conrad

WebinarIgnition MCP Server

by Tobias-Conrad
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

WebinarIgnition MCP Server

MCP Badge

Build and run WordPress webinars from a chat. One MCP server that puts WebinarIgnition inside any AI assistant — Claude, ChatGPT, Cursor and any MCP-capable client.

  • Endpoint: https://mcp.webinarignition.com/?src=registry

  • Transport: Streamable HTTP, MCP protocol 2025-06-18 (JSON-RPC 2.0)

  • Auth: none. No sign-in, no API key, no install.

  • Website: https://webinarignition.com

About this repository. This is the public source mirror of the hosted WebinarIgnition MCP server (https://mcp.webinarignition.com). Two internal modules are intentionally not part of the mirror — the live-pricing reader and the product knowledge service — so the supported way to use the server is the hosted endpoint above. Everything else (MCP transport, funnel session engine, WordPress connection flow, outbound channel) is included.

Install

Remote MCP server (Streamable HTTP, no auth): https://mcp.webinarignition.com/?src=registry. Agents: see llms-install.md for the exact steps.

Related MCP server: wordpress-mcp

Tools

mcp.so and other directories read this section. Listed below is what the connector exposes, and beneath it what the connected WordPress site offers.

Connector tools (always available)

Tool

What it does

Kind

wi_webinar

Plan, write and set up a webinar from a chat: topic, title, invitation emails, reminders, registration page, live room, evergreen funnel. Also answers product questions. Selects the step with was.

write

wi_webinar_delete

Delete or replace something on the connected WordPress site. Irreversible.

destructive

wi_webinar is a single entry point with guided steps (was): start (entry), thema (topic), weiter (continue), texte (write the texts), seite (build the page), verbinden (connect a WordPress site), faehigkeiten (what the site can do), ausfuehren (run a site ability), fragen (product questions), alles, ready.

Site tools (offered by the connected WordPress site)

Once a WordPress site is connected, the connector exposes 71 tools across 11 areas. They are read live from the site, so the list always matches the installed version.

Area

Count

Examples

webinar

15

wi_list_webinars, wi_get_webinar, wi_create_webinar, wi_funnel_stats, wi_run_preflight

config

14

wi_configure_webinar, wi_woo_offer_in_room, wi_configure_100ms, wi_configure_daily, wi_write_invite_texts

control

10

wi_master_switch, wi_room_switch, wi_list_questions, wi_answer_question, wi_get_prompter

gutenberg

6

wi_reg_page_blocks, wi_reg_page_edit, wi_media_search, wi_repair_registration_pages

mail

6

wi_get_emails, wi_check_mail, wi_send_test_email, wi_resend_renotifications

webhook

6

wi_list_webhooks, wi_upsert_webhook, wi_send_test_webhook, wi_read_webhook_history

leads

5

wi_list_leads, wi_export_leads, wi_import_leads_csv

colors

3

wi_get_colors, wi_update_colors, wi_sample_brand_colors

autoresponder

2

wi_set_autoresponder, wi_test_autoresponder

settings

2

wi_list_settings, wi_list_step_types

report

2

wi_list_report_types, wi_get_reports

What the tools do to your site

Every site tool is labelled, so an assistant — and you — can tell them apart before anything runs:

  • 28 read-only — lists, checks and reports. Nothing is touched. (wi_list_webinars, wi_get_webinar, wi_funnel_stats, wi_check_mail, wi_run_preflight, …)

  • 35 change something — creating, editing, publishing, sending. Each one is confirmed first. (wi_create_webinar, wi_configure_webinar, wi_set_autoresponder, wi_master_switch, wi_woo_offer_in_room, …)

  • 8 delete or reset — irreversible. (wi_delete_campaign, wi_delete_lead, wi_delete_all_leads, wi_reset_funnel, wi_delete_logs, wi_delete_webhook, wi_delete_all_questions, wi_import_hc_campaign)

Nothing changes on your site without your OK. A tool in the control scope requires explicit confirmation; the host may grant it once when connecting, otherwise it is asked on every call. Every write is snapshotted and audited.

Architecture

AI client (Claude / ChatGPT / Cursor / …)
    │
    └── WebinarIgnition MCP Server   https://mcp.webinarignition.com
            │
            ├── writes and reads webinars (connector, no site needed)
            │
            └── connected WordPress site → the real webinar, on your own hosting

Two doors exist by design, and both are optional:

  1. Connector only — plan the webinar, write the title, invitation emails and reminders, produce the registration copy. Works with no WordPress at all.

  2. Connected site — connect a WordPress site that runs WebinarIgnition, and the assistant builds the real thing: registration page, live room, evergreen schedule, WooCommerce offer in the room.

Connecting

Add the URL in your assistant's MCP settings:

https://mcp.webinarignition.com/?src=registry

In Claude: Settings → Connectors → Add custom connector, paste the URL, leave everything else as it is, save. Then open a new chat and write: "Build me a webinar for freelancers."

Works the same in Cursor, Claude Code, ChatGPT and any other assistant that speaks MCP.

The WordPress side is connected from inside the plugin (WebinarIgnition → AI connection), which returns a link the host opens in the browser to approve. No inbound access to the WordPress site is required — it polls the connector, so it also works behind a firewall or on shared hosting.

Sources

Directories list their own endpoint URL with an attribution parameter:

Source

URL

MCP Registry

https://mcp.webinarignition.com/?src=registry

Smithery

https://mcp.webinarignition.com/?src=smithery

mcp.so

https://mcp.webinarignition.com/?src=mcpso

Glama

https://mcp.webinarignition.com/?src=glama

mcpbeat

https://mcp.webinarignition.com/?src=mcpbeat

Health

  • GET /health — service status

  • GET /.well-known/mcp/server-card.json — published capability card

  • GET /openapi.json — HTTP schema

Links

Available Tools

2 tools
wi_webinarWebinarIgnitionAInspect

Plan, write and set up a webinar from a chat, and answer questions about WebinarIgnition. It picks a topic, produces the title, the invitation emails, the reminders and the registration page, and prepares the live, automated or evergreen room on the user's own WordPress site. Needs no sign-in. Returns JSON. was selects the step: • start — entry point; returns a question with tappable options. • thema — starts a conversation from the user's text; needs text. • weiter — continues a conversation; needs session_id and text. A result with ready=true means the texts can be written next with was=texte. • texte — writes the finished texts for a ready session; needs session_id. Optional: job_id to poll a running job, direction for an angle, skip_direction, invite_type (list, personal, facebook, whatsapp, instagram, linkedin, telegram, youtube), or type="custom" with custom_channel for any other channel. • stand — returns what the session has collected so far; needs session_id. • seite — checks a WordPress address for WebinarIgnition; needs url; returns state, next_action and next_url. • verbinden — connects the chat to the user's own WordPress; the first call needs session_id and url and returns a connect_url that the user opens in their own browser; a later call without url reports whether it went through. • faehigkeiten — lists the abilities of the connected site; needs session_id. • ausfuehren — runs one ability on the connected site; needs session_id, tool and args. Destructive abilities are not run here; the answer points to wi_webinar_delete. • trennen — drops the connection; needs session_id. • handoff — returns a handover link carrying the collected data; needs session_id (or known_facts/content), optional url. • technik — returns the setup plan without a connected site. • frage — answers a product question (prices, limits, integrations); needs text. • status — technical state of the connector. Returns { error, message } when a required field is missing, and { question } when the user has choices to make.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoThe WordPress address (seite). With was=handoff: the host's WordPress address to point the handover link at.
wasYesWhich step to run.
argsNoOnly with was=ausfuehren: the arguments for that ability, shaped by its input_schema.
textNoWhat the host said (thema · weiter) or the question in the host's language (frage).
toolNoOnly with was=ausfuehren: the ability name exactly as was=faehigkeiten reported it, e.g. webinarignition_create_webinar. Slashes and hyphens are accepted too, but the site publishes underscores.
typeNoOnly with was=texte: 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.
focusNoOnly with was=start: what it should be about.
wantsNoOnly with was=start: what the host wants, as short keywords (e.g. "thema", "texte", "technik").
has_wiNoOnly with was=start: true when WebinarIgnition is already installed on the host's site.
job_idNoOnly with was=texte: 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.
ratingNoOnly with was=handoff: the host's rating (1-10), if any.
contentNoOnly with was=handoff: finished text to carry over, if the session alone does not hold it.
has_mcpNoOnly with was=start: true when the host already uses an MCP/connector — the connector normally sets this itself.
languageNoThe language the host writes in.de
directionNoOptional with was=texte: 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.
situationNoOnly with was=start: what the host just said.
session_idNoFrom an earlier turn (weiter · texte · stand).
invite_typeNoOnly with was=texte, 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.
known_factsNoEverything you already know — send it every turn so nothing is lost on a restart.
has_wordpressNoOnly with was=start: true when the host already has a WordPress site.
custom_channelNoOnly with was=texte 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_directionNoOnly with was=texte: true when the host wants NO special angle — then it generates without an angle.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important behaviors: no sign-in required, JSON returns, error and question response shapes, the two-phase verbinden flow, the ready=true handoff between steps, and the single-running-text-job constraint. It adds substantive behavioral context without contradicting the annotations.

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?

The description is long but densely packed and well-structured: a one-sentence overview, then a scannable bullet list for each 'was' step. Every clause earns its place, and the front-loaded summary helps the agent orient before diving into the state details.

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 22-parameter, 14-state tool, the description is unusually complete: it covers entry points, continuation, text generation, WordPress connection, capability execution, disconnection, handoff, fallback planning, product questions, and status. The presence of an output schema further reduces the need to describe return values, though the description already covers the main response shapes.

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 the baseline is 3. The description adds value above the schema by explaining step-specific dependencies, the intended state-machine flow, the custom-channel rule, and how job_id polling works. It does not merely repeat schema text; it organizes the parameters into a usable workflow.

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 names a specific verb-resource pairing: plan, write, and set up a webinar, and answer WebinarIgnition questions. It clearly distinguishes from the only sibling, wi_webinar_delete, by stating that destructive abilities are not run here and the answer points to the delete tool.

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?

The 'was' state machine gives explicit when-to-use guidance for each step, including required and optional parameters. It also provides an exclusion rule: destructive abilities are not executed here and route to wi_webinar_delete. This is actionable selection guidance, not just a summary.

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

wi_webinar_deleteWebinarIgnition — deleteA
Destructive
Inspect

Delete or replace something on the connected WordPress site — irreversible. Runs only an ability that is verified as destructive: delete a campaign, a webhook, registrants (single or all), the logs, the attendee questions, or the HC import that replaces a campaign. Writes abilities are not run here; use wi_webinar with was="ausfuehren" for those. Needs session_id and tool, optional args. Returns JSON.

ParametersJSON Schema
NameRequiredDescriptionDefault
argsNoThe arguments for that ability, shaped by its input_schema.
toolYesThe destructive ability name exactly as was="faehigkeiten" reported it, e.g. webinarignition_delete_campaign or webinarignition_delete_webhook. Slashes and hyphens are accepted too, but the site publishes underscores.
session_idYesThe conversation id from an earlier turn — the session whose WordPress site is connected.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, and the description adds meaningful detail: operations are irreversible, only verified destructive abilities run, writes are excluded, and the concrete targets are listed. This is consistent with the annotations, so there is no contradiction.

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?

The description is dense and front-loaded, starting with the irreversible nature before enumerating scope, giving the alternative tool, and ending with invocation requirements. Every sentence earns its place given the tool's complexity.

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?

Given the output schema, full parameter documentation, and annotations, the description is complete enough. It adds the return format, destructive scope, and routing guidance, so an agent has everything needed to select and invoke the tool correctly.

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 the baseline is 3. The description merely restates that session_id and tool are required and args is optional, which adds little beyond what the input schema already provides.

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?

States a specific verb and resource: delete or replace something on the connected WordPress site, and enumerates the exact destructive targets. It clearly distinguishes itself from sibling wi_webinar by limiting itself to destructive operations.

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?

Explicitly states that writes abilities are not run here and directs the agent to wi_webinar with was="ausfuehren" for those. It also defines the tool's scope as verified destructive abilities, making the choice between siblings unambiguous.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.6
    • First observedwi_webinar
    • First observedwi_webinar_delete
Deploy Server
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

TDQS

A4.6/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: wi_webinar handles all non-destructive planning, setup, connection, and ability execution, while wi_webinar_delete is explicitly restricted to destructive deletion/replacement abilities. The boundary is reinforced by the description of wi_webinar, which points to wi_webinar_delete for destructive operations.

Naming Consistency4/5

Both tools share a consistent 'wi_webinar' prefix, which ties them to the domain. However, the main tool is named as a bare noun (wi_webinar) rather than following a verb_noun pattern like its counterpart (wi_webinar_delete), a minor deviation from ideal consistency.

Tool Count3/5

With only two tools for a broad domain (webinar planning, writing, WordPress connection, ability execution, deletion, Q&A, handoff), the surface feels thin. While consolidating many actions into a single parameterized tool is a valid design choice, the low count borders on under-provisioned.

Completeness4/5

The tools cover the full lifecycle: planning, content generation, site connection, running non-destructive abilities, destructive deletion/replacement, handoff, and technical status. Minor gaps exist (e.g., no explicit list or update tools, though abilities likely fill these), but the core workflows are well represented.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • wordpress-mcp

    cvrt-jh
    A
    license
    C
    quality
    B
    maintenance
    Enables AI-powered WordPress management via MCP, with 158 tools for posts, pages, media, plugins, themes, users, comments, and more, plus token-optimized responses.
    277
    1,128 npm
    3
    MIT

  • WordPress MCP Server

    InstaWP
    F
    license
    Not graded
    quality
    F
    maintenance
    Enables AI assistants to interact with a WordPress site, allowing content and taxonomy management (list, create, update, delete) through 17 MCP tools.
    2
    -