framesail

Save script

save_script

Save script text (your own draft, or an edited version of the generated one). Saving UPDATES the active version in place — the previous text is not kept, so show the user the current script (get_script) before overwriting it. New versions are created by generate_script runs, and activate_script_version switches between those. Run scan_script afterwards so assets and voice blocks reflect the new text.

Three notations the script text carries, none of them ever spoken:

SCENE DIRECTIONS — `[SCENE: <visual direction>]` as its OWN paragraph
(blank line before and after; brackets inside a narration paragraph are
never matched). It directs the storyboard for the narration that follows
it, until the next direction. For that span it OUTRANKS the channel
director style's shot choices — say what is on screen, who is in frame,
and any on-screen text you need baked in verbatim — while the director
style still governs look and rhythm. It is NOT a segmentation constraint:
the storyboard still cuts the span into as many segments as the pacing
wants. scan_script's asset extraction reads directions too: a character
or place named ONLY inside a direction is still extracted, under the
exact name the direction uses — no manual create_asset needed for it.

PAUSES — `<break time="1.5s" />` is the ONLY thing that makes the voice
pause. Ellipses, em dashes and paragraph breaks produce no silence at
all, so a script without break tags is read as one continuous sprint.
Both engines honor it (MiniMax natively, ElevenLabs masked out of the
caption alignment). Use ~0.5s between thoughts, ~1.0s at act seams, and
longer where a card or list needs reading time on screen; write ONE tag
with the total ("4.0s"), never two tags back to back. Breaks are also
the pacing lever the project's narrator_speed can't reach: speed changes
how fast words are said, breaks add the silence between them.

SPEAKERS — a paragraph starting `Name: "..."` assigns that line to a
character, who gets their own voice (set_character_voice) and their own
shot. Narration with no prefix is the narrator's.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`content`	Yes	Full script text to save as a new version; plain prose narration, optionally with `[SCENE: ...]` direction paragraphs, `<break time="0.5s" />` pauses, and `Name:` speaker prefixes
`project_id`	Yes	Project ID, as returned by create_project or list_projects

TDQS

A4/5.0

Behavior1/5

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

The description prominently discloses that saving overwrites the active version and that the previous text is not kept, which is a destructive effect. However, the annotations declare destructiveHint:false, directly contradicting that disclosure; per the rubric this must score 1.

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 description is long but not padded: it is organized into labeled sections for core behavior and each notation, and each rule prevents a mistake an agent could make. It could trim minor repetition, but the structure makes the length navigable.

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?

The description covers core mutation behavior, ordering constraints, notation details, scan_script extraction consequences, and exceptions such as brackets inside narration. It is nearly complete, but the contradiction with destructiveHint and the absence of any return-value/result information leave a small gap for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already documents both parameters (100% coverage), the description greatly expands the meaning of content by specifying the three notations: SCENE DIRECTIONS syntax and matching rules, break tags as the only pause mechanism with recommended durations, and speaker prefix format. This is far more than the schema alone 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 opens with a precise verb and resource: 'Save script text', and immediately scopes it to both user drafts and edited versions of generated scripts. It also distinguishes the tool from siblings by stating that saving updates the active version rather than creating or switching versions.

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?

The description gives an explicit workflow: fetch the current script with get_script before overwriting, use generate_script for new versions, activate_script_version for switching, and run scan_script afterwards. This tells an agent exactly when save_script is appropriate and what to do around it.

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

All framesail tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation3/5

Several tool families overlap in purpose, such as await_jobs/get_workflow_status/get_pipeline_progress, update_segment_content/update_segment_prompts, director_note/project_director_note, and scan_script/rescan_voice_blocks. The descriptions do a good job distinguishing them, but an agent must read carefully to avoid misselection, and there are more than a couple of confusable pairs.

Naming Consistency4/5

The set overwhelmingly follows a verb_noun snake_case convention with clear prefixes like get_, list_, set_, update_, create_, and delete_. Minor exceptions such as director_note, project_director_note, browse_audio_library, and whoami keep it from being perfectly consistent.

Tool Count1/5

At 72 tools, this is far beyond the 50+ extreme range and creates a heavy navigation burden for an agent. Even though the pipeline is complex, this many tools is not well-scoped for an MCP surface.

Completeness4/5

The surface covers the full script-to-export pipeline: styles, assets, voices, storyboards, segments, scenes, and rendering all have substantial lifecycle support. Some gaps exist—no delete_channel, delete_segment, delete_voice_block, or delete_provider_key—but most missing operations can be worked around through existing tools.

Resources

Need Help?