Skip to main content
Glama

edit_asset

Update or delete a library asset.

External MCP asset-code rule: use full replacement json.code. For Motion Graphics, inspect_asset includeCode:true returns asset.revision; pass asset.revision as expectedRevision to reject stale edits. Do not use codeFile.

  • update: change asset-level fields. Code update transport depends on the current agent surface. Before writing code, read its Skill: Motion Graphics=create-motion-graphics, effects/transitions=create-shaders (external hosts: shader-gen). If missing, read /skills//SKILL.md in ChatCut-Inc/agent-plugin, then go on. For other fields use json (e.g. filename, sourceLut). type is optional for update and inferred from assetId.

  • MG properties: {key,label,type,defaultValue}; change asset defaults with propertyDefaults:{key:value}, or one clip with edit_item propertyOverrides. Legacy root property keys normalize only with explicit type:"motion-graphic". width/height are clip/source dimensions; duration aliases durationInSeconds.

  • sourceLut:null removes a video/image/gif source grade; sourceLut:{assetId} applies an existing builtin or project LUT effect to ALL instances. Find project LUTs via browse_assets type:"effect" (a lut-typed editable property). Unique prefixes resolve; nonexistent LUTs fail. For one clip/range use edit_item instead.

  • delete: remove the asset and any items/effects/transitions that reference it. If references exist, the tool first returns the impact and requires confirmImpact:true before deleting.

Asset properties live on the asset; clip-level position and per-instance overrides live on the item — use edit_item for those.

This runtime cannot read the agent's workspace files. For code-based assets, set the complete replacement source inline in json.code.

Web analysis declarations belong in json.chatcutSpecialEffectUsed; see the json parameter and create-shaders skill.

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>",
      "assetId": "<assetId>"
    },
    "name": "edit_asset"
  }
}

Input Schema

NameRequiredDescriptionDefault
jsonNoJSON for update: {"type":"motion-graphic","code":"..."}. Web Motion Graphic edits use the shared syntax/API/renderer-contract validator. Invalid code and known incompatibilities must be fixed. Uncertain analysis is a non-blocking warning: make at most one best-effort repair, never repeatedly rewrite just to silence it. Valid code without known incompatibilities receives the renderContract stamp without a preview or caller declaration. Desktop retains its native policy. chatcutSpecialEffectUsed: Optional Web-only media-analysis declarations. Omit for ordinary MG/effect/caption work and preserve existing values on unrelated revisions. Transitions and Desktop do not support these readers. caption_v1 is private to caption-owned code.
typeNoAsset type (for delete)
actionYesupdate or delete
assetIdYesAsset ID or prefix ID
projectIdNoProject for this call (full ID or unambiguous prefix). Explicit-timeline calls never change the target of later calls; legacy project selection applies otherwise.
timelineIdNo
confirmImpactNoFor action=delete only: pass true only after the user confirms the reported timeline impact.
expectedRevisionNoRevision returned as asset.revision by inspect_asset includeCode:true for a Motion Graphic. Pass with inline json.code to reject a stale source copy. Omit for asset types without revision guards.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

A3.8/5.0
Behavior1/5

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

The content itself is unusually rich — it discloses the reference-cascading delete, the confirmImpact gate that returns impact before removal, revision guards, prefix resolution with nonexistent-LUT failure, and a runtime that cannot read workspace files. However, annotations declare destructiveHint=false while the description states that delete "remove[s] the asset and any items/effects/transitions that reference it," which is a direct contradiction of the structured safety signal.

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?

It is front-loaded with a clear one-line purpose and uses bullets to separate update, Motion Graphics, sourceLut, and delete concerns, which helps. But it sprawls across many concerns — code-transport policy per agent surface, skill file paths in an external repo, runtime file-access limits, and web analysis declarations — and some of this belongs in a skill or help text rather than the selection-time description.

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 an 8-parameter, two-action tool with inline code replacement, the description covers the risky edges: delete cascades and confirmation, stale-edit rejection, LUT application scope, and the edit_item boundary. The main omission is return-shape/pagination, though with no output schema and 88% schema coverage the description is close to sufficient.

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 the baseline is 3, but the description adds genuinely new meaning: type is optional for update and inferred from assetId, expectedRevision must come from inspect_asset includeCode:true and only applies to Motion Graphics, and confirmImpact is only valid after the user confirms the reported impact. It also clarifies that unique prefixes resolve while nonexistent LUTs fail, which the schema does not state.

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 pair and resource ("Update or delete a library asset") and explicitly draws the boundary against the closest sibling: "clip-level position and per-instance overrides live on the item — use edit_item for those." An agent can distinguish edit_asset from edit_item, inspect_asset, and browse_assets without opening any schema.

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?

Gives concrete when-to-use routing throughout: read the relevant Skill before writing code, use edit_item for one clip/range LUT changes, use browse_assets type:"effect" to find project LUTs, use inspect_asset includeCode:true to obtain asset.revision, and prefer propertyDefaults vs edit_item propertyOverrides. It also names the failure and confirmation conditions, leaving little to inference.

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.