Send a shoot's worth of scripts to the Daily Studio teleprompter on iPhone, in one link.
Scored across 12 tools
Each tool has a clearly distinct purpose, with explicit cross-references in descriptions (e.g., add_scripts_to_plan vs send_script_to_teleprompter, list_planned_scripts vs get_planned_scripts). The six planned-script tools (add, archive, edit, get, list, reorder) are separated by distinct verbs and descriptions that clarify the boundary between planning, editing, ordering, and reading. No two tools appear to do the same thing.
All 12 tools use consistent snake_case with a verb_noun structure (add_scripts_to_plan, list_collections, cancel_scheduled_post, etc.). The only minor variation is the noun phrase 'scripts_to_plan' vs 'planned_scripts', but this remains predictable and readable. The pattern is uniform throughout.
With 12 tools, the set is well-scoped for a content planning and teleprompter assistant. Each tool covers a distinct operation (planning, editing, ordering, reading, delivering, tracking posts) and earns its place. There is no redundancy or bloat.
The core script lifecycle is well covered: create/add, read (overview and full text), update/edit, reorder, archive, and deliver to teleprompter. Post scheduling and account connection are read-only or managed externally, which is appropriate, but collection management only supports listing—no create/update/delete for collections, a minor gap that could force workarounds.
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.
| 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. |
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.
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.
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.
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.
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.
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.
Archive scripts out of the user's working plan, by id — or restore archived ones with restore: true. Archiving is reversible and keeps the script and any recorded video; it is the right way to clear finished or shelved work. Permanent deletion is deliberately not available to assistants — the user does that themselves.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | The scripts to archive (or restore). Ids come from list_planned_scripts. | |
| restore | No | true brings archived scripts back into the plan instead. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations present, the description adds valuable behavior: the operation is reversible, the script and recorded video are kept, and permanent deletion is deliberately outside the assistant's scope. This aligns with `idempotentHint: true` and `destructiveHint: false`, and 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three purposeful sentences front-load the primary action, add the restoration behavior, then state the important boundary around permanent deletion. There is no filler or repeated information from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the small parameter count, strong schema coverage, and useful annotations, the description is effectively complete for selecting and invoking the tool. It could add a note about how restored archived scripts appear in lists, but that is not critical for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters and includes helpful field descriptions, including that ids come from list_planned_scripts and that restore defaults to false. The description reinforces `restore: true` behavior but does not need to fill a schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact action and resource: it archives planned scripts out of the working plan, plus the same tool can restore via `restore: true`. That makes its purpose distinct among sibling tools like edit_planned_scripts, list_planned_scripts, and reorder_planned_scripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly describes the intended use case ('the right way to clear finished or shelved work') and states the assistant cannot permanently delete. It does not explicitly name sibling tools as alternatives, but the context is accurate and a strong enough boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel one post that is waiting to go out, by id from list_scheduled_posts. Only works while the post is still waiting; the take becomes approvable again. Confirm with the user before calling this — it withdraws something they approved.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The post's id, from list_scheduled_posts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds important context: the post withdraws something the user approved, becomes approvable again, and requires user confirmation before calling. This goes beyond the annotation and explains the consequence of the destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with every sentence adding value: the action, an operational constraint, and a user-consent requirement. There is no redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, the description covers all essential operational aspects: when it is valid, the effect on the post, and the required user confirmation. It is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id' is fully described in the schema with 'The post's id, from list_scheduled_posts.' The description repeats this same source instruction without adding new semantics beyond the schema, so the baseline of 3 for 100% schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Cancel one post that is waiting to go out' with a specific verb and resource. It also names the source of the id, list_scheduled_posts, which distinguishes it from siblings like retry_scheduled_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a key usage condition: 'Only works while the post is still waiting.' It also implies when to use by saying the take becomes approvable again. It does not explicitly name alternatives, but the constraint is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change scripts already in the user's Daily Studio content plan, by id and in bulk: move them to other days, group them into collections, retitle or rewrite them. This is the tool for 'these contents go on these days, grouped like this' when the content already exists — read the plan first with list_planned_scripts, then send one call with all the changes. Only the fields you send change; one bad entry never drops the batch.
| Name | Required | Description | Default |
|---|---|---|---|
| edits | Yes | The changes, one entry per script. Only the fields you send change; everything else stays. Get ids from list_planned_scripts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutation), idempotentHint=true, destructiveHint=false. The description adds important context: partial updates ('Only the fields you send change'), null semantics (clearing fields), and batch atomicity ('one bad entry never drops the batch' – implies partial success or error isolation). While idempotency is annotated, the description doesn't explicitly state it, but the partial-update semantics and error handling are useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that pack a lot of information with efficient phrasing. The first sentence states everything the tool does; the second explains workflow and batch behavior. No redundancy, front-loaded with the most critical info, and each clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk update tool with one parameter array and full schema coverage, the description provides complete context: when to use (after reading plan), what can be changed, how updates behave (partial), and failure handling. No output schema, but return value isn't critical here. The description is sufficient for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% description coverage with rich details (explains 'null makes it undated', 'null clears it', 'get ids from list_planned_scripts'). The description repeats the essence but adds little beyond schema. Baseline 3 is appropriate because the schema covers parameter semantics thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Change scripts already in the user's Daily Studio content plan, by id and in bulk' with specific actions (move to other days, group into collections, retitle or rewrite). It distinguishes from siblings by specifying 'when the content already exists' and naming 'read the plan first with list_planned_scripts'. This is specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: 'read the plan first with list_planned_scripts, then send one call with all the changes' and contrasts with alternative tools (list_planned_scripts for reading). It also states the batch behavior: 'Only the fields you send change; one bad entry never drops the batch' – clear when-to-use and operational notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full text of specific scripts in the user's content plan, by id — the words themselves, not just titles. Use it before rewriting or reviewing a script, or when the user asks about one ('check the hook on Tuesday's'). Up to 20 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | The scripts to read in full, at most 20 per call. Ids come from list_planned_scripts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only/idempotent safety. The description adds useful behavioral context: it returns full text, not just titles, and imposes a per-call limit of 20, though the limit is also in the schema. It doesn't describe return format or pagination, but for this simple read tool the added clarity is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-load the core purpose, provide usage context, and state the limit. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with a single param, full schema coverage, and strong annotations, the description covers what the tool does, when to use it, and its constraints. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single 'ids' parameter is fully described, including the source 'Ids come from list_planned_scripts' and limit). The description only repeats 'by id' and 'Up to 20 per call,' adding minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and clearly identifies the resource ('specific scripts in the user's content plan'), and distinguishes itself from siblings by emphasizing 'the words themselves, not just titles.' This is a clear, distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool ('Use it before rewriting or reviewing a script, or when the user asks about one') and contrasts with listing tools via 'not just titles,' giving context on when to prefer this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the collections (piles) the user already groups their scripts into, with counts. Call it before grouping anything so you reuse their existing names instead of inventing near-duplicates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it returns collections 'with counts' and emphasizes the existing groupings, which helps the agent understand what data to expect beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary action stated first and a concise usage directive second. Every word adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, rich annotations, and a clear description that mentions return value (counts) and purpose, the tool is fully contextualized. The sibling list provides further differentiation, but the description alone is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so there are no parameter semantics to explain. The baseline for 0-param tools is 4, and the description does not need to add parameter details. It appropriately focuses on purpose and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists collections (piles) with counts, specifying both the resource (collections) and the scope (user's existing script groups). This distinguishes it from sibling tools like list_planned_scripts, which focus on scripts themselves rather than their groupings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this tool 'before grouping anything' to reuse existing names, providing a clear when-to-use directive and rationale. This prevents duplicate collection names and is a strong usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the social accounts the user has connected to Daily Studio, so you know where a video could be published and under which handle. Requires a connected Daily Studio account — the first time you call this, the user is asked to connect one, and the call is retried automatically afterwards. Nothing is published by this tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds valuable behavioral context beyond these: the first call triggers a user connection prompt and the call is retried automatically. It also reinforces that nothing is published, complementing the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each with a distinct purpose: listing the accounts, explaining the use case, and clarifying the connection requirement and non-destructive nature. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with an empty input schema and no output schema. The description covers the tool's purpose, use case, side effect (first-time auth), and safety, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers everything. The baseline for zero-parameter tools is 4, and the description appropriately adds no parameter-specific information, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists connected social accounts for a specific purpose ('so you know where a video could be published and under which handle'). It uses a specific verb 'List' and resource 'social accounts', and differentiates itself from the sibling send_script_to_teleprompter by emphasizing it publishes nothing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: before publishing a video to know target platforms and handles. It also notes the first-time connection requirement and auto-retry, but does not explicitly state exclusions or alternatives, though the sibling tool is unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read what is already in the user's Daily Studio content plan — each script's id, title, collection, the day it goes out, its place in the shoot order, and how far it has got (written, recorded, uploaded, scheduled, published, or failed). Call this before adding to a plan so you do not repeat what is there, before editing so you hold real ids, and whenever the user asks what they have coming up. Nothing is changed by this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Only scripts dated on or before this day. | |
| from | No | Only scripts dated on or after this day. | |
| collection | No | Only scripts in this collection. Omit to read the whole plan. | |
| includeUndated | No | Include scripts with no date at all (the backlog). Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation set already declares readOnly, idempotent, and non-destructive; the description adds 'Nothing is changed by this tool' and lists the data returned. This is consistent with the annotations and provides useful behavioral clarity, but it doesn't add deeper context such as auth or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action, then result scope, then when to use it, then a side-effect guarantee. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with full parameter schema, good annotations, and no output schema, the description covers purpose, trigger situations, returned fields, and non-mutating behavior. This is sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description need not explain parameters; it doesn't add semantic detail beyond the schema. The phrase 'whole plan' echoes the collection parameter's schema description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read what is already in the user's Daily Studio content plan' and enumerates returned fields, making the verb and resource specific. It does not explicitly differentiate from the sibling get_planned_scripts, though it contrasts with add/edit actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage triggers: 'Call this before adding to a plan so you do not repeat what is there, before editing so you hold real ids, and whenever the user asks what they have coming up.' It lacks explicit when-not-to-use guidance or named alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read what the user has approved for publishing and what happened to it: waiting, going up now, published (with the link), failed (with the reason in plain words), or cancelled. Call it when the user asks 'did my post go out?' or 'why not?'. Nothing is changed by this tool, and new posts cannot be scheduled from here.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Only posts in this state. Omit for the whole queue, newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: it explains what each state means, that successes include a link and failures include a plain-language reason, and that nothing is mutated and scheduling is out of scope for this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with what is returned before the usage triggers. Every clause earns its place: the state list, the example questions, and the scope boundary each carry distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey return content, and it does so well by enumerating states and what each includes. Ordering and default scope are left to the schema, and there is no mention of result volume or pagination, a minor gap for a queue-listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'state' parameter, including the enum values and the 'omit for whole queue, newest first' behavior, so the schema carries the parameter burden. The description loosely maps its listed states to the enum but adds no filtering syntax or format detail beyond what is already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Read' the publishing queue) and enumerates the exact outcome states it reports (waiting, publishing, published with link, failed with reason, cancelled). An agent can distinguish this read-only queue view from mutation siblings like cancel_scheduled_post or retry_scheduled_post 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete invocation triggers ('did my post go out?', 'why not?') and a clear exclusion ('new posts cannot be scheduled from here'), which steers the agent away from incorrectly using it for creation. It stops short of naming the sibling tools that would handle those other jobs, so it is a strong 4 rather than a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the order the user's camera walks through their scripts — pass ids first-to-record first. Scripts you leave out keep their current order after the ones you name. Use it when the user says what to shoot first, or after planning a batch that should be recorded in sequence.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Script ids in the order they should be recorded, first first. Scripts you leave out keep their current order, after the ones you name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, but the description adds important behavioral context: 'Scripts you leave out keep their current order after the ones you name.' This clarifies the exact effect of the operation beyond what the annotations state, making the behavior predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and uses a dash to explain the ordering logic. The second sentence provides practical usage guidance without excessive detail. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, a clear description, and annotations covering idempotency and destructiveness, the description fully explains what happens to named and unnamed scripts and when to use it. No output schema is needed, and the tool's behavior is completely specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter semantics, including the exact order semantics and the behavior of omitted scripts. The tool description repeats this information but does not add meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Set the order the user's camera walks through their scripts.' It also distinguishes itself from siblings by focusing on first-to-record ordering, which is not mentioned in other tool names like add_scripts_to_plan or edit_planned_scripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Use it when the user says what to shoot first, or after planning a batch that should be recorded in sequence.' It does not explicitly list exclusions or mention alternatives, but the intended use case is clear enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Put one failed post back in the queue, due now — by id from list_scheduled_posts. Use it after the cause in the failure sentence is fixed (say, a reconnected account). The post goes out within about five minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The post's id, from list_scheduled_posts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, and the description adds that the post goes out within about five minutes. It also mentions it's a single post (one failed post), complementing the annotations. No contradiction; the description adds temporal behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, all with purpose: states the action, specifies the condition, and notes the timing. No filler, front-loaded with the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, high schema coverage, idempotent annotation, and no output schema, the description is sufficient. It covers the trigger condition and expected behavior, though it doesn't detail what happens on failure or idempotency implications, but that's not required given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the parameter with a detailed description ('The post's id, from list_scheduled_posts.') and maxLength. The tool description repeats the source ('by id from list_scheduled_posts') but doesn't add new semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to put a failed post back in the queue, with the specific condition of being due now and referenced by id. It distinguishes itself from siblings by specifying it operates on a failed post from list_scheduled_posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use it: after the cause in the failure sentence is fixed (e.g., reconnected account). It also implies not to use it before fixing the cause, and provides context on the timing (about five minutes). This gives clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn one or more finished video scripts into a single one-tap link that opens the user's Daily Studio app with the script(s) loaded into the teleprompter and the right platform safe-zones selected, ready to record. For one script use text; for a batch the user will record back-to-back (a day's 3-4 videos, or a whole content plan — up to 100), use scripts — they land as an in-app shoot queue in order, and ONE link carries them all. Call this only once the scripts are final. Returns a link the user taps on their iPhone; on a desktop it opens a page with a QR code to scan.
| Name | Required | Description | Default |
|---|---|---|---|
| wpm | No | Optional scroll speed in words per minute. Sets the app's teleprompter speed. Omit to leave the user's setting alone. With `scripts`, applies to items that don't set their own. | |
| text | No | A finished talking-head script to speak directly to camera, plain UTF-8. Newlines allowed. Provide either this or `scripts`, not both. | |
| title | No | Optional short label for `text`, e.g. 'Cold plunge hook'. | |
| scripts | No | A batch of scripts (in recording order) delivered as a single link — up to 100 of them, 400000 characters of script in total. The app queues them; after each recording it offers the next. Provide either this or `text`, not both. | |
| platform | No | Where the video will be published. Selects that platform's safe-zone overlay so on-screen UI never covers the creator. Omit to leave the user's choice alone. With `scripts`, applies to items that don't set their own. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic read/write/openWorld/idempotent profile; the description adds real behavioral context beyond them: the batch becomes an ordered in-app shoot queue, one link carries all items, and the return is a tappable iPhone link or a desktop QR page. The 'only once scripts are final' constraint is also disclosed here and nowhere else.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose before mode guidance, and each sentence carries distinct information (mode choice, queue behavior, finality precondition, return format). Slightly long, but no sentence is disposable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-idempotent write tool with no output schema, the description covers the essentials: what it produces (a link / QR page), how batches behave, and the timing constraint. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the description adds meaning the schema does not: which parameter to pick for single vs batch use and the fact that a batch lands as an ordered queue. It does not restate the wpm/platform inheritance rules that the schema already covers, so it stays modestly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (turns finished scripts into a one-tap teleprompter link) and describes the concrete outcome: scripts loaded, safe-zones selected, ready to record. It also distinguishes its two modes (`text` vs `scripts`) so an agent knows the shape of the call without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit selection guidance ('For one script use `text`; for a batch the user will record back-to-back ... use `scripts`') and a precondition ('Call this only once the scripts are final'). It stops short of naming sibling tools (add_scripts_to_plan, etc.) or an explicit when-not-to-use, so it is strong context rather than full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_scripts_to_plan1 field changedInput schema / properties / scripts / items / properties / text / descriptionPrevious 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."send_script_to_teleprompter2 fields changedInput schema / properties / scripts / items / properties / text / descriptionPrevious value: -"The finished script for this video, plain UTF-8."New value: +"The finished talking-head script: one hook, one idea and a short closing, plain UTF-8."Input schema / properties / text / descriptionPrevious value: -"A single finished teleprompter script, plain UTF-8. Newlines allowed. Provide either this or `scripts`, not both."New value: +"A finished talking-head script to speak directly to camera, plain UTF-8. Newlines allowed. Provide either this or `scripts`, not both."list_scheduled_posts1 field changedInput schema / properties / state / enumPrevious value: -[
- "scheduled",
- "publishing",
- "published",
- "failed",
- "cancelled"
-]New value: +[
+ "scheduled",
+ "publishing",
+ "published",
+ "drafted",
+ "failed",
+ "cancelled"
+]add_scripts_to_plan1 field changedInput schema / properties / scripts / items / properties / idAdded 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"
+}archive_planned_scriptscancel_scheduled_postedit_planned_scriptsget_planned_scriptslist_collectionslist_scheduled_postsreorder_planned_scriptsretry_scheduled_postadd_scripts_to_plan2 fields changedInput schema / properties / collectionAdded 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"
+}Input schema / properties / scripts / items / properties / collectionAdded value: +{
+ "description": "Overrides the batch's collection for this one script. Rarely needed.",
+ "maxLength": 80,
+ "type": "string"
+}list_planned_scripts1 field changedInput schema / properties / collectionAdded value: +{
+ "description": "Only scripts in this collection. Omit to read the whole plan.",
+ "maxLength": 80,
+ "type": "string"
+}add_scripts_to_planlist_planned_scriptslist_connected_accountssend_script_to_teleprompterRead and write your Teleprompter.com scripts and folders: list, create, update, and organize.
Send scripts to the blablabla rehearsal app, and find free scenes and monologues to practice.
Create short-form scripts and paced audio, then hand clips to ScriptSeen's on-device video maker.
Prepare podcast rundowns and private drafts; review saved transcripts in your linked Studio.
Add one secure layer between your agents and this server.
