MCP for localization: a technical deep dive on letting AI agents call translation like any other tool

An engineering team ships a coding agent that scaffolds features, writes tests, and opens pull requests without a human touching the keyboard. The agent updates the strings file, the JSON locale bundle, the subtitle track for the onboarding video. All of it ships in English because translation was never something the agent could reach. It was a ticket, a vendor portal, a Slack message to someone in localization, a different system, on a different timeline, requiring a human to notice the gap and route the work.

The actual failure mode is that agents default to English from an infrastructure gap. Localization sat outside the boundary of what an agent could discover and call. Model Context Protocol closes that gap, and gives agents a standard way to find a tool, understand its inputs and outputs, and invoke it mid-task, the same way they call a filesystem, a database, or a ticketing system. Ollang's argument is narrow and specific: build the MCP server and Skills layer so that translate, dub, subtitle, and review become tools an agent discovers and calls, not a service a human requests.

Why a REST endpoint doesn't solve this

A REST API is a contract you read once, in documentation, and hard-code against. You write a client, you map fields, you handle the response shape, you ship it. That works for a human developer building a fixed integration. It doesn't work for an agent that needs to decide, at runtime, what tool to reach for and how to call it correctly without a developer having pre-wired that specific call.

MCP formalizes what was previously ad hoc. An MCP server publishes a list of tools with machine-readable schemas, name, description, and a typed parameter spec, and an agent can call list_tools at connection time to see what's available, without a developer writing custom glue code for that specific vendor. The agent's model reads the tool description and schema the same way it reads any other function signature, decides whether the task calls for it, and issues a structured call with typed arguments instead of constructing an ad hoc HTTP request and hoping it is well-formed. Responses come back structured, too, so the agent can act on them programmatically rather than parsing free text or guessing at JSON shape.

The Model Context Protocol is an open standard developed by Anthropic that enables AI models to interact with external tools and data sources through a structured, schema-driven interface. That distinction, schema-driven discovery versus a fixed integration a developer wrote in advance, is what makes an agent capable of reaching for localization on its own, mid-task, instead of requiring a human to have anticipated that exact call.

Where Ollang's MCP server sits in the stack

The platform orchestrates AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows, and exposes these capabilities through APIs, an MCP server, an SDK, and agent Skills. For an agent, the MCP server is the discovery surface: connect to it, enumerate the available actions, translate a document, dub a video, translate and re-time a subtitle file, run a quality check, and call them with structured arguments instead of hand-rolling requests against a REST spec the agent's model has never seen.

Ollang takes a source asset, a video, audio file, document, image, subtitle file, or strings file, and produces multilingual, reviewable localization outputs. That asset-in, reviewable-output-out shape is what makes it callable mid-workflow: an agent working on an i18n bundle or a subtitle track doesn't need to understand Ollang's internal pipeline, only the tool's schema.

Review is part of the workflow. You can add a Level 1 review gate to any order to route output to Ollang-managed linguists or your own LSPs and editors. AI quality checks on accuracy, fluency, and related dimensions run as part of the same callable surface. This matters for a coding agent because it can request translation with a review gate attached in the same call, rather than shipping AI-only output and hoping quality holds.

Authentication follows the pattern engineers expect for a production MCP integration: connect, authenticate, and the server's permission model governs what the agent can access, rather than the agent needing separate hard-coded credentials for every action it calls.

The skills layer: one definition, any agent

MCP solves discovery and schema. It does not solve the fact that not every agentic tool speaks MCP the same way, or that some coding agents work better from local instruction files than a live server connection. That's what Ollang's Skills layer is for.

Agent Skills are reusable capability packages for AI coding agents. They give your agent procedural knowledge, step-by-step instructions and API details, so it can accomplish domain-specific tasks without you writing custom prompts. Architecturally, a skill is a local instruction file, not a live connection. Skills teach your agent how to call the Ollang REST API, so no proxy server or MCP connection is required if you prefer that integration path. Ollang supports both approaches, MCP and local Skills.

The practical payoff is that engineering teams don't write a custom wrapper per agent. A collection of skills for interacting with the Ollang translation platform API via natural language is compatible with any agent that supports the skills standard, including Claude Code, Cursor, Devin, and others. Installation is a single command:

npx skills add https://github.com/ollang/skills --skill ollang

After installation, the skills are available in your agent. Skills are prompt-based extensions for AI agents that trigger automatically based on intent. Once installed, you can say things like "upload this video to Ollang" or "check my recent orders" and your agent will follow the procedure in the skill file.

Ollang says the SKILLS layer is designed to be framework-agnostic. Once connected to an agent like Cursor, Claude Code, Devin, Replit, or Lovable, the agent can use Ollang capabilities on the fly. For a Head of Engineering evaluating this, the operational difference from a traditional vendor integration is: install once, and it works across the coding agents your teams already standardize on. Skills work with agents such as Cursor, Claude Code, Windsurf, Cline, Codex, and other compatible tools. No separate SDK per tool, no bespoke API client for each agent your organization runs.

Context-aware localization for i18n and JSON

Calling a translation tool from inside an agent's workflow only matters if the output is usable without a rewrite pass. i18n strings and JSON locale files are dense with fragments, button labels, error states, tooltips, that break under literal, string-by-string translation. A word that's neutral in a marketing paragraph can read wrong in UI microcopy; a term that's fine in one region's dialect can miss the register entirely in another.

Ollang addresses this by attaching context to the call rather than treating every string as an isolated unit. It uses project context, custom instructions, and terminology memory to help agents localize JSON and i18n content with the right regional tone, idioms, and cultural appropriateness. So instead of translating text in isolation, the system adapts each string based on the product, audience, and market.

That matters for the agentic use case because the agent making the call may not know the brand's terminology conventions or the target market's tone expectations, and it should not need to encode that knowledge into every prompt. Terminology memory and project context live on the Ollang side of the call, attached to the project, so the same skill or MCP tool call produces consistent output whether invoked by a human prompt or an autonomous agent step three moves into a task.

The actual problem: English-first by default

Most engineering orgs run into the same issue: every AI agent, every app, every workflow is English-first by default. The reason is structural, not strategic. Reaching 240+ languages requires stitching together multiple APIs, managing file conversions, handling dubbing, subtitles, and i18n files separately, and keeping quality consistent. That creates significant operational overhead.

MCP and Skills are built to close that gap for the coding-agent context specifically. With native MCP/Skills integration, agents such as Claude Code, Cursor, Cline, and Codex, plus 15+ others, can localize files directly from their workflow rather than exporting to a separate translation step run by a different team on a different schedule. The failure mode is not a bad translation, it is no translation at all, because the capability was never reachable from inside the loop where the work happened.

The argument, stated plainly

Protocol-level access changes how localization works. When translation, dubbing, subtitling, and review are tools with published schemas that any compliant agent can discover and call, localization stops being a project you scope, staff, and wait on. It becomes a function call with a return value, something an agent reaches for the same way it reaches for a linter or a test runner, inline, at the moment the content is created rather than after it ships.

For a Head of Engineering, the decision is not about translation quality in isolation. Many vendors can produce a competent translation. The decision is whether that capability is addressable from inside the systems your teams and agents already run, without a bespoke integration for every tool in your stack. An MCP server plus a framework-agnostic Skills layer is what makes that true in practice: connect once, and every agent that speaks the protocol, or reads a local skill file, can call localization the same way it calls anything else in your workflow.