From intent
to output.
MCP access to the same processing API and account allowance your scripts use.
Connect with OAuth.
Use your configured service origin followed by /mcp/server in
a client supporting Streamable HTTP and the current MCP authorization profile.
This build is a local preview; public hosting is not configured.
- Enter the endpoint in your client. Discovery opens the existing sign-in page, followed by a permission review.
- Check the client identifier and permissions. Processing uses your existing allowance; billing, API keys and admin controls are excluded.
- Review or revoke access under agent connections. Revocation blocks subsequent requests immediately. Previously accepted jobs keep running.
Remote tools: get_usage, list_jobs, create_job, get_job, cancel_job and get_outputs.
Upload through the website, authenticated REST API or local connector,
then pass owned file IDs to remote jobs. Remote MCP cannot read a
filename on your computer, import a URL or carry base64 media. Output
URLs returned by get_outputs require authentication through the
same API; they are not public download links.
Client ID Metadata Documents (CIMD) are supported with secure HTTPS discovery. Anonymous dynamic client registration is disabled. Clients requiring DCR need a separate compatibility decision; support in every desktop host is not claimed. Operators can configure managed local test clients without exposing public registration.
One workflow, end to end.
Let your agent upload media, submit an FFmpeg job, check its progress and save the result. Processing uses your account’s normal quota and isolated workers.
get_usage- Check available processing time and storage.
upload_file- Upload an authorized video, audio file or image.
create_job- Run FFmpeg with a stable UUID for safe retries.
list_jobs / get_job- Track your account’s jobs and output metadata.
delete_job_outputs- Delete result files on request; keep inputs and history.
download_result- Save a finished output into your selected folder.
cancel_job- Stop queued or running work and follow its actual state.
For example: place a video and a PNG logo in your selected input folder, then ask your agent to add a watermark. Each file is an ordinary job input. Current preview limits apply.
Connect Codex
- Use Python 3.12+ and this project checkout. Install
requirements-mcp.lock, then install the checkout withpython -m pip install -e . --no-deps. - Create a personal key in your account with
usage:read,files:write,jobs:write,jobs:readandoutputs:read. Keep it in your client’s private environment asVIDEO_WORKER_API_KEY. - Create separate input and output folders. The connector accepts flat media filenames inside those folders; it never overwrites an existing result.
- Add the configuration below to Codex’s MCP settings. Replace the absolute paths and use the service origin for your installation. Restart the client to load the server.
[mcp_servers.videoworker]
command = "/absolute/path/to/python"
args = ["-m", "videoworker_mcp"]
cwd = "/absolute/path/to/project"
env_vars = ["VIDEO_WORKER_API_KEY"]
[mcp_servers.videoworker.env]
VIDEO_WORKER_API_URL = "http://localhost:18887"
VIDEO_WORKER_UPLOAD_ROOT = "/absolute/path/to/media-input"
VIDEO_WORKER_DOWNLOAD_ROOT = "/absolute/path/to/media-output" On Windows use paths such as C:/path/to/python.exe. A
private key file can be selected with VIDEO_WORKER_API_KEY_FILE instead of forwarding the key itself.
Never place keys in a repository or media folder.
Clear access. Predictable retries.
The local connector has access to the two folders you explicitly configure. Your key authorizes only its selected API scopes. Account and admin controls are separate.
Choose one UUID for each intended job. Retry an uncertain submission with the same UUID and identical arguments for 48 hours. A changed request conflicts; an expired original job is reported as expired. Upload retries are separate and can create another uploaded file.
Poll about once per second. Closing a tool call does not stop server
work: use cancel_job and wait for a terminal state.
The connector speaks standard MCP over STDIO. Compatibility is verified with the official SDK client; individual desktop hosts need their own connection check. The local STDIO connector requires a local installation. Remote OAuth access uses the separate endpoint above.
REST reference ↗