WebinarIgnition MCP Server

WebinarIgnition — delete

wi_webinar_delete

Destructive

Delete or replace WebinarIgnition campaigns, webhooks, registrants, logs, attendee questions, or HC imports on a connected WordPress site; requires a session ID and is irreversible.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`args`	No	The arguments for that ability, shaped by its input_schema.
`tool`	Yes	The 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_id`	Yes	The conversation id from an earlier turn — the session whose WordPress site is connected.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.6Oct 4, 2026

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.

Deploy Server