Skip to main content
Glama

Replace the entire Clipkit project

set_project
Destructive

Replace the entire project with the given source JSON, returning its project_id. This is the PRIMARY way to build: use it to create a composition or to add/change many elements at once. (To tweak a single element in an existing project, use edit_element / add_element / delete_element instead.) REVISION RULE: if you are iterating on a video that already exists in this conversation — the user asked for changes, you are fixing your own work — you MUST pass its project_id so the project is updated in place and keeps one editor link and its version history. Omitting project_id creates a NEW, unrelated project and strands the old one; only omit for a genuinely different video. The input is validated against the @clipkit/protocol before being accepted; invalid inputs return an error. Shape: { width, height, duration, frame_rate, output_format, background_color?, defaults? (house easing, e.g. a spring), fonts?, camera?, lights?, elements:[…] }; every element has a type plus base fields (id, layer, x, y, width, height, time, duration, opacity, rotation, animations, keyframe_animations) and type-specific fields. CKP/1.1: keyframe easings accept a spring object {type:"spring", duration?, bounce?}; channels take stagger {each, from, ease, split, seed} to spread across text units / set copies / group children; groups take layout {direction, gap, align} (stack — no hand-computed positions); text takes a count-up {expr, format}. For exact field names + types call get_schema (optionally with an element_type) — the runtime ignores unrecognized keys, and this tool flags any it does not recognize.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceYesA full Clipkit source object.
project_idNoWhich project to act on — the id returned by create_project / set_project / create_promo / load_project. ALWAYS pass it once a project exists in this conversation; omitting it on a build tool creates a brand-new project. (Omit only on the local stdio server working a single project.)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
widthNo
heightNo
durationNo
project_idYes
element_countYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / project_id / description
      Previous value: -"Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project."New value: +"Which project to act on — the id returned by create_project / set_project / create_promo / load_project. ALWAYS pass it once a project exists in this conversation; omitting it on a build tool creates a brand-new project. (Omit only on the local stdio server working a single project.)"
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already carry destructiveHint=true and readOnlyHint=false, but the description adds substantial context beyond them: what gets destroyed (entire project replaced; old project stranded when project_id is omitted), the editor-link/version-history effect of passing project_id, validation against @clipkit/protocol, and unrecognized-key handling ('the runtime ignores unrecognized keys, and this tool flags any it does not recognize'). No contradiction with annotations.

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?

Information is front-loaded: core action, primary use case, alternatives, and the REVISION RULE all precede the schema specification dump. The CKP/1.1 section is dense in the back half, but each feature bullet conveys version-specific behavior that would otherwise force repeated get_schema calls, so the length is largely earned for a tool of this complexity.

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 destructive build tool with nested objects, the description is complete: purpose, when-to-use, alternatives, destructive consequences, project_id discipline, validation behavior, shape outline, and a pointer to get_schema for exact details. With an output schema present, the return value ('project_id') needs no further elaboration.

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?

Schema coverage is 100%, but the source parameter's schema description is just 'A full Clipkit source object' — opaque for a deeply nested, open (additionalProperties: {}) parameter. The description compensates by documenting the full top-level shape, base element fields, type-specific fields, and CKP/1.1 syntax (spring, stagger, layout, count-up), while directing the agent to get_schema for exact names and types — real meaning far beyond the schema text.

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?

Opens with a specific verb and resource — 'Replace the entire project with the given source JSON, returning its project_id' — matching the title and stating scope (entire project). It also differentiates itself from siblings by explicitly naming edit_element / add_element / delete_element as the single-element alternatives, so an agent can tell the tools apart without opening their schemas.

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?

States exactly when to use it — 'create a composition or to add/change many elements at once' — and when not to, routing to edit_element / add_element / delete_element for single-element tweaks. The REVISION RULE adds an explicit obligation: when iterating on an existing video, the agent MUST pass project_id, and it spells out the consequence of omission (new unrelated project, stranded old one).

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.