Skip to main content
Beta. The Video API MCP server is in beta. Tool names and schemas are stable for the beta (additions may land; nothing is removed without notice). Jobs are billed to the organization you approve (hosted) or your API key’s account (headless): see Billing & Limits.

What you get

An MCP server that exposes the full Video API as native agent tools — all 44 capabilities in the capabilities reference, with client-side schema validation, automatic submit-and-poll, and results returned as artifact URLs or structured analysis JSON. Your agent edits video by calling tools; you connect with one OAuth login (or an API key in headless environments).

Connect your agent

One OAuth login — approve access in the browser and your agent is ready. No API key to create or paste. Jobs bill to the organization you approve on the consent page. Approving requires an active dashboard session — if you’re signed out, the consent page routes you through sign-in and back to the approval automatically.
Adding registers the server but does not connect it — it waits as pending approval. Run /mcp inside Claude Code, approve eachlabs-video, and log in when prompted; the video tools appear once the login completes.

Headless and CI (API key)

Environments without a browser (CI runners, servers) run the same MCP server locally over stdio, authenticated with an API key from Settings → API Keys in your eachlabs dashboard; jobs bill to the key’s account. The local server is named video so it can coexist with the hosted eachlabs-video. Add the mcpServers entry to your client’s stdio config — for Claude Code, .mcp.json in the project root:
Codex uses the TOML equivalent in ~/.codex/config.toml:
For reproducible CI, pin the version (npx -y @eachlabs/[email protected]) instead of tracking latest.
npm rollout: the @eachlabs/video-api-mcp package is rolling out during the beta. If npx cannot find the package yet, use the hosted connection above.
The server targets the eachlabs-video-api model slug by default — no extra configuration is needed. EACHLABS_VIDEO_MODEL exists only to override that default.

Use it

Ask your agent to do video work with any publicly downloadable media URL — inputs are staged automatically (see Quickstart — inputs); s3:// URIs from onboarding also work. No public URL at hand? Make one from any local video: ask the agent to call upload_file with the file’s path — it uploads the file to eachlabs storage and returns a public_url (the underlying REST endpoint is upload-file). Use that URL as the input:
“Trim the first 12 seconds of YOUR_INPUT_URL, burn the captions from this SRT, and give me the result URL.”
The agent chains the trim and captions tools; each tool call returns the hosted artifact URL (or JSON for the analysis capabilities) plus the billed cost.

Tool inventory

One tool per wrapped capability — same names and parameters as the capabilities reference (the keep_ranges/silence_remove pair is exposed under its original wire name, silence_remove) — plus run_ffmpeg (raw ffmpeg for beta organizations; contract and safety boundary in run_ffmpeg), get_job for checking a long-running job later, and upload_file for uploading a local file to eachlabs storage and returning the public_url to pass as input. Parameters are validated client-side before submit and again by the engine. A call that doesn’t match the tool’s schema — including a parameter the tool doesn’t declare — is rejected before anything is submitted: nothing reaches the engine and nothing bills.

Notes for agent builders

  • Long jobs: the server polls with backoff; if a job outlives the polling budget — the hosted server holds up to ~4 minutes, the local stdio server defaults to 5 minutes (configurable via EACHLABS_POLL_TIMEOUT_MS) — the tool returns the prediction ID and your agent resumes with get_job.
  • Billing semantics are identical to the REST surface: Billing & Limits.
Policies: Acceptable Use · Abuse & Takedown · Versioning & Deprecation
Last modified on August 16, 2026