MCP, skills, SDK, or API: a technical deep dive on how AI agents call localization at Ollang

The problem: four ways to be wrong about integration

Every engineering team building agent-driven products in 2026 hits the same wall: the tools your agents can call matter as much as the models running them. Model Context Protocol gave the industry a standard way for agents to discover and invoke external capabilities, and localization vendors responded predictably, by bolting an MCP wrapper onto whatever REST API already existed and calling it "agent-ready." That approach works, but it discards the reason MCP exists: different invocation contexts need different authentication models, different state assumptions, and different failure modes.

A backend service orchestrating nightly translation batches has nothing in common, architecturally, with a developer typing "translate this subtitle file into French" inside Cursor. Treating both as the same integration problem is how you end up with OAuth flows bolted onto headless cron jobs, or API keys hardcoded into a coding agent's config where they don't belong.

Ollang's argument is that these are different problems requiring different surfaces. The platform ships four: a REST API, a hosted MCP server, file-based Agent Skills, and a TypeScript SDK. Ollang is an AI-native localization platform for video, audio, and document content, and the platform 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. The rest of this piece is about which surface to reach for and why, grounded in what Ollang's API documentation actually specifies.

REST API: the backend contract

The REST API is the substrate everything else is built on. It covers programmatic uploads, orders, projects, revisions, QC, human review, and webhooks, and is API-key authenticated. That's a different scope than "translate this string," it is the full order lifecycle: create a project, submit an order against it, poll or receive a webhook callback on completion, run a QC evaluation, request a human review upgrade, and file a revision if the output misses the mark.

The endpoint surface backs this up directly. The reference documentation lists direct file upload, order creation, VTT upload, human review request and cancellation, QC evaluation, order rerun, subtitle embedding requests, revision creation and retrieval, plus folder and project listing endpoints, alongside health checks, supported languages, order statuses, order types, and order document types as reference data.

This is the surface for teams building custom backend orchestration, a localization microservice inside a larger content pipeline, a CI job that fires translation orders on every content merge, or an internal admin tool that needs full control over the order, QC, and revision loop without routing through an agent runtime at all. Authentication is a static API key rather than a user-consent OAuth flow, which is the right model for service-to-service calls where there's no human in the loop to authorize anything. Details on base URL, request/response shape, pagination, and callback handling live in the API reference, worth reading before you design retry logic, since order processing is asynchronous by nature.

Hosted MCP server: OAuth for agents that act on your behalf

MCP solves a different problem: how does a conversational agent, one a human is actively steering, discover and call a tool without the human hand-typing curl commands. Ollang's hosted Model Context Protocol server is OAuth 2.0 with PKCE authenticated and is supported by multiple agent clients.

The choice of OAuth 2.0 with PKCE over a bearer API key is not incidental. MCP servers built for public-facing use serve multiple clients, acting on behalf of different users, so the server needs to know who is actually asking, not just that a valid key was presented. PKCE closes the specific hole where an intercepted authorization code could be replayed by an attacker to obtain a token; it binds the code to the client that requested it, and it's mandatory in the OAuth 2.1 profile MCP tooling has converged on. In practice, this means a developer connects their coding agent once, goes through a consent flow, and afterward the agent can call Ollang tools with a token scoped to that session, revocable, short-lived, and traceable to an actual user rather than a shared secret sitting in an environment variable.

The operational shift this enables is clear: instead of an engineer writing glue code to call the REST API from inside an agent's tool-calling loop, the agent discovers Ollang's capabilities natively through the MCP handshake and invokes them as part of a conversation. "Localize this video into Japanese and German, then flag it for human review" becomes something an agent can plan and execute directly, with the MCP server translating that into the underlying order and review-gate operations. This is the right surface for conversational, agent-driven workflows where a human is in the loop approving direction but not typing API calls.

File-based Agent Skills: no server, no OAuth, no glue code

Skills solve a third, narrower problem: what if you don't want to run a server or manage an OAuth session at all, and just want your coding agent to understand localization as a set of natural-language operations. Ollang's file-based Agent Skills work across several coding-agent environments, offering natural-language ops with no server to run.

Structurally, Skills are prompt-based packages that provide procedural knowledge, with step-by-step instructions and API details so an agent can accomplish domain-specific tasks without custom prompts written by hand. Under the hood each skill maps to a specific REST endpoint, but the agent never needs to know that; it matches intent to action. The documented sub-skills expose discrete, composable operations: ollang-upload to upload a file and get a projectId, ollang-order-create to create an order and get an orderId, ollang-order-get to poll order status, ollang-qc-eval to run a quality check on a completed order, and ollang-revision to report issues, alongside human review, project, and folder skills for browsing and managing workspace state.

The lack of a server is the point. Skills are file-based, they live in the agent's own config directory, get pulled and updated via a simple CLI command, and authenticate with a locally stored API key rather than a session token. That makes them the right fit for a developer who wants "translate this file" to work inside their coding agent today, without provisioning infrastructure or managing an OAuth consent flow for what's often a single-developer, single-machine workflow. The Skills reference documents the full set and their parameters.

TypeScript/Node SDK: localization wired into the repo

The fourth surface targets a problem the other three don't solve well: continuous internationalization embedded directly in a codebase, not invoked ad hoc. Ollang ships a TypeScript/Node.js SDK for asset scanning, i18n workflows, browser CMS capture, and a typed REST client.

This matters for teams running string-based i18n pipelines, React, Vue, or mobile apps with locale files that drift out of sync as developers add new strings. An SDK that can scan source for untranslated keys, diff against existing locale bundles, and call a typed REST client to fill gaps is a different operational shape than either an agent tool call or a backend order pipeline. It runs as part of the build or CI process, gets version-controlled alongside the code it's translating, and gives engineers compile-time type safety on request and response shapes instead of raw JSON. It's the surface for "localization as a repo dependency" rather than "localization as a service I call."

Choosing among the four

None of these surfaces is strictly better, they answer different questions about where control, identity, and state live.

A reasonable enterprise stack ends up using more than one. A platform team might expose the REST API internally for its own orchestration layer, hand Skills to individual developers for local, ad hoc translation tasks, and grant MCP access to a customer-facing support agent that needs to localize documents on request during a live session, all against the same underlying order and QC model, so quality scoring and review-gate behavior stay consistent regardless of which door was used to walk in.

The actual argument

Most vendors treat "AI-ready" as a checkbox: expose an MCP endpoint, ship a changelog entry, move on. That's a wrapper, not an execution layer. The distinction matters because agent architectures are diverging into conversational agents, headless pipelines, embedded coding assistants, and CI-resident tooling, often within the same organization. A localization vendor that only speaks REST forces every one of those patterns through the same lowest-common-denominator integration, usually hand-rolled by whichever engineer drew the short straw. A vendor that only speaks MCP solves the agent case and ignores the batch-pipeline and repo-embedded cases entirely.

Building four first-class surfaces against one consistent order, QC, and review model is what makes localization behave like infrastructure rather than a service with an API bolted on. The test for any vendor claiming to be an execution layer for AI agents is whether the integration surface actually matches the shape of the system that's calling it, and whether picking one of the four surfaces means giving up governance, quality scoring, or review-gate control that the others get. If the answer is that all four surfaces stay consistent underneath, the vendor has built infrastructure. If not, they've built a wrapper wearing infrastructure's clothes.