Parse WebVTT, SRT, or TTML for conformance, timing, overlaps, line length, and reading speed.
Scored across 2 tools
The two tools are clearly separated by operation: caption_check handles a single file, while caption_compare explicitly handles exactly two files and even directs users to caption_check for single-file use. There is no functional overlap or ambiguity between them.
Both tool names follow the same caption_ + verb pattern: caption_check and caption_compare. The naming is predictable and clearly conveys each tool's action.
With only two tools, the server is minimal but appropriately scoped for its narrow purpose of caption-file validation and comparison. The count is slightly below the typical 3-15 range, but each tool earns its place and there is no unnecessary bloat.
The domain is caption-file preflight checking, and the server covers both core operations: validating a single file and comparing two files. There are no obvious dead ends or missing lifecycle operations for this read-only validation purpose.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
Compare exactly two caption or subtitle files under identical bounded checks: an original versus its translated track, before versus after a timing fix, or a format migration. Attach two WebVTT, SRT, or TTML/IMSC caption files in chat or give two publicly fetchable URLs and it runs the same SSRF-guarded, 2 MB-capped preflight as caption_check on each, then aligns them by cue index and reports side-by-side pass status, detected-format and encoding differences, the cue-count delta, timing drift and overlap differences, reading-speed (CPS) regressions, structural-error deltas, and a winner only when the measured checks separate the two. Use caption_check for a single file. It reports only source-file conformance, timing, encoding, and reading-speed facts against a dated profile: never translation quality, transcription accuracy, or sync against the video. Fetching and parsing two live files can take up to 60 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | No | Exactly two public caption URLs to compare, in the order they should appear side by side (for example original then translated). Provide either this or files, never both. STRICT RULE: Caption compare failed — provide either two caption URLs or two attached caption files, not both STRICT RULE: Caption compare failed — provide two public caption URLs or attach two caption files | |
| files | No | Exactly two caption files attached in chat to compare, in the order they should appear side by side (for example original then translated). Provide either this or urls, never both. | |
| profile | No | Named reading-speed profile applied to both tracks. netflix-adult-20 (default), netflix-children-17, youtube, ebu-tt. |
| Name | Required | Description |
|---|---|---|
| notes | Yes | Notes about incomplete checks or completion under identical limits |
| tracks | Yes | The two tracks in input order |
| winner | No | Track with fewer weighted structural, timing, reading-speed, and line-length problems |
| profile | Yes | Reading-speed and line-length profile applied to the caption checks |
| checkedAt | Yes | ISO timestamp when the caption result was produced |
| comparison | No | Measured differences between the two successfully preflighted tracks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: SSRF-guarded and 2 MB-capped preflight, alignment by cue index, the specific comparison dimensions (cue-count delta, timing drift, CPS regressions, structural-error deltas), and the explicit non-goals (never translation quality, transcription accuracy, or sync against video). It also discloses the up-to-60-second fetch/parse time. The only minor gap is that it doesn't describe the exact output shape, but an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: it front-loads the core purpose and use cases, then the input modes, then the comparison dimensions, then the sibling routing, then the non-goals and latency caveat. Every sentence earns its place, though the long middle sentence listing all comparison dimensions is a bit heavy. It is appropriately sized for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a comparison tool with an output schema, 100% schema coverage, and read-only annotations, the description is complete. It covers what the tool does, how to provide inputs, what it checks, what it deliberately does not check, the sibling alternative, and the latency expectation. An agent has everything needed to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all three parameters (urls, files, profile) with detailed descriptions and strict rules. The description adds the ordering semantics ('in the order they should appear side by side') and the profile's role ('applied to both tracks'), but it doesn't add much beyond what the schema already provides. Baseline 3 is appropriate when the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Compare'), a precise resource ('exactly two caption or subtitle files'), and enumerates concrete use cases (original vs translated, before/after timing fix, format migration). It also explicitly distinguishes itself from the sibling caption_check by naming the single-file alternative, so an agent can tell them apart 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('Use caption_check for a single file') and clear input modes (two attached files or two public URLs, never both). It also states the strict either/or rule and the 60-second latency expectation, so the agent knows the operational context before invoking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
caption_checkcaption_compareConvert subtitles, transcripts, broadcast captions (SCC/MCC/STL), EDLs, and Premiere files.
Validate JSON, YAML, XML and CSV with exact line/column errors and silent-corruption warnings.
Verbatim transcription of public video/audio URLs to clean text, SRT, and timestamped records.
Transcribe audio & video: diarization, timed SRT/VTT, podcasts, paste-a-link, whole-feed batch.
