Caption File Check

caption_check

Read-only

Preflight one caption or subtitle file before delivery. Attach a WebVTT (.vtt), SRT (.srt), or TTML/IMSC (.ttml/.xml) caption file in chat or give a publicly fetchable URL and it downloads the artifact under an SSRF-guarded, 2 MB-capped fetch, detects the format by content and the byte encoding and BOM, then parses it with the real spec engine (the WebVTT spec parser, a dedicated SRT parser, or the imscJS TTML/IMSC profile engine) and returns deterministic evidence: pass/fail, cue count, structural spec and IMSC profile-conformance errors, overlapping / negative / out-of-order / empty cues, per-line length, and per-cue and summary reading speed (CPS) against a named platform profile (netflix-adult-20, netflix-children-17, youtube, ebu-tt). It reports only source-file conformance, timing, encoding, and reading-speed facts against a dated profile. It does not judge translation quality, transcription accuracy, or synchronization against the video. An arbitrary XML or text file that is not a caption track returns an explicit unsupported-format error. Fetching and parsing a full-length track can take up to 60 seconds.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	No	A publicly fetchable HTTP(S) URL of a WebVTT, SRT, or TTML/IMSC caption file, detected by content not extension. Provide either this or an attached file, never both. Query strings are allowed but never logged. Pasted caption bodies, data URLs, FTP/SFTP, and URLs needing credentials, headers, or cookies are not supported. STRICT RULE: Caption check failed — provide either a caption URL or an attached caption file, not both STRICT RULE: Caption check failed — provide a public caption URL or attach the caption file
`file`	No	A caption file attached in chat (WebVTT, SRT, or TTML/IMSC), detected by content not extension. Provide either this or url, never both.
`profile`	No	Named reading-speed profile to judge CPS and line length against. netflix-adult-20 (default, 20 CPS) and netflix-children-17 (17 CPS) are spec-backed; youtube and ebu-tt are advisory ~17 CPS heuristics.

Output Schema

TableJSON Schema

Name	Required	Description
`bom`	Yes	Byte-order-mark detected: utf-8, utf-16le, utf-16be, or none
`cps`	Yes	Per-cue and summary reading-speed measurements
`url`	Yes	The checked caption source: the submitted URL query- and fragment-stripped, or the attached file's name
`pass`	Yes	True when the file passes all checked format, timing, line-length and reading-speed criteria for the selected profile. False can include an advisory readability threshold breach, not just a specification error; this is not a platform-acceptance verdict
`timing`	Yes	Measured cue timing and empty-text findings
`profile`	Yes	Reading-speed and line-length profile applied to the caption checks
`cueCount`	Yes	Number of caption cues retained for checking
`encoding`	Yes	Detected byte encoding of the caption file
`specUsed`	Yes	The dated spec identifier the detected format was checked against
`checkedAt`	Yes	ISO timestamp when the caption result was produced
`lineLength`	Yes	Per-line character counts checked against the profile limit
`truncation`	Yes	Markers identifying checks truncated by configured limits
`rawCueCount`	Yes	Cues parsed before the 20,000-cue cap
`ttmlProfile`	No	IMSC/TTML profile designator declared in the file, when present
`detectedFormat`	Yes	webvtt, srt, or ttml (covers IMSC), detected by content
`structuralErrors`	Yes	Spec-parser and IMSC/TTML profile-conformance findings
`structuralErrorCounts`	Yes	Counts of structural findings grouped by severity

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnlyHint/destructiveHint annotations, the description discloses substantial behavioral detail: SSRF-guarded fetch, 2 MB cap, format detection by content rather than extension, the specific parser engines used, deterministic output, a potential 60-second runtime, and an explicit unsupported-format error for non-caption files. This is exemplary transparency for a complex tool.

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?

The description is long, but every sentence carries operational value: input modes, fetch constraints, parsing engine, evidence returned, explicit non-goals, error behavior, and timeout. It is front-loaded with the core purpose and scopes the tool before diving into mechanics. It could be slightly trimmed, but for the tool's complexity the length is 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 the tool's complexity, the description is complete: it covers supported input delivery methods, unsupported URL types, size and safety limits, output categories, profile names, non-goals, error handling for non-caption files, and worst-case runtime. An output schema exists, so the absence of a detailed return-value explanation is not a gap. An agent has everything needed to invoke this tool correctly.

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 url, file, and profile including the profile enum meanings and the default. The description adds behavioral context (content detection, fetch limits, timeout) but no additional parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate.

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?

The description opens with a specific verb and resource: "Preflight one caption or subtitle file before delivery," then enumerates supported formats and the exact evidence returned (pass/fail, cue count, timing errors, reading speed). This makes the tool's purpose unmistakable and clearly distinct from the sibling caption_compare, which by name is a comparison operation.

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 establishes a clear use context: validating a single caption/subtitle file against spec, timing, encoding, and reading-speed profiles before delivery. It also states exclusions — it does not judge translation quality, transcription accuracy, or synchronization against video — which helps an agent decide when not to use it. However, it never explicitly names caption_compare or says 'use this instead when comparing two files,' so it stops short of a 5.

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

All Caption File Check tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?