Any Video to Text

Translate a transcript

translate_video

Idempotent

Translate a public video's transcript line by line. Long videos come in parts: call with part 0, then each part up to the number of parts it returns. If the video has not been transcribed yet it is transcribed first (same cost and waiting as get_transcript, so it may answer that it is still running with a jobId; then call transcribe_status and call translate_video again). Free accounts get about an hour of video per day.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>",
      "to": "<to>"
    },
    "name": "translate_video"
  }
}

Input Schema

Name	Required	Description
`ai`	No	true to use the AI version of the transcript, when list_my_transcripts or get_my_transcript says the saved one is AI.
`to`	Yes	The language to translate into.
`url`	Yes	Link to one public video: a TikTok, YouTube (including Shorts), Instagram Reel/post, Facebook or X video URL.
`part`	No	Which part to get, starting at 0.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The description adds behavior well beyond what the annotations state: transcription cost/waiting is incurred on first use, an async jobId path exists, pagination is bounded by a returned part count, and free accounts get roughly an hour of video per day. These quota and async-chaining disclosures are exactly the operational context annotations cannot express, and they are consistent with readOnlyHint=false and idempotentHint=true.

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?

Four sentences, front-loaded with the purpose, then the pagination protocol, then the not-yet-transcribed fallback, then the quota caveat. Every sentence carries information; the parenthetical about get_transcript cost is slightly dense but justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-shape burden and does so adequately by naming the parts count and the jobId-while-running response. It could additionally state whether repeat calls reuse a cached translation or re-bill, and what a completed part payload looks like, but nothing essential to calling it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning for the 'part' parameter (its upper bound comes from the part count the previous call returns) and implicitly explains the fallback transcription path that makes the first call behave differently. It says nothing extra about 'to' or 'ai', which are already fully documented in the schema.

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+resource+unit: 'Translate a public video's transcript line by line.' That is clearly differentiated from retrieval siblings like get_transcript (which returns the original transcript) and from transcribe_status (which only reports job state). The scope word 'public' is also informative.

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?

It gives concrete invocation guidance: start at part 0 and increment up to the returned part count, and if the video is not yet transcribed, expect a jobId, call transcribe_status, then re-call this tool. What it lacks is an explicit exclusion such as 'use get_transcript if you want the original language' or guidance on when to prefer summarize_video / ask_video.

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

All Any Video to Text 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?