MCP, skills, SDK, API: a technical map of how AI agents call localization as a service

Every localization vendor now claims MCP support. That claim tells you almost nothing. An MCP server that exposes three read-only tools and a vendor's REST API wrapped in an SDK are both technically "MCP support," and they solve completely different engineering problems. When evaluating a localization execution layer for how your CI pipelines, coding agents, and internal tooling will actually call it, ask which of the available integration surfaces maps to which part of your workflow.

Ollang exposes four distinct surfaces for this reason: a REST API, a hosted MCP server, a TypeScript/Node.js SDK, and file-based Agent Skills. The platform orchestrates AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows in one place, and exposes everything through APIs, an MCP server, an SDK, and agent Skills. These are four different approaches, each making different tradeoffs between explicit control and agent autonomy, and picking the wrong one means either over-engineering a pipeline that should have taken an afternoon or under-engineering a workflow that needed real orchestration.

The four surfaces, mechanically

Before the use-case breakdown, be precise about what each surface actually is, because naming conventions in this space get sloppy fast.

Programmatic uploads, orders, projects, revisions, QC, human review, and webhooks are API-key authenticated. The hosted Model Context Protocol server uses OAuth 2.0 + PKCE and integrates with Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and more. The TypeScript/Node.js SDK handles asset scanning, i18n workflows, CMS capture, and provides a typed REST client. File-based Agent Skills for Cursor, Claude Code, Codex, Windsurf, and Cline provide natural-language ops with no server to run.

That last distinction, no server to run, is the one most engineering teams get wrong when they hear "MCP" and assume it's the only agent-native option. Skills and MCP solve overlapping problems through opposite mechanisms, and the difference matters for anyone deciding what to stand up.

REST API: explicit, repeatable, auditable

The REST API is the surface for anyone who needs deterministic behavior in a pipeline they do not want an agent to improvise inside. This suits CI/CD jobs, scheduled batch runs, and webhook-driven automation, because these workflows require the same call to produce the same result every time, with a clear audit trail of what was submitted and what came back.

The operational model underneath the API is a Folder → Project → Order hierarchy, which gives engineering teams a structure to hang automation on: a folder per product line, a project per release, an order per language batch. The reference layer covers base URL, authentication, request and response format, pagination, errors, and callbacks in one reference page, and production guidance covers API keys, callbacks, retries, pagination, error handling, folder structure, and memory, the infrastructure that keeps a batch job running when callbacks time out.

Concretely, a nightly build that extracts new strings, submits them as an order, and waits on a webhook callback to merge translated output back into a release branch is a REST API job. So is a quarterly document localization run across twenty PDFs that needs to hit a QC threshold before it's marked done. AI-only vs AI plus human review, editor interface, assignments, and QC annotations are all controllable through the same API surface, which means the difference between a fully automated batch and one that routes through human review is a parameter, not a different integration.

The API is the place to go when you want to own the orchestration logic yourself and treat localization as one deterministic step in a pipeline you already control.

MCP: outcome-based requests without a custom integration

MCP exists for teams that do not want to write orchestration logic. They want an agent to inspect project state and decide what needs to happen. The hosted Model Context Protocol server uses OAuth 2.0 + PKCE authentication and integrates with Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and more, meaning the agent authenticates as itself, with scoped, revocable access, rather than carrying a static API key with blanket permissions.

That authentication model matters. OAuth 2.1 with PKCE became the MCP authorization standard because agents are long-running, often unattended processes making calls without a human clicking "authorize" each time, and static API keys cannot distinguish which agent, on whose behalf, is asking for what. A hosted MCP server with proper OAuth scoping means you can grant a coding agent access to translate a specific project's strings without handing it standing access to every order in your account.

A practical use case is an agent working inside a repository that notices a new set of untranslated locale files, checks what languages the project already supports, and creates the missing translation orders without a human writing a script first and without the agent needing to know the API's exact request shape. The agent inspects project state through MCP's tool-calling interface and completes supported actions directly. This is the surface for teams who want agents making judgment calls about what to localize, while the mechanics of how remain inside Ollang's execution layer.

SDK: scanning the codebase and applying translations in place

The SDK solves a narrower, more code-specific problem: getting translations into and out of a codebase without breaking the structures those translations live in. The TypeScript/Node.js SDK handles asset scanning, i18n workflows, CMS capture, and provides a typed REST client.

Localization files are rarely flat text. A JSON i18n bundle has nested keys, interpolation placeholders, and pluralization rules that a naive string replace will mangle. Ollang's supported source formats include DOCX, PDF, PPTX, XLSX, HTML, JSON, DITA, mobile strings (.xml, .strings, .stringsdict), AE projects, and JPEG/PNG image-to-image, and the SDK is built to scan those structures, identify translatable strings without disturbing keys or placeholders, and write translated values back into the same shape.

For a Head of Engineering, the SDK is the right choice when the workflow is to scan the repo, find every locale file across every module, submit the translatable content, and apply results directly back into .strings, .stringsdict, or nested JSON without a human diffing every file afterward to check nothing broke. It's also the surface for CMS capture, pulling structured content out of a headless CMS, translating it, and writing it back in the same shape it came from. This is code-adjacent work, and the SDK is typed accordingly rather than treating every payload as an opaque string.

Skills: reusable agent actions, no server, no per-tool wrapper

Skills are the surface many teams underestimate because they look like documentation rather than infrastructure. 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. They work with agents like Cursor, Claude Code, Windsurf, Cline, Codex, and other compatible tools.

The engineering reason this matters is that Skills follow the open SKILL.md specification, which means a skill written once runs unmodified across every agent that supports the format, instead of requiring a bespoke integration wrapper per tool. A skill built for one coding agent runs the same way in the others without modification. For a platform team supporting a mixed environment, some engineers on Claude Code, some on Cursor, some scripting through Codex, that is the difference between maintaining one localization skill file and maintaining N custom integrations that drift out of sync every time an agent updates its plugin format.

Skills are appropriate when the ask is simple and repeatable in natural language, for example "translate this document," "create a subtitle order for this video," or "check the QC status of this project." Creating translation orders, subtitles, closed captions, AI dubbing, studio dubbing, and document translation, is exactly the kind of action Skills expose, because it maps cleanly to a single REST call that an instruction file can describe without ambiguity. Skills do not require standing up or maintaining a server, which makes them the lowest-friction entry point for small teams or for adding localization to an agent workflow without provisioning new infrastructure.

Choosing the right surface

Choose based on workflow shape rather than vendor marketing: does the task need to run unattended on a schedule (API), does it need an agent to reason about project state before acting (MCP), does it need to touch code structure directly (SDK), or does it need to work identically across a fleet of different coding tools without separate integrations (Skills)? Most mature engineering orgs use more than one surface, for example API for the nightly batch, Skills for ad hoc agent requests during development, SDK for i18n refactors, and MCP for an agent that manages localization as part of a broader autonomous workflow.

The actual argument

The category shift under all four surfaces is that localization stops being something a project manager schedules and becomes something a system, human-built or agent-built, calls when it needs it. That only works operationally if the calling code or the calling agent has a surface that matches what it is trying to do. A vendor that offers only a REST API forces every agent-driven workflow through a custom wrapper someone has to build and maintain. A vendor that offers only an MCP server forces every deterministic batch job through conversational tool-calling it was not designed for.

The engineering discipline here is not picking the most modern-sounding surface. The right diagnostic question is whether the surfaces on offer actually cover your workflow shapes without forcing you to bend one interface to do a job it was not built for.