MCP for localization: a technical deep dive on letting AI agents call translation and dubbing as native tools

An engineer using Claude Code or Cursor can now open a pull request, fix a flaky test, and deploy a service without touching a terminal outside the agent session. Ask the same agent to get that new feature's UI copy translated into eight languages, or dub a product demo video into Spanish and Japanese, and the workflow breaks. The agent has to stop, a human has to open a vendor portal or file a ticket, and the work re-enters the world of email threads and delivery dates. Every unlocalized string, every English-only demo video, is the default output of that broken handoff, not a strategic choice, just friction nobody removed.

Model Context Protocol is becoming the standard way coding agents reach systems outside their own context window, and localization is one of the cleanest cases for it. The failure mode is universal: software ships English-first by default because turning content into other languages has always required leaving the build pipeline. This piece is not a pitch for why that matters. It is a walkthrough of how Ollang's MCP server and Skills layer actually work, down to the sub-skill and endpoint level, for the engineer who has to decide how to wire it in.

Two integration shapes, not one

Ollang exposes localization through https://api-docs.ollang.com/home: a REST API, a hosted MCP server, a TypeScript/Node SDK, and file-based Agent Skills. The two that matter for agent-native workflows, MCP and Skills, are architecturally distinct, and conflating them is the fastest way to over-engineer an integration.

Ollang's MCP is a hosted Model Context Protocol server secured with OAuth 2.0 and PKCE, built to drop into Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and similar agent environments. It's a real server, your agent authenticates against it, holds a session, and calls tools over that session rather than making raw HTTP requests.

Skills work differently. Skills are local instruction files that teach an agent how to call the Ollang REST API directly, with no proxy server or MCP connection required. Skills are file-based and agent-local, while MCP is a hosted protocol server. There's no persistent connection to reason about, no token exchange to debug. The agent reads a markdown instruction set, figures out which API call it needs, and issues it with an API key.

The practical difference is that MCP centralizes auth and session state on Ollang's server and governs access per connection, while Skills push execution to the agent's own environment and govern access per API key. Neither is better in the abstract, they solve different deployment problems, which is why Ollang ships both instead of forcing one.

The master-skill routing pattern

The part worth understanding line by line is how a natural-language request becomes an API call. The Ollang master skill routes to the right sub-skill based on what you ask your agent, and each sub-skill maps to when the agent should use it and the specific API surface it covers. There are https://api-docs.ollang.com/skills/sub-skills in total, each a thin, single-purpose wrapper around one part of the API.

A few concrete examples from the reference:

• Health check, pings the Ollang API to verify it's online, and requires no API key, hitting GET /health. This is the sub-skill an agent uses to sanity-check connectivity before attempting real work.
• Upload, uploads a source file to Ollang, supporting video, audio, documents, spreadsheets, and VTT subtitle files, and returns a projectId used to create orders, with a dedicated endpoint for VTT intake specifically (POST /integration/upload/vtt) alongside direct file upload.
• Order creation, creates one or more translation orders for a project, supporting order types including closed captions, subtitles, document, and dubbing.
• Order management, revisions, QC, and human review, the broader skill set covers managing orders (status, cancel, rerun, filtered lists), running AI-powered QC evaluations for accuracy, fluency, tone, and cultural fit, handling revision requests, and escalating orders for professional linguist review.

The full published set also includes health, upload, custom instructions (CRUD for translation rules), order creation, single-order lookup, and paginated order listing with filters, each tied to a plain-English trigger phrase an agent matches against. That routing layer is effectively a lightweight intent classifier sitting in front of the REST API, the master skill does not do the translation work itself, it resolves "translate this to Spanish" into a call against POST /integration/orders with the right parameters already inferred.

A concrete run: video in, dubbing order out, no context switch

Here's what that looks like end to end for an engineer working inside Claude Code, Cursor, Devin, or Replit. The agent is given a video file and told to get it dubbed into two target languages.

