ChatCut

manage_template

One template per templateId; save creates one. Find published or saved templates with browse_library category:"motion-graphics" (group:"favorites" for saved). Pass its result id; attachments use blocks.

Actions:

get: read template metadata (name, description, dimensions); no asset properties.
list_assets: read template assets grouped by type, including motionGraphicAssets[].properties (key/type/defaultValue), dimensions and duration. Read-only: no apply/copy needed. Match referenceAssetId against these asset IDs; they belong to the template source, not the current project. Reference JSX is available from browse_library references ids + parts:["code"].
apply: copy the whole template timeline/content into the current project. This is the preferred path when the template structure fits.
copy_assets: copy all template assets into the current project without placing the full template. Use this only when a new MG must embed or remap template media as project-local asset IDs. The result returns project-local copied asset IDs.
save: save a Motion Graphic from the current project as one of the user's own templates, so it can be reused in other projects. Returns its templateId; get, list_assets and apply then work on it like any template. A template keeps only the graphic: later conversations learn that the user liked it, and for which video, from memory (manage_memory with sources template:).

Read scene descriptions and companion requirements before applying; include required layers/effects and verify order and half-open time ranges. Missing companions are blockers, not permission for an incomplete scene. Template IDs are not project asset IDs: use the apply/copy result for inspect_asset and edit_item.

Apply fitting templates as-is. For a different visual job or number of content slots, use the current surface's MG workflow to create a fitting structure, borrowing visual language rather than forcing content into the example. copy_assets is only for embedding/remapping template media.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "manage_template"
  }
}

Input Schema

Name	Required	Description
`name`	No	For save: template name; defaults to the asset's name.
`action`	Yes	Template operation to perform.
`assetId`	No	For save: the Motion Graphic asset ID (or unique prefix) in the current project.
`placement`	No	For apply: optional placement; targetTrackId accepts full IDs or unique prefixes. Linked IDs are template IDs, not project asset IDs: discover manage_template if needed, get each chosen template to read its dimensions/duration, then apply with templateId and placement {startFrame,targetTrackId}. Do not pass these IDs to edit_item adds or inspect_asset. Use the returned project asset/item IDs for later edits. Read linked scene descriptions before applying templates. When a description requires companion components, resolve them among the same design style's templateRefs with the matching canvas aspect ratio; apply all required components at the same start/end time on their specified layers (background below footage, foreground above). Video track order is zero-based back-to-front: lower order is behind, higher order is above. Use stable track IDs and read back the final order after inserting tracks. Similar names do not mean duplicate components: use each role, description and template ID. Preserve the template's exact duration; align video windows to the half-open range [startFrame,startFrame+durationInFrames), restoring the video at that exclusive end frame. Described companion effects are separate required edits, not effects already drawn by the MG: inspect the named builtin effect for its supported properties, apply it to the specified footage and time range, and read back its target/range/parameters. Follow any accompanying video-window instructions. If a required companion or effect is unavailable or ambiguous, report the blocker instead of placing an incomplete scene.
`projectId`	No	Project for this call (full ID or unambiguous prefix). Explicit-timeline calls never change the target of later calls; legacy project selection applies otherwise.
`templateId`	No	Required except for save. Template id from a browse_library motion-graphics result, a reference detail templateId, a templateRefs value, a <template id=...> block or a save result. Do not pass referenceAssetId here.
`timelineId`	No
`omitAssetIds`	No	For apply: template asset IDs to omit.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedNov 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, but the description adds substantially more: it discloses what apply actually destroys/creates (copies the whole template timeline into the current project), that copy_assets returns project-local copied asset IDs and apply returns project asset/item IDs for later edits, and that save returns a templateId that unlocks get/list_assets/apply. The ID-provenance warning (template IDs vs project asset IDs, don't pass referenceAssetId as templateId, don't feed template IDs to inspect_asset or edit_item) is exactly the kind of behavioral context structured fields cannot carry.

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 Actions list is well front-loaded and scannable, but the piece is bloated by repetition: the template-ID-vs-asset-ID warning appears in the main description, again in the templateId field, and again in the placement field, and the copy_assets restriction is stated twice. Large amounts of apply-time workflow (track ordering, half-open ranges, companion effects) sit inside the placement parameter description, which is structurally misplaced and inflates the schema.

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 an eight-parameter, five-action tool with no output schema, the description covers what an agent needs: return values for save and copy_assets, the discovery path to obtain IDs, mutation scope for apply, and failure policy for missing companions. Nothing essential to a correct invocation 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 already 88%, so most field meaning is documented; the description's contribution is provenance rather than syntax — it tells the agent where a templateId may come from (browse_library result, reference detail templateId, templateRefs value, <template id=...> block, or a save result) and where assetId comes from for save. It adds less for placement/omitAssetIds, whose semantics live entirely in the schema (and the placement field, conversely, is overloaded with workflow prose rather than parameter meaning).

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 specific resource (motion graphic templates) and enumerates five distinct operations with a one-line verb-first definition of each: get reads metadata, list_assets reads assets by type, apply copies the whole timeline, copy_assets copies assets only, save creates a user template. It also distinguishes itself from browse_library by pointing there for discovery and from inspect_asset/edit_item by warning that template IDs are not project asset IDs.

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?

Explicit routing is given for every branch: discovery via browse_library with the category: and group: arguments, apply as the "preferred path when the template structure fits," copy_assets restricted to "only when a new MG must embed or remap template media," and the negative case — when the visual job or slot count differs, build a new structure rather than forcing content into the example. Prerequisites (read scene descriptions and companion requirements first, report blockers rather than place an incomplete scene) are stated outright.

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

All ChatCut tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.