Skip to main content
Glama

ass_set_clip

Set, add, or remove clip and iclip tags on selected Aegisub subtitle lines using rectangles, ASS drawings, or SVG paths.

Instructions

Set, add or remove a clip on the selected lines.

selection accepts anything :func:base.resolve_indices understands (None = the session selection, or every line when none is set).

Geometry is taken from the first one of these that is given: rect ("x1,y1,x2,y2" or a 4-list, in script resolution unless scale names the scale space those numbers are written in), drawing_text (ASS path data), svg_path / svg_d (SVG path data) or spec (a rectangle string, an ASS drawing, or an SVG path -- SVG is detected by its H/V/Q/T/A/Z command letters and the result is converted).

scale for a vector clip sets the explicit \clip(<scale>,...) level; when omitted a vector clip is written at level 1 (script resolution). inverse=True emits \iclip.

mode:

  • "replace" -- strip every existing clip from the line, then insert.

  • "add" -- keep existing clips, insert the new one at the front.

  • "remove" -- strip every clip tag (\clip and \iclip) from the lines; the geometry arguments are ignored.

Returns {doc_id, mode, kind, tag, scale, inverse, lines: [{index, changed, text, removed, clip}]}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoreplace
rectNo
specNo
scaleNo
svg_dNo
doc_idNo
inverseNo
svg_pathNo
selectionNo
drawing_textNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that replace strips every existing clip, add inserts at the front, remove strips all clip tags and ignores geometry, and that inverse emits \iclip. It also explains scale defaults for vector clips. It stops short of stating permissions, undo behavior, or default document context for doc_id.

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

Conciseness5/5

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

The description is front-loaded with the core action and then structured with clear paragraphs and bullets for scale, inverse, and mode. Despite its length, every section earns its place by documenting distinct input behaviors for a complex 10-parameter tool.

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, 10-parameter mutation tool with no annotations, the description is largely complete: it covers modes, selection, geometry sources, scale, and inverse, and the output schema handles return values. The omission of any doc_id guidance is the main remaining gap.

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 description coverage is 0%, so the description must compensate for all 10 parameters. It explains selection, rect, drawing_text, svg_path, svg_d, spec, scale, inverse, and mode with useful format and precedence details. The only parameter not addressed at all is doc_id, which keeps this from being fully complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and resource: set, add, or remove a clip on selected lines. It clearly distinguishes the three modes, but it does not explicitly differentiate this tool from siblings like ass_remove_clip or ass_get_clips, so an agent still has to infer when this combined tool is preferable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear operational context: mode semantics, the default selection behavior, and geometry precedence. However, it does not state when to use this tool versus its sibling alternatives such as ass_remove_clip or ass_convert_clip_scale, nor does it give any exclusions.

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

Deploy Server

Other Tools