Tanod MCP server

utilpeek: convert subtitles between SRT, WebVTT and JSON

convert_subtitles

Read-onlyIdempotent

Convert between SRT, WebVTT, and JSON subtitle formats, with optional time shifting. Reformat or retime cues for editing, playback, or transcription workflows.

Instructions

utilpeek: Convert subtitles between SRT, WebVTT and JSON, with a time shift. To make subtitles from audio use transcribe_audio. Returns a subtitle file converted between SRT, WebVTT and a JSON segment list [{start, end, text}] (seconds, as /v1/audio/transcribe returns it), with an optional time shift in milliseconds. Strict parsing: the input format is detected, a malformed cue is named in a 422. At most 1,000,000 characters and 10,000 cues. Malformed subtitles (bad timing line, end before start, empty cue, over the limits) are a 422 naming the cue (not charged). A negative shift clamps starts at 0 and drops cues that end before 0. Typically under 0.3 s. Price: USD 0.002. Free: 10 utilpeek calls per IP per UTC day. Docs: https://tanod.dev/learn/subtitle-converter-api.html

Input Schema

TableJSON Schema

Name	Required	Description
`to`	Yes	Output format: srt (SubRip), vtt (WebVTT) or json (a list of {start, end, text}, seconds).
`content`	No	The SRT or WebVTT file as text (at most 1,000,000 characters, 10,000 cues). The format is detected from a WEBVTT header unless from_format is given. Use this or segments.
`segments`	No	A JSON segment list [{start, end, text}] in seconds, as /v1/audio/transcribe returns it. Use this or content.
`shift_ms`	No	Time shift in milliseconds for every cue (negative = earlier; a cue that ends before 0 is dropped).
`from_format`	No	Optional input format check: content is srt or vtt, segments are json.

Output Schema

TableJSON Schema

Name	Required	Description
`to`	No
`cues`	No
`from`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`output`	No
`dropped`	No
`duration`	No
`segments`	No
`shift_ms`	No
`operation`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations declare the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial operational detail beyond that: strict parsing with cue-named 422s, limits of 1,000,000 characters and 10,000 cues, free-request behavior, that failures are not charged, negative-shift clamping/dropping, typical latency, and price. This is unusually rich disclosure for a read-only 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 opening sentence front-loads the core action and time shift, and later sentences carry genuinely useful operational facts. It is dense and includes some detail already present in the schema (format detection, shift clamping), but nothing is padding and it stays scannable.

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?

With an output schema present, the description needn't explain returns, yet it still covers formats, limits, error behavior, latency, pricing, and free-tier rules. An agent has everything needed to call it correctly, and the sibling routing removes the main ambiguity.

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 both the shift semantics and the format-detection rule are already documented in the schema. The description largely repeats these ('with an optional time shift in milliseconds', negative-shift behavior) with little added syntax or format detail, so the baseline of 3 applies.

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 (Convert) plus resource (subtitles) and enumerates the formats (SRT, WebVTT, JSON) and the time-shift capability. It also distinguishes itself from transcribe_audio, the sibling that produces subtitles from audio. An agent can identify the tool's function 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 Guidelines4/5

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

Explicitly routes the from-audio case to transcribe_audio, giving a clear when-to-use boundary. However, it doesn't spell out when to prefer content vs segments (that choice lives only in the schema) nor warn against using convert_data for subtitles. Clear context, but no explicit exclusions beyond the one sibling callout.

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

Deploy Server