MCP for localization: How AI agents call translation, dubbing, and QC as tools instead of filing tickets

Your engineering org has already wired coding agents into the repo. Claude Code opens a PR, Cursor refactors a module, Codex writes the test. Then a string file needs to go from English to nine languages, and the workflow reverts to 2019, export a JSON file, email a vendor, wait for a quote, wait longer for delivery, reconcile the returned file against a branch that has since moved. The agent that just wrote your feature can't touch localization because localization was never exposed as something an agent could call.

That gap is the point of this piece. Most localization vendors added an API to an existing translation management system built for human project managers clicking through a dashboard. The API mirrors that dashboard's object model, projects, tasks, assignees, and treats AI agents as a novelty client bolted onto infrastructure designed for a different era. Ollang inverted the build order, designing the MCP server, SDK, and agent SKILLS as integration surfaces alongside the REST API, so a coding agent can discover, call, and chain localization actions with the same mechanics it uses for any other developer tool, rather than requiring a human to translate the agent's request into a ticket.

Four surfaces, one execution layer

Ollang exposes the same underlying capability, orchestrating AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows, through four distinct integration paths, each suited to a different caller.

REST API. Programmatic uploads, orders, projects, revisions, QC, human review, and webhooks, authenticated by API key. This surface is for backend services, CI/CD jobs, and any system that needs deterministic, scriptable control over a localization pipeline.

MCP server. A hosted Model Context Protocol server using OAuth 2.0 with PKCE, built to drop into Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and more. This surface is built for agents reasoning in natural language and deciding, mid-task, that a localization action is the next tool call.

SDK. A TypeScript/Node.js SDK for asset scanning, i18n workflows, CMS capture, and a typed REST client. This gives engineers a typed layer to build custom pipelines without hand-rolling REST calls, useful when you're wiring Ollang into an existing CI system rather than an agent runtime.

SKILLS. File-based Agent Skills for Cursor, Claude Code, Codex, Windsurf, and Cline that support natural-language operations with no server to run. Skills are the lightest-weight path, prompt-based extensions that trigger automatically based on intent. Once installed you can tell an agent to upload a video or check recent orders and it knows what to do.

Different callers need different contracts. A CI pipeline wants a stable, versioned REST endpoint. An autonomous coding agent wants a discoverable tool schema it can reason about at runtime. A developer prototyping inside Cursor wants a skill they can install with one command and never touch again. Vendors that expose only a REST API force every one of these callers through the same narrow door.

Inside the repo: what agents actually do

The practical test of agent-native infrastructure is whether an agent can complete a localization task without a human translating the request into vendor-specific steps. With Ollang's SKILLS layer installed via a single command that copies skill folders into the agent's skills directory, such as the Claude Code skills path, a coding agent working inside a repo can recognize a localization need directly from context: a new i18n key was added, a marketing doc changed, a video asset landed in the content folder.

Ollang designed the SKILLS layer to be framework-agnostic, so once connected to an agent like Cursor, Claude Code, Devin, Replit, or Lovable, the agent can use Ollang capabilities on the fly, understanding the tech stack and workflow context to trigger the right multimodal localization action. The agent does not stop to ask a human which vendor handles video versus documents versus i18n strings. One connected capability set handles all of it, because Ollang says otherwise you must stitch together multiple APIs, manage file conversions, and handle dubbing, subtitles, and i18n files separately while trying to keep quality consistent, which increases integration work.

For a head of engineering, the relevant question is whether the agent can execute a full loop, detect a change, call the right modality-specific action, and return a result the CI pipeline can gate on. That loop separates a chatbot plugin from an execution layer.

Context over isolated strings

An agent that translates each string independently can produce output that is technically correct but contextually wrong, with inconsistent terminology, the wrong register for the market, or idioms that do not survive translation. Ollang addresses this by giving agents access to project-level context rather than treating each call as stateless. The platform uses project context, custom instructions, and terminology memory to help agents localize JSON and i18n content with the right regional tone, idioms, and cultural nuance, adapting each string based on the product, audience, and market instead of translating text in isolation.

This matters because coding agents operate on diffs and file changes, one commit at a time, with no inherent memory of a brand's voice in German versus Japanese. If the localization tool called by the agent does not carry that memory forward, every commit resets to zero context, and terminology drifts across the file within weeks. Persistent terminology memory and custom instructions attached to the project, not the individual API call, let an agent's output stay consistent across hundreds of small, incremental commits rather than one large batch translation.

Transport mechanics: why stdio vs. streamable HTTP matters here

This is the part most vendor pages skip, and it determines whether your MCP integration survives contact with production traffic.

MCP defines two current standard transports. Stdio is a model where the client launches the server as a child process and talks newline-delimited JSON-RPC over stdin/stdout, local, single client, no network. It's the right choice for an individual developer running an agent on their own machine, but it does not scale to a shared, authenticated, multi-user deployment, because there is no session to load-balance, no way to gate access by role, and no server process independent of the client that launched it.

Streamable HTTP, introduced in the MCP spec's March 2025 revision and carried forward since, replaces the older two-endpoint SSE transport with a single HTTP endpoint that accepts both POST for client messages and GET for server-initiated streams, responding with plain JSON for short calls and upgrading to SSE for streaming ones. This design makes a shared, production MCP deployment viable, because it supports stateless servers, resumable streams, authentication, and multi-tenancy, making it the right choice for production or enterprise deployment.

Ollang's MCP server runs as a hosted service authenticated with OAuth 2.0 and PKCE rather than a local subprocess, the appropriate architectural choice for an engineering org where multiple agents, multiple developers, and multiple environments, staging, CI, production, all need to call the same localization backend under distinct, revocable credentials. A stdio-only MCP integration would mean every developer's machine runs its own instance with its own auth state, which does not survive a security review. Ask vendors whether their MCP server is stdio-only, whether it supports OAuth-scoped sessions over HTTP, and whether it can sit behind a load balancer without breaking session state, since stateful sessions still complicate horizontal scaling.

Read access vs. full workflow execution

Not every MCP server that touches localization does the same job. Several established TMS vendors have shipped MCP servers that let an agent manage the project around translation, listing projects, creating keys, assigning tasks, checking coverage, pulling files that a human or a separate machine translation step already produced. That's a real capability, but it is fundamentally read-and-administer access to a translation memory and task queue, not execution of the translation, dubbing, or QC work itself.

The distinction matters for a head of engineering deciding what to build against. An MCP server that only manages tasks still requires a downstream vendor or a separate MT pipeline to actually produce translated content, the agent is automating project administration, not localization. Ollang's MCP and SKILLS surfaces are built to trigger the execution itself, the agent does not create a task and wait, it invokes the dubbing, subtitle translation, document translation, or QC action and gets a result back, orchestrated by the same platform that runs AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows. That's the difference between an agent that files a smarter ticket and an agent that finishes the job.

The closing argument

The architecture question underneath all of this is whether localization is treated as a service you request or infrastructure you call. Every design choice in a bolted-on API, task objects instead of callable actions, dashboards instead of tool schemas, stdio-only local servers instead of authenticated production endpoints, reflects an assumption that a human is still the one initiating and monitoring the work. Coding agents do not fit that assumption. They discover tools, chain calls, and act on context without waiting for a project manager to route the request.

Building MCP, SDK, and SKILLS access as first-class parts of the system rather than an afterthought lets localization sit inside the same execution loop as the rest of an engineering org's agentic tooling, called the moment a string changes, gated in CI the same way a test suite is gated, carrying market-specific context forward the same way a linter carries a style guide forward. This piece argues for treating localization as infrastructure an agent calls directly, on the same terms it calls everything else in your stack.