Daily Studio Teleprompter

Add scripts to the content plan

add_scripts_to_plan

Put finished talking-head scripts into the user's Daily Studio content plan, each with the day it should go out. Use this when the user asks you to PLAN — a week, a month, a series — rather than to hand them something to record right now. The plan lives on their account: it shows up in the app, on dailystudio.app/plan, and stays there. Calling this twice with the same scripts is safe; duplicates are skipped. Requires a connected Daily Studio account with the plan turned on. To record something immediately, use send_script_to_teleprompter instead — that is a delivery, this is a plan. Default to about 45 seconds of natural speech directly to camera: a hook, one clear idea and a short closing. Preserve the creator's voice and verified facts.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`scripts`	Yes	The scripts to add, in the order they should sit in the plan.
`collection`	No	Optional name for this batch as a group — a topic ('Customer questions'), a series ('Framing, part 1-5'), or what the week is about. The scripts show up grouped under it in the app and on the web, which is how somebody finds them again later. Use one when the scripts belong together; leave it out for a handful of unrelated ones.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

changedInput schema / properties / scripts / items / properties / text / description

Previous value: -"The finished script, plain UTF-8. Newlines allowed."New value: +"The finished talking-head script to speak directly to camera: one opening, one clear idea and a short closing. Default about 45 seconds of natural speech. Plain UTF-8; newlines allowed."

Changed1 schema field changedAug 20, 2026

addedInput schema / properties / scripts / items / properties / id

Added value: +{
+  "description": "Optional stable key of YOUR choosing for this script (an idempotency key). Re-sending a batch with the same keys updates those scripts instead of duplicating them — use it when a call may be retried, or to deliberately revise scripts you added earlier.",
+  "maxLength": 64,
+  "type": "string"
+}

Changed2 schema fields changedAug 20, 2026

addedInput schema / properties / collection

Added value: +{
+  "description": "Optional name for this batch as a group — a topic ('Customer questions'), a series ('Framing, part 1-5'), or what the week is about. The scripts show up grouped under it in the app and on the web, which is how somebody finds them again later. Use one when the scripts belong together; leave it out for a handful of unrelated ones.",
+  "maxLength": 80,
+  "type": "string"
+}

addedInput schema / properties / scripts / items / properties / collection

Added value: +{
+  "description": "Overrides the batch's collection for this one script. Rarely needed.",
+  "maxLength": 80,
+  "type": "string"
+}

AddedAug 19, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly=false, destructive=false and openWorld=false, but the description adds real context beyond them: retry safety ('calling this twice ... duplicates are skipped'), a hard prerequisite (a connected Daily Studio account with the plan turned on), and persistence ('shows up in the app, on dailystudio.app/plan, and stays there'). One caveat: the retry/dedupe claim sits in mild tension with idempotentHint=false, though the schema's update-on-same-key behavior makes that defensible rather than a contradiction.

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?

Front-loads purpose, then routing, then the plan's persistence, retry behavior and prerequisite in a tight sequence. The closing sentence on 45-second structure duplicates the schema's `text` description and could be trimmed, but the rest earns its space.

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 mutation tool with no output schema, the description covers everything an agent needs: what it creates, where the result lives, the account prerequisite, retry behavior, and which sibling to use for the immediate-recording case. No significant gap remains.

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% and the nested item fields (id as idempotency key, date, title, platform, collection) are fully documented in the schema, so the schema carries the semantics. The description's content guidance ('about 45 seconds ... a hook, one clear idea and a short closing') largely restates the schema's own text description rather than adding new syntax or constraints.

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 ('Put finished talking-head scripts into the user's Daily Studio content plan, each with the day it should go out') and immediately contrasts itself with the delivery sibling ('this is a plan', not a recording handoff). An agent can distinguish it from edit_planned_scripts and send_script_to_teleprompter without opening any schema.

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?

Gives an explicit trigger ('Use this when the user asks you to PLAN — a week, a month, a series') plus an explicit exclusion ('rather than to hand them something to record right now'), and names the alternative tool to use in the excluded case. Nothing is left to inference.

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

All Daily Studio Teleprompter 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?