Skip to main content
Glama

craft-content-mcp

by io.github.shashwatgtm
OverviewDiscussionsAdmin

Webinar Script

webinar_script
Read-only

Writes a webinar run of show and a full spoken script 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 the run of show, the script with the speaker lines and on-screen cues for each segment built from your takeaways and speakers, polls with answer options, anticipated questions with answers, a follow-up email sequence and sector notes. Without key takeaways it suggests them from the topic and type. The script uses only what you gave and says what it did not get.

Input Schema

TableJSON 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')
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. 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"
+}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered; the description adds genuinely new behavioral context by enumerating the returned artifacts and, importantly, disclosing grounding behavior ('The script uses only what you gave and says what it did not get'). It stops short of noting any limits on length or generation constraints, so not a 5.

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?

Purpose and required inputs are front-loaded in sentence one, followed by optional shapers, fallbacks, and the grounding caveat in descending order of importance. It is dense with enumerated fields but no sentence is filler; only the long mid-paragraph artifact list could be tightened.

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?

With 11 parameters and no output schema, the description compensates by listing every returned artifact (run of show, speaker lines and on-screen cues, polls, anticipated Q&A, follow-up emails, sector notes) and by documenting default behavior for each optional input. An agent has everything needed to call it correctly and to set caller expectations.

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, but the description goes further by grouping the optional parameters that 'shape it' and by stating the fallback for key_takeaways, your_product, your_sector and business_model when omitted. That adds conditional semantics the enum lists alone do not convey.

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 first sentence names a specific verb ('Writes') and two concrete artifacts ('webinar run of show and a full spoken script') plus the three required inputs that drive them. That artifact set is unmistakable against siblings like newsletter_builder or case_study_generator, so an agent can select this tool without opening the schema.

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?

The description explains conditional behavior ('Without key takeaways it suggests them from the topic and type', product mention levels), which implies when the tool is appropriate, but it never states when to prefer it over the sibling content tools or what prerequisites it assumes. Usage is inferable 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 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