Inside the machine: how Ollang's API, MCP server, SDK, and Skills layer actually fit together

An engineering team evaluating localization infrastructure usually asks the wrong first question. They ask "does it have an API?" instead of "which of my systems need programmatic access, and what does each one actually need to call?" A CI/CD pipeline shipping nightly builds needs something different from a coding agent triaging untranslated strings in a pull request, which needs something different again from a support engineer asking Claude to check on an order status. Most localization vendors answer all three with the same webhook-and-token API and call it done. That's a lowest common denominator.

Ollang's position is that enterprises don't need one integration path into localization, they need the right one for each calling system. The platform ships four distinct surfaces, REST API, MCP server, SDK, and Skills, and the engineering discipline here is not any single surface, it is keeping them separate and ensuring they all resolve to the same execution engine underneath. Ollang is a localization platform for video, audio, and document content, and it orchestrates AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows in one place, exposed through APIs, an MCP server, an SDK, and agent Skills. This piece is a system diagram for the engineers who have to decide which door to walk through.

The shared core underneath all four doors

Before picking a surface, it helps to understand what sits beneath all of them, because none of the four are independent products bolted onto a marketing site. The Folder → Project → Order hierarchy is the operational model every request eventually resolves to, regardless of whether it arrived via a curl command, an agent's tool call, an SDK scan, or a natural-language Skill invocation. A Folder groups related work, a Project holds source assets and configuration, and an Order is the unit of execution, the thing that actually gets translated, reviewed, and delivered.

That shared model is what makes multi-surface access safe instead of chaotic. Ollang uses project context, custom instructions, and terminology memory to help agents localize JSON/i18n content with the right regional tone, idioms, and cultural nuance, and that memory does not reset depending on entry point. A term pinned via the dashboard is respected when an MCP-connected agent runs the same project a week later. A glossary built through the API persists when a Skill-driven coding agent touches the same repo. Governance, quality gates, and terminology consistency are properties of the Project and Order objects, not properties of whichever client happened to call them.

REST API: the pipeline builder's surface

For teams building end-to-end custom localization pipelines, source system on one end, delivery target on the other, orchestration logic in between, the REST API is the correct layer. It is API-key authenticated, covering programmatic uploads, orders, projects, revisions, QC, human review, and webhooks.

This is the surface you reach for when localization needs to be a first-class step in a system you already own: a CMS publish hook that creates an Order on every content change, a release pipeline that gates deployment on translation QC status, or an internal admin tool that lets a localization ops team requeue a batch of documents without touching the Ollang dashboard. The API gives you the primitives, folders, projects, orders, revisions, and lets your own orchestration code decide the sequencing, retry logic, and business rules.

The tradeoff is honest, you own the glue. Polling for order completion, handling webhook retries, mapping your internal content model to Ollang's asset types, that's your integration code to write and maintain. What you get in exchange is full control over how localization sits inside a pipeline you already trust, which matters when the pipeline has its own compliance, audit, or sequencing requirements that no vendor-provided abstraction should override.

MCP server: where autonomous agents run workflows directly

The REST API assumes a human engineer wrote the calling code ahead of time. The MCP server assumes the opposite, an autonomous agent needs to discover what's possible and decide, at runtime, which workflow to run. This is the surface built for the agent pattern, not the scripted one.

Ollang runs a hosted Model Context Protocol server, authenticated with OAuth 2.0 + PKCE, that drops into Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and more. The practical difference from the REST API is discovery. An MCP client does not need pre-written integration code for every action, it connects, enumerates the tools the server exposes, and an LLM decides which tool to call and with what arguments based on the task in front of it. A support engineer can ask an agent to "check the status of the German dubbing order for the onboarding video" without anyone having built a status-check UI for that specific phrasing. The agent discovers the order-lookup tool and calls it.

This matters operationally because it removes an entire category of custom glue code, the code you would otherwise write specifically to let an LLM-based tool call your API safely. OAuth 2.0 with PKCE handles the authorization handshake so credentials are not passed around as static bearer tokens in agent config files. The MCP server is the right choice when the caller is not a fixed pipeline but a reasoning system that needs to decide, mid-task, whether to translate, check QC, or route to human review.