1. The master skill matches the request to the upload sub-skill. A prompt like "upload the file at https://example.com/promo.mp4 to Ollang" is enough, the agent doesn't need to know the underlying route, only that this sub-skill exists for that job. Because uploads can reference a source URL rather than requiring the agent to stream a binary payload itself, large video assets don't have to pass through the agent's own request pipeline.
2. Upload returns a projectId.
3. The master skill matches "dub this into Spanish and Portuguese" to the order-create sub-skill, which builds a dubbing order against that project. Ollang's dubbing pipeline produces multilingual dubbed audio and mixed video with optional lip sync or audio description, and also supports TTS-first flows that accept a script with no source video at all, relevant if the agent is working from a script rather than a finished cut.
4. The agent uses order-get or orders-list to poll status without ever leaving its own session.

The engineer never opens a vendor dashboard. The dubbing order is a tool call, not a ticket.

Authentication and the things that break in production

The demo path is straightforward. Production is where the details matter, and Ollang documents them rather than leaving them implicit.

Auth boundary. REST and Skills access is API-key authenticated for programmatic uploads, orders, projects, revisions, QC, human review, and webhooks, with the key set as an environment variable the agent's shell can read. Every skill except the health check requires an API key sourced from lab.ollang.com, set via the OLLANG_API_KEY environment variable. MCP inverts that model, instead of a long-lived key sitting in an env file across every developer's machine, the OAuth 2.0 plus PKCE flow issues a session-scoped credential per connection, which matters if you're deploying one shared MCP endpoint across a team rather than distributing secrets.

Callbacks and retries. Localization jobs, especially dubbing and human review, are asynchronous by nature. Ollang's production guidance documentation covers API keys, callback handling, retries, pagination, and error handling, alongside a single reference page for base URL, authentication, request/response format, and callbacks. Any integration that fires an order and walks away needs to handle the callback contract correctly rather than polling blindly. Read the guidance before wiring a webhook receiver into a CI pipeline.

File-size and intake limits. Direct file upload has documented ceilings, which is why the upload sub-skill's example prompt references a URL rather than a raw multipart payload. For large video and audio assets, pointing Ollang at a source location sidesteps the constraints of streaming a large binary through an agent's own request path. Check the current limits in the docs before assuming a given asset will clear a direct upload.

Choosing MCP, Skills, or the raw SDK

None of these three replace each other, and the choice comes down to where you want state and auth to live:

• Use MCP when you're standardizing access across a team or across multiple agent tools at once, Claude Code, Cursor, Devin, and Replit connecting to one governed, OAuth-protected server rather than each developer holding their own API key. The hosted server is also the right fit if you want a single point to audit and revoke access.
• Use Skills when you want zero additional infrastructure, a solo developer, a CI runner, or a scripted agent environment where an API key environment variable is an acceptable trust boundary and you'd rather not stand up or depend on a server connection at all.
• Use the raw SDK or REST API directly when the workflow is deterministic rather than agent-driven, for example, a nightly i18n pipeline that scans source files and files translation orders on a fixed schedule. The TypeScript/Node SDK is built for exactly that: asset scanning, i18n workflows, CMS capture, and a typed REST client, code you write once and run the same way every time, not a natural-language surface for an agent to interpret.

Ollang's own documentation frames this as a genuine either/or/or decision rather than a funnel toward one preferred path, the docs cover REST API, MCP, SDK, and Skills as four ways to integrate, with guidance on when to use each and how they fit together.

The argument underneath the architecture

What's actually shifting here is not the existence of an API, vendors have had APIs for years. Localization is being exposed at the same layer agents already operate in, as a callable tool with a discoverable contract, not a service queue behind a login screen. The master-skill routing pattern matters because it removes the burden of memorizing endpoints from both the human and the agent, intent gets matched to the right sub-skill, and the sub-skill knows the API surface. The OAuth-secured MCP server matters because it lets that access be governed the same way any other production system is governed, instead of being one more shared secret in a .env file.

The real distinction between infrastructure and a vendor relationship is that a vendor is something you go to, while infrastructure is something your systems already reach because it was built to be called, polled, and governed the same way as other systems in the stack. For a Head of Engineering deciding how localization fits into an agent-driven build process, that is the question that matters.