Skip to main content
Glama
Sign In

craft-content-mcp

by io.github.shashwatgtm
OverviewDiscussionsAdmin

Webinar Script

webinar_script
Read-only

Helps you plan a webinar that leads to meetings, from your topic, target audience and webinar type. Optional duration, key takeaways, speakers, polls, product mention level, your product and business model shape it. Returns a run of show, a full spoken script with speaker lines and on screen cues, polls with answer options, likely questions with answers, a follow up email sequence and sector notes. It uses only what you gave and says what it did not get. Ask whether written customer approval covers the exact material and intended use.

Input Schema

NameRequiredDescriptionDefault
topicYesThe webinar topic or title
durationNoThe webinar length
speakersNoOptional: speakers as you want them listed. Separate speakers with semicolons or line breaks ('Name, Title; Name, Title'), or with commas if each is one phrase
your_sectorNoOptional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.
webinar_typeYesThe kind of webinar; sets the structure
your_productNoOptional: your product or service name, used in the answer. Without it the answer says so and shows a placeholder.
include_pollsNoInclude poll suggestions with answer options
key_takeawaysNoOptional: what attendees should learn, one per line, per semicolon or comma-separated. If not provided, takeaways are suggested from the topic
business_modelNoOptional: how you charge, so the advice fits it. If omitted, it is read from your text and the answer says how.
target_audienceYesWho will attend (for example 'Support leaders at consumer apps')
publication_approvalNoOptional confirmed written approval for this exact customer name, figures, quote and intended use. Ask before publication. A draft cannot grant customer permission.
product_mention_levelNoWhether to add product tie-in placeholders to the script ('none' leaves them out)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / publication_approval
      Added value: +{
+  "description": "Optional confirmed written approval for this exact customer name, figures, quote and intended use. Ask before publication. A draft cannot grant customer permission.",
+  "enum": [
+    "approved",
+    "not_approved",
+    "unknown"
+  ],
+  "type": "string"
+}
  2. Changed10 schema fields changed
    • addedInput schema / properties / business_model
      Added value: +{
+  "description": "Optional: how you charge, so the advice fits it. If omitted, it is read from your text and the answer says how.",
+  "enum": [
+    "saas",
+    "services",
+    "connectivity",
+    "transactions",
+    "marketplace",
+    "hardware_software",
+    "investment"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / duration / description
      Previous value: -"Webinar length"New value: +"The webinar length"
    • changedInput schema / properties / include_polls / description
      Previous value: -"Include interactive poll suggestions"New value: +"Include poll suggestions with answer options"
    • changedInput schema / properties / key_takeaways / description
      Previous value: -"OPTIONAL: 3-5 things attendees should learn (comma-separated). If not provided, we'll suggest based on topic"New value: +"Optional: what attendees should learn, one per line, per semicolon or comma-separated. If not provided, takeaways are suggested from the topic"
    • changedInput schema / properties / speakers / description
      Previous value: -"Optional: Speaker names and titles (comma-separated)"New value: +"Optional: speakers as you want them listed. Separate speakers with semicolons or line breaks ('Name, Title; Name, Title'), or with commas if each is one phrase"
    • changedInput schema / properties / target_audience / description
      Previous value: -"Who will attend (e.g., 'Marketing managers at B2B SaaS companies')"New value: +"Who will attend (for example 'Support leaders at consumer apps')"
    • changedInput schema / properties / topic / description
      Previous value: -"Webinar topic/title"New value: +"The webinar topic or title"
    • changedInput schema / properties / webinar_type / description
      Previous value: -"Type of webinar determines structure"New value: +"The kind of webinar; sets the structure"
    • addedInput schema / properties / your_product
      Added value: +{
+  "description": "Optional: your product or service name, used in the answer. Without it the answer says so and shows a placeholder.",
+  "type": "string"
+}
    • addedInput schema / properties / your_sector
      Added value: +{
+  "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+  "enum": [
+    "logistics_tech",
+    "fintech",
+    "saas",
+    "vertical_saas",
+    "ai_native",
+    "ites",
+    "telecom",
+    "software",
+    "cybersecurity",
+    "other"
+  ],
+  "type": "string"
+}
  3. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint true, destructiveHint false, openWorldHint false), and the description adds genuinely new behavior: an input-grounding guarantee ('uses only what you gave and says what it did not get') and a compliance caveat that a draft cannot grant customer permission. What it does not say is anything about latency, determinism across repeated calls, or limits on input size.

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?

Four sentences, front-loaded with the purpose, then optional inputs, then outputs, then the compliance caveat. The input list and output list are dense but each earns its place by telling the agent what will and will not be returned. The final imperative is slightly abrupt in placement but carries real content.

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?

With 12 parameters and no output schema, the description carries the burden of explaining returns, and it does so in detail: run of show, spoken script with speaker lines and on-screen cues, polls, likely Q&A, follow-up email sequence, sector notes. It also flags the customer-approval prerequisite. Complete enough for correct invocation, missing only sibling comparison.

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 every one of the 12 parameters, including the six enums, is already documented in the schema, and the fallback behavior for omitted values is described there too. The description's enumeration of optional shaping inputs largely restates parameter names rather than adding new semantics. Baseline 3 is the right ceiling here.

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?

The description opens with a specific verb-plus-resource: plan a webinar that leads to meetings, driven by topic, target audience and webinar type. That is concrete enough to separate it from siblings such as newsletter_builder or case_study_generator, although it never names a sibling or states the boundary explicitly, which keeps it short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the stated goal (a webinar whose purpose is to generate meetings) and by the note that omitted inputs are reported back rather than invented. There is no explicit when-to-use versus when-not guidance and no routing to alternatives like thought_leadership_series or sales_enablement_content. The compliance instruction about written customer approval is a prerequisite, not usage guidance.

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

All craft-content-mcp toolsInspect
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