Zovo Subtitle Fix

Fix subtitles

fix_subtitles

Read-onlyIdempotent

Use this when the user wants to fix subtitle timing or convert subtitles: shift an SRT or VTT file earlier or later, convert it from one frame rate to another (23.976, 24, 25, 29.97, 30, 50, 59.94, 60), sync it on two cues, trim overlapping cues, give short cues a minimum duration, strip formatting tags, renumber, or convert SRT to WebVTT and back. Takes one attached .srt or .vtt file (or the subtitle text) and returns the fixed file and a CSV change log with old and new times per cue. Times are whole milliseconds, rounded half up. Does not listen to audio or find the right offset by itself, does not translate or edit the words, and does not read SSA/ASS files.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "fix_subtitles"
  }
}

Input Schema

Name	Required	Description
`file`	No	The subtitle file: one .srt or .vtt file in UTF-8 or UTF-16 with a byte order mark, e.g. movie.srt.
`sync`	No	Two-point sync: cue_a should start at time_a and cue_b at time_b; all times are mapped on that straight line. Do not combine with shift_ms or frame rates.
`gap_ms`	No	Gap kept before the next cue when fixing overlaps or extending cues, 0 to 1000 ms, e.g. 1 (default).
`to_fps`	No	Frame rate of the video they should match, e.g. 23.976. One of 23.976, 24, 25, 29.97, 30, 50, 59.94 or 60. new time = old time x from_fps / to_fps.
`from_fps`	No	Frame rate the subtitles were timed for, e.g. 25. One of 23.976, 24, 25, 29.97, 30, 50, 59.94 or 60. Use with to_fps.
`renumber`	No	SRT output: true (default) numbers cues 1, 2, 3 in output order; false keeps the numbers as written.
`shift_ms`	No	Move all cues by this many milliseconds: positive = later, negative = earlier, e.g. 2500 (2.5 s later) or -1200. Limit 24 hours.
`strip_tags`	No	true removes formatting tags such as <i>, <b>, <u>, <font>, WebVTT <c>/<v> tags and {\an8} codes from the text. Default false.
`fix_overlaps`	No	true: when a cue ends after the next cue starts, or less than gap_ms before it, its end moves to gap_ms before that start. Default false.
`line_endings`	No	Line endings of the output, e.g. crlf. Default same as the input (CRLF, LF, or CR for old Mac files).
`output_format`	No	Output format, e.g. vtt to convert SRT to WebVTT. Default same as the input.
`sort_by_start`	No	true writes cues in start-time order (stable). Default false keeps the file order.
`subtitle_text`	No	Instead of a file: the subtitle text itself, e.g. "1\n00:00:01,000 --> 00:00:03,000\nHello". Use either file or subtitle_text.
`min_duration_ms`	No	Make short cues last at least this long, up to gap_ms before the next cue, e.g. 1000. 0 (default) = off. Limit 10000.

Output Schema

Name	Required	Description	Default
`file`	Yes
`check`	Yes
`notes`	Yes
`counts`	Yes
`timing`	Yes
`cues_in`	Yes
`removed`	Yes
`cues_out`	Yes
`encoding`	Yes
`log_name`	Yes
`downloads`	Yes
`format_in`	Yes
`format_out`	Yes
`output_name`	Yes
`changes_preview`	Yes
`expires_in_hours`	Yes
`changes_preview_count`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description just needs to add context, and it does: it states the accepted inputs (one .srt/.vtt in UTF-8 or UTF-16 with BOM, or raw text), the outputs (fixed file plus a CSV change log with old and new times per cue), and the numeric policy (whole milliseconds, rounded half up). No contradiction with readOnlyHint — the tool transforms and returns, it doesn't mutate in place.

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 the triggering condition, then capabilities, then output contract, then exclusions — a sensible order. It is dense but nearly every clause carries information. Minor waste: re-listing all eight frame rates, which the schema already enumerates twice.

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 14-parameter tool with nested objects, this is thorough: input form, output form (file + CSV change log), rounding semantics, and explicit out-of-scope capabilities are all stated. The existence of an output schema absolves it from describing return structure in detail, and the remaining gaps are covered by 100% schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter including the frame-rate set and the 'do not combine sync with shift_ms or frame rates' constraint. The description's contribution is mostly a narrative mapping of operations to parameters (sync on two cues, trim overlaps, minimum duration) plus the rounding rule, which is modest added meaning. Baseline 3 applies since the schema is doing the heavy lifting.

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?

Opens with a specific verb+resource ('fix subtitle timing or convert subtitles') and then enumerates the concrete operations it performs: shift, frame-rate conversion, two-point sync, overlap trimming, min duration, tag stripping, renumbering, SRT↔WebVTT. Negative scope ('does not translate or edit the words') further pins down what class of tool it is. It stops short of naming the sibling check_subtitles, so an agent must infer fix-vs-check on its own.

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?

Explicit triggering condition: 'Use this when the user wants to fix subtitle timing or convert subtitles.' When-not guidance is present in the negative clause ('does not listen to audio or find the right offset by itself'). What's missing is routing to an alternative tool — e.g. telling the agent to use check_subtitles when the problem still needs diagnosing.

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

All Zovo Subtitle Fix 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.

Resources

Need Help?