Skip to main content
Glama

framesail

by com.framesail

Update segment prompts

update_segment_prompts
Idempotent

Set one segment's final prompts VERBATIM — no LLM rewrite. The direct counterpart to update_segment_content: your text is written as-is to the segment's creative direction and to the matching asset configs the renderer reads. Asset statuses are untouched: an already-rendered asset stays complete, and generate_segments skips complete assets — so to see the edit rendered, call regenerate_segment_asset on that segment (the ONLY re-render path after a prompt edit). Continuation links, SFX, and overlays are untouched. Pass only the prompt(s) you want to change; media_queries edits a fetched segment's stock-search text the same way.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesProject ID, as returned by create_project or list_projects
image_promptNoNew scene-image prompt (image segments; also the retrieval-miss fallback on real-photo segments). Empty leaves it unchanged.
video_promptNoNew motion/video prompt (video segments; also the retrieval-miss fallback on real b-roll). Empty leaves it unchanged.
media_queriesNoNew stock-search queries for a fetched-media segment (real b-roll / real photo). Replaces the search text verbatim; re-fetch an already-fetched clip with regenerate_segment_asset. Omit to leave the search unchanged.
segment_numberYes1-based segment number, as reported by get_segments
start_frame_promptNoNew start-frame prompt (generated video segments). Empty leaves it unchanged.

TDQS

A4.9/5.0
Behavior5/5

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

The description explains side effects beyond the annotations: it writes verbatim to creative direction and asset configs, leaves asset statuses untouched, preserves continuation links/SFX/overlays, and clarifies the re-render implication. This is valuable behavioral context that the annotations alone (idempotentHint, destructiveHint) do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and distinguishing trait, then efficiently packs necessary side-effect, re-render, and parameter-selection guidance into two dense sentences. Every clause carries information the agent needs, with no filler.

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 mutating tool with 6 parameters and important side effects, the description covers what happens, what does not happen, how re-rendering works, and how partial updates behave. The schema supplies parameter provenance, so 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.

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. The description adds useful cross-parameter guidance: passing only the desired prompts is a partial update, and media_queries behaves the same verbatim way as the prompt fields. This consolidates and clarifies semantics beyond the individual schema entries.

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 names a precise verb and resource ('Set one segment's final prompts VERBATIM') and immediately differentiates from update_segment_content by emphasizing the no-LLM-rewrite behavior. The scope ('one segment') and the mention of asset configs remove ambiguity about what is being modified.

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?

It explicitly names update_segment_content as the direct counterpart and gives the critical routing rule: after an edit, regenerate_segment_asset is the ONLY re-render path because generate_segments skips complete assets. It also tells the agent to pass only the prompts it wants to change, providing clear when-and-how guidance.

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

All framesail toolsInspect
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