aegisub-mcp

Overview Schema Source Related Servers Discussions Admin

ass_wrap_range

Wrap a character range in an ASS override block and restore the outer styling after it. Supports visible or raw index scopes for precise subtitle edits.

Instructions

Wrap a character range in an override block, restoring the outer state.

Args: index / text / doc_id: the line to edit (0-based index of doc_id or a raw string). start: range start. A plain index when scope="plain" (the default), a raw index when scope="raw". end: range end, exclusive. Same index system as start; None means "to the end of the line" (the visible end / the raw end). override: the tags to apply, with or without the surrounding braces and with or without the leading backslash (r"\fscx200", "fscx200" and r"{\fscx200}" are all accepted). Braces and line breaks inside the payload are rejected. doc_id: document holding index. scope: "plain" (default) counts only visible characters — override blocks and the \N/\n line-break escapes are not counted, so the same start/end cover the same glyphs no matter how many tags precede them. "raw" counts every stored code point including braces, which is what you want when you already have offsets into the stored Text field. A raw boundary that would land inside an override block is refused with a ToolError instead of silently splitting the block. in_place: write back to the document (snapshot-backed). The raw-string mode never writes.

The tags that were in effect before start are re-emitted after end when they changed inside the range, so the override applies to exactly the requested characters. warnings reports tags that had no previous value to restore (there is nothing to restore for e.g. \an).

Returns {"source", "index", "doc_id", "scope", "start", "end", "raw_start", "raw_end", "plain_start", "plain_end", "override", "text", "plain_text", "changed", "written", "warnings"}. start/end are echoed in the requested index system; plain_start/plain_end are always plain (visible character) indices and raw_start/raw_end are always raw offsets into the stored line, so the two systems stay comparable no matter which one was passed in.

Input Schema

TableJSON Schema

Name	Required	Default
`end`	No
`text`	No
`index`	No
`scope`	No	plain
`start`	No
`doc_id`	No
`in_place`	No
`override`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 12, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses that pre-existing tags are re-emitted after end, that warnings lists tags with no restorable prior value (e.g. \an), that raw boundaries inside a block raise a ToolError rather than splitting silently, and that in_place writes to a snapshot-backed document while raw-string mode never writes.

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?

Front-loaded with a one-line purpose, then organized into an Args block and a returns paragraph, so it is easy to scan. It is longer than strictly necessary and repeats some scope detail, but for an 8-parameter tool with zero schema descriptions the length is largely earned.

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?

Given a complex 8-param tool, 0% schema coverage and an output schema, the description is complete: it documents inputs, the return field set (and explains the dual plain/raw index echoes), and side-effect behavior. Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 0%, so the description must compensate and it does: every parameter is explained, including the index/text/doc_id polymorphism, end exclusivity and None meaning end-of-line, the flexible override payload format with its brace/newline restrictions, and the exact semantics of scope.

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?

States a specific verb+resource: wrapping a character range in an override block while restoring the outer state. That is precise and distinguishes it from generic mutation tools. It does not, however, name which of the many nearby tag siblings (ass_apply_tag_to_block, ass_set_tag, ass_insert_tag_at) it should be preferred over.

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

Usage Guidelines3/5

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

There is strong conditional guidance on choosing scope="plain" vs "raw" (visible-char counting vs stored offsets, and the refusal when a raw boundary splits a block). But there is no explicit when-to-use statement relative to the sibling tag-manipulation tools, so tool selection is left to inference.

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

Deploy Server