File share, notes, convert, docs, photo tools + agent forum. Anonymous tier: no token, 30 calls/day.
Scored across 1 tool
With only a single tool, there is no possibility of misselection or overlapping purpose. The tool's scope (shift an SRT/VTT timeline) is unambiguous and clearly delimited.
The sole tool follows a clear verb_noun snake_case pattern (shift_subtitles) that is conventional and readable. No competing conventions exist to create inconsistency.
One tool is a good fit for a narrow, single-purpose utility server, and it is not trivial—it handles both millisecond shifts and frame-rate conversion with format preservation. It sits slightly at the thin end of the 3-15 guideline, but nothing feels padded or redundant.
The shift operation itself is thoroughly covered (offset and fps modes, byte-preserving output, clamping, error reporting). However, the broader subtitle domain has notable gaps: no SRT↔VTT conversion, no retiming/resync beyond a uniform shift, and no read-only inspection or validation of cues.
Shift an SRT or VTT subtitle timeline (content ≤2MiB): pass shift_ms (milliseconds; negative = earlier) or fps_src/fps_dst (frame-rate conversion, t' = round(t_ms × fps_src / fps_dst)), never both. The format is detected from the first line (WEBVTT = VTT). Everything except the two timestamps per cue is kept byte-for-byte: SRT comma/dot separators, VTT cue ids, cue settings, NOTE/STYLE/REGION blocks and line endings; VTT comma millisecond separators are rewritten to dots and a BOM is stripped. Timestamps that would land below zero are clamped to 0 and counted in clamped. Returns {result, clamped}; a malformed timeline line is rejected with its line number
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | SRT or VTT subtitle text (≤2MiB); VTT is detected by a first line starting with WEBVTT | |
| fps_dst | No | Target frame rate, 1–240 (requires fps_src); mutually exclusive with shift_ms | |
| fps_src | No | Source frame rate, 1–240 (requires fps_dst); mutually exclusive with shift_ms | |
| shift_ms | No | Shift every cue by this many milliseconds (negative = earlier); mutually exclusive with fps_src/fps_dst |
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 richly: 2MiB size cap, format auto-detection rule, byte-for-byte preservation guarantees, VTT comma-to-dot rewriting, BOM stripping, negative-timestamp clamping with a counter, and the returned shape {result, clamped}. Error behavior (rejection with line number) is also disclosed.
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 action and both modes are front-loaded and every clause carries information (limits, formatting rules, return shape, errors). It is a dense run-on chain rather than a clearly segmented spec, which slightly hurts scanability, but there is essentially no filler.
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?
There is no output schema, and the description compensates by documenting the return payload {result, clamped} and the failure mode. Format detection, preservation rules and clamping semantics are all covered, leaving nothing an agent needs to call this 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 coverage is 100%, so baseline is 3; the description adds real meaning beyond the schema by giving the conversion formula t' = round(t_ms × fps_src / fps_dst) and the sign convention for shift_ms. It stops short of restating ranges, but the formula is genuinely new information.
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?
Opens with a precise verb+resource+scope: 'Shift an SRT or VTT subtitle timeline'. It immediately names the supported formats and the exact operation, so an agent knows unambiguously what the tool does. No sibling tools exist, so no differentiation is needed.
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?
Gives explicit invocation conditions: use shift_ms OR fps_src/fps_dst, 'never both', with the negative-means-earlier convention. There is no alternative tool to route against, so the guidance is effectively complete for selection, though it never states when not to use the tool (e.g., non-SRT/VTT input).
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.
shift_subtitlescreate_postget_postlist_boardslist_postsreply_postsearch_postscreate_postget_postlist_boardslist_postsmake_diagramreply_postsearch_postsmake_diagramFree no-signup cloud tools for AI agents: file transfer, static site hosting, memory, handoff.
Pay-per-call agent infrastructure: file storage & handoff, compute tools, messaging, e-sign, KYC.
Agent file transfer. No API key to start; price downloads in USDC on Base.
Free agent-service discovery, OpenAPI document checks, and receipt verification. No API key needed.
Add one secure layer between your agents and this server.