Skip to main content
Glama

Cutscene

Write a piece of your own

create_piece
Destructive

Make a piece of the user's own, in one of two ways. from: { film, shot } keeps a scene of a film as it is set (the shot of the library it is, with every choice made on it: settings, elements placed, turned, recoloured, hidden, their entrances and effects, its camera, colours and length; never its words or pictures, which stay in the film); from: { piece } keeps a shot of the library, or one of the user's pieces, under a new name; give it a name. Or recipe: write a piece whole, of the shape get_piece { example: kind } shows: a style, a scene composed of elements (with keys, loops, effects and pulses per element, a camera that hits), a transition or an effect (a fragment shader), an element animation, a text animation, a camera move, a sound written as a score, a 3-D object assembled from our shapes. It is read first (its shape, its shader's words, the pieces it names) and refused with what is wrong; then a quick check draws it (its shader compiles and is not heavy, one meeting or its opening and its life in 16:9, it follows the brand) and the answer says « ready » or what to fix, with a picture. It is kept with the user's pieces (« Mes pièces » on their account; pieces/ on their machine) and used by its id like a piece of the library: add_shot, set_transition, set_element… Rewritten (overwrite: true), the films that use it take the new version. show_piece shows it in a few versions; check_piece passes every gate. The checks draw it in Cutscene's default colours and in another brand (to see that it follows the brand): to see it in the film's, put it in the film and use preview_film. Every word a scene shows is an example the user rewrites: it claims nothing (no figure, price or name).

Input Schema

NameRequiredDescriptionDefault
fileNoInstead of recipe or from: a file of another program made scenes of the user's own (a Lottie animation, a composition sent from After Effects by « Send to Cutscene », a timeline .fcpxml, Fusion nodes .setting). Each plays the file's animation with Cutscene's own player in the brand's colours, each text a setting; what is not played (expressions are never run, effects, 3-D…) comes back in left_out, to tell the person
fromNoKeep a scene of a film, or a piece, as it is set (instead of recipe)
nameNoWith from: the name the user will find it under, in their language
aboutNoWith from: a sentence on what it is for
recipeNoA piece written whole (see get_piece { example: kind }). Leave its id out for a new piece; with overwrite, the id of the user's piece it rewrites
overwriteNoWith recipe: rewrite the user's piece that has this id (its earlier version is kept online)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The annotations mark the tool as destructive, and the description adds substantial behavioral context: validation/refusal, drawing checks, storage location, overwrite effects on films, and brand-color checks. It does not contradict the annotations and greatly reduces ambiguity beyond them.

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

Conciseness3/5

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

The purpose is front-loaded, but the prose is long, run-on, and occasionally confusing, especially where it says "one of two ways" despite several modes existing. The complexity justifies some length, but the structure could be tighter and clearer.

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?

For a complex multi-mode creation tool with a rich schema and destructive annotation, the description covers validation, storage, overwrite behavior, and post-creation workflow. It omits the file-import mode from prose and relies on the schema for that path, so it is mostly but not fully complete.

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% and already very detailed. The description adds useful semantics for from film/shot (what is and is not copied), recipe structure, and overwrite consequences, though it adds little for the file-import parameter beyond the schema.

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 opening "Make a piece of the user's own" names a specific verb and resource, and the body distinguishes the from-film/from-piece/recipe modes and points to show_piece, check_piece, and preview_film. Despite the confusing "one of two ways" phrasing, an agent can identify the tool's role and distinguish it from siblings.

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 explains the conditions for each creation mode and names alternatives for viewing, validating, and previewing in film colors. It does not discuss the file-import mode in prose, but the schema covers it, and the overall routing guidance is strong.

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.

Resources