SDK: inline, in-repo translation at the source

Neither the API nor MCP is the right tool for a very specific, very common engineering job: scanning a codebase or content repo, finding what needs translation, and applying results back into the files without breaking structure. That is what the SDK is for.

Ollang ships a TypeScript/Node.js SDK for asset scanning, i18n workflows, CMS capture, and a typed REST client. The distinction from the raw API is important, the SDK is not just a typed wrapper around HTTP calls, though it includes one, it understands the shape of source repositories and content stores well enough to scan them, identify translatable strings inside i18n files, and write translated values back into the correct keys without corrupting the surrounding JSON structure. This is the layer for a build step that runs ollang scan against a locales/en.json file, sends the diff for translation, and writes the results back into locales/de.json, locales/ja.json, and so on, as a scripted, repeatable, version-controlled operation rather than a manual export/import cycle through a TMS.

CMS capture extends the same pattern to content systems that do not live in a git repo: scanning rendered or structured content from a CMS, identifying what's new or changed, and pushing translated content back through the same typed client. The SDK is the right layer whenever the unit of work is "find strings in this codebase or content store and translate them in place," not "orchestrate a multi-step business process" (API) or "let an agent decide what to do" (MCP).

Skills: reusable agent actions with no server to run

Skills solve a different problem than any of the above, giving a coding agent procedural knowledge about how to use Ollang without requiring a running server connection or custom prompt engineering every time.

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. Skills work with agents like Cursor, Claude Code, Windsurf, Cline, Codex, and other compatible tools. They are file-based rather than server-based, dropped into an agent's skills directory and loaded at session start, no persistent connection required. Skills are prompt-based extensions for AI agents that trigger automatically based on your intent, once installed you can say things like "upload this video to Ollang" or "check my recent orders" and your agent will know what to do.

The practical workflow is granular by design. ollang-upload uploads a file and returns a projectId. ollang-order-create creates an order with that projectId and returns an orderId. ollang-order-get polls order status. ollang-qc-eval runs a quality check on a completed order. ollang-revision reports any issues. Each sub-skill is a discrete, composable action rather than one monolithic "do localization" prompt, which is what makes Skills framework-agnostic. The same skill package behaves consistently whether the host agent is Cursor editing a frontend repo or Claude Code refactoring a backend service. The difference from MCP is architectural, not just cosmetic. MCP is a live protocol connection an agent queries at runtime, Skills are static, versioned instruction sets an agent reads once and reuses across sessions, which is why they are the right fit for developer environments where you want localization behavior checked into version control alongside the rest of the agent's configuration, not dependent on an always-on server connection.

Choosing the layer, not the vendor

The decision is not which surface is best, it is matching the caller to the surface built for that calling pattern.

If you are building a custom pipeline with your own orchestration, retries, and business logic from source system to delivery, choose the REST API. If you want an autonomous agent to decide at runtime which localization action a task requires, without pre-written integration code, choose the MCP server. If the unit of work is scanning a repo or CMS and applying translations inline as a scripted, repeatable, version-controlled step, choose the SDK. If you want to give a coding agent reusable, portable know-how that works the same across Cursor, Claude Code, Cline, and Codex without a live server dependency, choose Skills.

The argument this makes about localization infrastructure

The reason this separation matters is what it implies about where localization sits in the stack. A vendor with a single API surface is implicitly saying localization is one kind of system-to-system call, the same shape whether the caller is a cron job, a human, or a reasoning agent. That's a description of a translation service with a webhook, not an execution layer.

Treating REST, MCP, SDK, and Skills as four distinct, purpose-built surfaces over one engine is a claim about maturity, that localization has enough different calling patterns, scheduled pipelines, autonomous agents, in-repo tooling, portable agent skills, to deserve interfaces shaped around each one, while still guaranteeing that a term translated through one surface is respected by every other. The actual infrastructure argument is not that Ollang can be called programmatically, but that it can be called correctly by whichever system in your stack needs to call it.