Video transcoding has always been the kind of infrastructure that software engineers automate and everyone else emails someone to do. Qencode, a cloud transcoding API vendor, just shipped a Model Context Protocol server that removes the middle step. The connector lets any MCP-compatible client, from Claude to Cursor to ChatGPT, submit, monitor, and reason about transcoding jobs in plain English.
The pitch is simple. Ask your agent to “transcode this video as an HLS ladder at 1080/720/540/360 and put it in my R2 bucket,” and the agent picks the hls_abr recipe, fills in per-rendition encoding parameters, submits via start_encode2_raw, and polls until the job completes. No API keys in client config, no reading a 200-page API reference, no hand-writing JSON. The agent does the plumbing.
What makes this worth attention is not the convenience. It is the pattern. Qencode is one of the first established infrastructure vendors to treat the AI agent, not the developer, as the primary API consumer. The MCP server ships with a knowledge base of recipes, 21 slash-command prompts, and a security model designed around OAuth 2.1 rather than static keys. That is a bet on where the industry is heading, and it is a bet worth examining.
The agent as API consumer
The Qencode MCP server exposes eleven tools. Seven handle transcoding and jobs: transcode_video, start_encode2_raw, get_job_status, get_job_status_detailed, wait_for_job, search_qencode_docs, and fetch_qencode_doc. Four handle media storage: list_buckets, create_bucket, list_objects, and get_download_url. The transcode_video tool is a convenience wrapper that auto-injects encoder_version: 2 when omitted. start_encode2_raw is the escape hatch for advanced workflows, accepting the full query JSON exactly as the Qencode API expects.
The design philosophy is explicit in the documentation. The server ships a knowledge base of recipes and reference docs, exposed as MCP resources so the agent can fetch only what it needs. Notable URIs include qencode://docs/best-practices, qencode://docs/error-codes, and qencode://docs/gotchas. There are recipe resources for hls_abr, mp4_ladder, audio_outputs, thumbnails, speech_to_text, subtitles, stitching, drm_widevine_ezdrm, drm_fairplay_ezdrm, drm_playready_ezdrm, codec_av1, per_title_encoding, incremental_abr, and refresh_abr_playlist.
The prompts are one-shot templates. Each tells the agent to read the matching recipe resource and submit via start_encode2_raw. There are prompts for encode_hls_abr, encode_dash_abr, encode_mp4_ladder, encode_incremental_rung, encode_refreshing_playlist, encode_av1, tune_per_title, extract_audio, generate_thumbnails, transcribe, add_subtitles, get_video_metadata, stitch_videos, enable_callbacks, enable_reliability, and six DRM variants spanning Widevine, PlayReady, FairPlay, BuyDRM, and ExpressPlay.
This is the notable part. The agent is not just a front-end for the API. It is the orchestrator. The MCP server hands the agent a semantic layer: recipes, best practices, error-code mappings, and gotchas. The agent reasons over that layer to compose a job. That is a fundamentally different relationship between infrastructure and its users than the REST API era produced.
The security bet: OAuth instead of keys
The security model is the second notable decision. The connector uses OAuth 2.1 only. There is no static-API-key mode. On first use, the client opens a browser, the user signs in to the Qencode portal, picks a project, and approves the requested scopes. The client stores the token. Subsequent calls are silent until the token expires.
The scopes are granular. transcoding:read covers get_job_status, wait_for_job, and docs tools. transcoding:write covers transcode_video and start_encode2_raw. The resource server enforces these scopes on access tokens at the transport layer. Qencode API keys never leave the portal; the MCP server derives a short-lived session token per request via an internal portal endpoint.
This matters for a reason beyond security hygiene. Static API keys in agent config files are a liability. An agent with a long-lived key can do anything the key permits, indefinitely. OAuth scopes with refresh tokens and short-lived session tokens bound the blast radius. If an agent is compromised, the damage is limited to the approved scopes and the token lifetime. Qencode is treating agent identity as a first-class security problem, which is more than most API vendors have done.
The threat model is documented in docs/security/THREAT_MODEL.md. Source URLs are validated at the tool boundary as an SSRF defense. Schemes like https://, http://, s3://, and tus: are accepted. FTP/SFTP and private or metadata URLs are rejected. The test suite includes an OWASP MCP Top 10 adversarial suite, run under pytest -m security. There are roughly 540 offline tests across L1, L2, and L5 layers.
Protocol maturity signals
The versioning policy is another signal of maturity. The connector targets MCP protocol version 2025-11-25 as primary. CI also runs conformance tests against 2025-06-18 because JSON-RPC batching behavior differs between earlier revisions. The server does not claim support for 2025-03-26 or older wire semantics beyond what the underlying SDK negotiates.
SemVer is applied to the MCP surface, not the Qencode HTTP API. A MAJOR bump means a breaking surface change: a tool or prompt removed, an argument becoming required, an OAuth scope added in a way that forces re-consent, or a supported protocol version dropped. Surface changes are guarded by snapshot tests under tests/protocol/. When the surface changes, the version must be bumped in four places that must all agree: pyproject.toml, src/qencode_mcp/__init__.py, server.json, and a new CHANGELOG.md entry.
This is the kind of discipline that matters when the consumer is an agent. An agent cannot read a changelog and adapt the way a human engineer can. If a tool signature changes, the agent’s cached understanding of the surface is wrong. Snapshot tests and strict SemVer are the agent-era equivalent of API deprecation policies.
What this means for AI builders
The Qencode MCP server is a template for how infrastructure vendors should ship agent-facing interfaces. The recipe knowledge base is the key move. Instead of forcing agents to discover API behavior through trial and error, Qencode encodes best practices directly into the MCP resource layer. The agent fetches qencode://docs/best-practices and applies composition defaults automatically. That is a documented, versioned, testable way to transfer human expertise to an agent.
The OAuth-only model is the second template. Long-lived API keys are the wrong primitive for agent access. Scoped, short-lived, refreshable tokens are the right one. Vendors who ship agent connectors with static keys are building a liability.
The remaining question is whether the agent actually gets video right. The documentation lists capabilities like smart thumbnail selection, AI detection of AI-generated video, VMAF quality scoring, and speech-to-text with translation into up to 15 languages. Whether an agent reliably composes a start_encode2_raw query that produces a correct Widevine package on the first try is an empirical question. The 540 tests cover the server, not the agent’s judgment. The agent evals live under evals/README.md, and the CI runs nightly L3 and weekly L4 cron jobs. That is more evaluation infrastructure than most MCP servers ship.
The Qencode connector is a bet that agents become the default interface to infrastructure. For AI builders, the lesson is concrete: the agent is the new API client, and the API surface must be designed for it. Recipes, scopes, threat models, and snapshot-tested versioning are the new API docs. Qencode got there first, and the pattern is worth copying.