Skip to main content
Glama

ass_export_text

Export selected Aegisub/ASS subtitle lines as plain text, TSV, SRT, or raw Dialogue/Comment fragments to a file or workspace output path.

Instructions

Export selected lines as plain text, TSV, SRT or an ASS fragment.

Args: selection: selection spelling; None = every line. doc_id: document to export; the current one when omitted. format: "txt" (one line of plain text each), "tsv" (start, end, style, actor, effect, kind, plain text), "srt" (SubRip) or "ass-fragment" (the raw Dialogue:/Comment: lines). line_separator: replacement for the ASS in-line hard break \N (and \n) in txt/tsv output. The default keeps the ASS escape for lossless re-import; pass "\n" for one output line per visual line, or any other string ("|") to flatten explicitly. srt always uses real newlines (required by the format) and ass-fragment keeps the original text untouched. output_path: file to write; when omitted the file is written into workspace.output_dir (created if needed).

txt and srt skip comment lines; tsv and ass-fragment keep them. Returns {"doc_id", "path", "format", "media_type", "text", "bytes", "line_count", "selection": [<0-based indices>]} where line_count is the number of exported records (SRT blocks, TSV rows, text lines, events).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
doc_idNo
formatNotxt
selectionNo
output_pathNo
line_separatorNo\N

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/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 so well: it discloses that txt/srt skip comment lines while tsv/ass-fragment keep them, that the default separator preserves the ASS escape for lossless re-import, and that output_path defaults into workspace.output_dir which is created if needed. It omits file-overwrite behavior, permission/auth requirements, and failure modes, keeping it short of a 5.

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?

Purpose is front-loaded in the first line, then parameters are laid out in a scannable Args block followed by the two format-dependent behaviors and the return shape. Slightly long, but each sentence adds distinct information and nothing is redundant.

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 five-parameter, zero-schema-description export tool, this is complete: every parameter is explained, format-specific comment-line handling is called out, and the return payload is enumerated. Nothing an agent needs in order 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: all five parameters are documented with meaning beyond the schema, including the four format values and their output shapes, the exact semantics of line_separator with worked examples ('\n', '|'), and the defaults for selection, doc_id and output_path.

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?

States a specific verb (export) plus a precisely scoped resource (selected lines) and enumerates the four output formats, which implicitly separates it from siblings like ass_plain_text or ass_karaoke_export. An agent can tell what it produces without opening the schema.

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?

The description gives useful in-parameter guidance (selection=None means every line, doc_id defaults to the current document, which line_separator value to pick for wrapping vs lossless re-import), but it never states when to choose this tool over alternatives such as ass_plain_text or ass_karaoke_export. Usage is implied through parameter semantics rather than stated.

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