Skip to main content
Glama

Insert media

insert_media

PROJECT-SCOPED: this call acts only on the explicit project_id and returns the project identity with its result. Splice an uploaded video clip or image INTO the edit at ANY position in the FINAL edited video — mid-take positions split the take cleanly at a word edge, so 'in the middle of the talk' works exactly. NEVER splice a clip the user sent as a STYLE REFERENCE ('watch this', 'make it like this', 'use this as reference', 'recreate this', a YouTube they asked you to study) — look_at_asset it, extract_audio / add_music if they want THAT song, and rebuild the look from the MAIN gameplay/footage. If the studio already placed a reference on the timeline, remove_insert it. Call list_assets(kind='clip') or kind='image' first and pass the exact storage_key. duration_s: how long the insert plays (image default 3.0s; a video defaults to its available length). clip_start_s: where in the source clip the window starts — use look_at_asset to pick the right moment. motion: 'zoom_in', 'zoom_out', 'pan_left' or 'pan_right' gives either a still or a video insert its own slow local camera move without changing timing or audio. Use it deliberately to direct attention, not on every shot. Inserted media is NOT transcribed — captions cover the main footage only. fit defaults to 'auto': the WHOLE asset is preserved (black bars when the program frame is already pad; a blurred extension otherwise) so a portrait card cannot be center-cropped into an empty middle band. Pass fit='pad' for solid black; never use blur when the user asked for black. fit='crop' fills edge-to-edge. Assets may be reused whenever the edit benefits from repetition or a different source window.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fitNo
motionNo
asset_keyYes
duration_sNo
project_idYesRequired immutable scope for this call. Copy the id from list_projects/open_project/project_state; the active-project pointer is never used to guess.
at_output_sYes
clip_start_sNo
motion_motifNoActive Blueprint motion motif id this event executes; never 'hold'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations are all false (non-readonly, non-open-world, non-idempotent, non-destructive), so the description carries the full burden of behavioral disclosure. It delivers: project-scoped behavior, splitting at word edges, no transcription of inserted media, fit behavior with black bars/blur, motion effects, and defaults. It even clarifies edge cases like portrait cards and blur-vs-pad preferences. This is comprehensive behavioral disclosure.

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 each sentence adds substantive value, from scoping to usage rules to parameter semantics. It is front-loaded with the critical project-scoping warning. It could be tightened slightly (e.g., merging some fit explanations), but the density is justified by the tool's complexity and the need to avoid misuse.

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?

Given the tool's complexity (8 parameters, no output schema) and the high-risk misuse cases (style references, fit options), the description is remarkably complete. It covers prerequisites (list_assets), behavioral nuances (no transcription, split at word edge), parameter defaults, and explicit exclusions. An agent could confidently invoke this tool without further documentation.

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?

With only 25% schema description coverage, the description must explain the six undocumented parameters. It does so thoroughly: duration_s (defaults for image vs video), clip_start_s (use look_at_asset), motion (types and effect), fit (auto/pad/crop and blur behavior), and it implicitly clarifies asset_key and at_output_s through the overall description. This compensates fully for the schema gaps.

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 clearly states the tool's function: splicing an uploaded video clip or image into the edit at any position, with specific details like splitting at word edges. It distinguishes itself from siblings by naming alternatives (look_at_asset, extract_audio, remove_insert) and by explicitly scoping to the project_id. This makes the purpose unambiguous and differentiates it from the many other add/insert tools.

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 provides explicit when-to-use and when-not-to-use guidance. It warns against splicing style-reference clips, directs to alternatives (look_at_asset, extract_audio, remove_insert), and instructs to call list_assets first. This is far beyond typical usage guidance and leaves no ambiguity about correct invocation.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.