WebinarStack

Clone Webinar with New Schedule

webinarstack.workflows.clone_with_new_schedule

Duplicate a webinar with a fresh schedule while preserving branding, content, and non-webhook automations in one call. Clones the source webinar, re-creates its email, integration, webhook and Meta Pixel event automations (webhook-subscription automations are excluded), and applies the new schedule. Meta Pixel event (meta_capi) rules are copied as-is (same pixel, event, custom data and enabled state) when the account is on the Growth plan and the pixel still exists; otherwise that rule alone is not copied and is listed in skippedAutomations with its reason code — other automations still clone. Segment/branch-scoped automations are re-created as global (non-segment-scoped) on the clone — segments get fresh IDs in the clone and there is no remap pass (v1.29 limitation). Cloned webhook automations receive a NEW signing secret rather than the source rule's; a receiver verifying signatures must be updated with the clone's secret, copyable from the dashboard automation editor. Returns { webinarId, sourceWebinarId, registrationUrl, sessionCount, automationCount, skippedAutomationCount, skippedAutomations, steps }.

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": {
      "webinarId": "<webinarId>",
      "schedule": "<schedule>"
    },
    "name": "webinarstack.workflows.clone_with_new_schedule"
  }
}

Input Schema

Name	Required	Description
`name`	No	Optional display name for the clone (defaults to source title + "-copy")
`schedule`	Yes	New schedule to apply to the clone — required (otherwise just use :duplicate)
`webinarId`	Yes	ID of the source webinar to clone

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description adds substantial behavior beyond the annotations: webhook-subscription automations are excluded, Meta Pixel rules depend on plan and pixel existence, skipped rules are reported with reasons, segment-scoped automations become global, and webhook automations receive a new signing secret. It also describes the return object.

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?

The purpose and main effect are front-loaded, and nearly every sentence carries specific operational constraints. The description is necessarily dense for the complexity, though some clauses are long and could be more scannable.

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 mutation behavior, plan-dependent automation cloning, segment limitation, webhook secret rotation, skipped-automation handling, and lack of an output schema, the description is complete. It explicitly documents the return shape and the main edge cases an agent needs to know.

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 description coverage is 100%, so the schema already documents webinarId, name defaulting, and the required schedule variants. The description does not add further parameter-level meaning such as schedule syntax or constraints beyond what the schema 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?

The description states a precise verb, resource, and scope: duplicate a webinar with a fresh schedule while preserving branding, content, and non-webhook automations in one call. It clearly distinguishes this operation from schedule updates and individual automation edits.

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?

It makes the use case clear: cloning with a new schedule in one call, with the schedule parameter noting that otherwise :duplicate should be used. It does not explicitly contrast against all relevant siblings such as update_schedule, but the context is sufficiently clear.

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

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

Resources

Need Help?