MCP, skills, SDK, or API: a technical deep dive on agent-native localization access

Your coding agent can already open a pull request, refactor a service, and deploy to staging without a human clicking through a dashboard. Ask it to localize a string table, a subtitle file, or a support doc into twelve languages, and most localization platforms hand the result back to a human anyway, log into a web app, upload a file, wait for an email, download a zip. The integration problem engineering leaders are solving right now is whether the systems that run our pipelines can call localization the same way they call any other service.

Most vendors that market themselves as "AI-enabled" still run their AI inside a dashboard. The execution layer built for the agentic era is narrower and more useful: those capabilities are exposed as tools an AI agent can call mid-workflow, authenticated the way agent tooling expects, without a proxy layer or a human in the loop for routine work. This piece describes the mechanics of that access, MCP, agent skills, SDK, and raw REST, so you can pick the right surface for your agent stack.

Four surfaces, one execution layer

Ollang's API documentation frames the integration question directly rather than burying it under marketing copy. The documentation covers APIs, an MCP server, an SDK, and skills for AI-native localization, a platform that 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.

Those are four distinct integration surfaces, and they address different problems. The REST API is for direct HTTP calls to integrate into pipelines and backend services. The SDK is a TypeScript/Node.js library for asset scanning, i18n workflows, CMS capture, and a typed REST client for teams building custom tooling on top of the platform. Agent skills are local, file-based instruction packages that teach a coding agent how to call the API itself. The hosted MCP server is a protocol-level endpoint that agents connect to directly, with no local files required.

The right choice depends on where the agent runs and how much control you want over the connection. The rest of this piece describes each one. The two worth understanding in depth, because they change how localization is triggered, are MCP and skills.

The hosted MCP server: a protocol endpoint, not a dashboard login

Ollang runs a hosted Model Context Protocol server secured with OAuth 2.0 and PKCE, built to drop into Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and more. This differs from a REST API with a bearer token. MCP is a standardized protocol that lets an agent discover what tools a server exposes and call them mid-conversation, without the agent's developer hand-writing API wrappers for every capability.

The choice of OAuth plus PKCE over a simple API key reflects a structural fact about how agentic clients differ from traditional web clients. MCP servers serve multiple clients such as Claude Desktop, Cursor, custom agents, and automation scripts. Those clients act on behalf of different users, and the server needs to know who is asking for what. A shared API key cannot make that distinction; a properly scoped OAuth token can.

PKCE, or Proof Key for Code Exchange, is a security extension that prevents authorization code interception attacks, and in OAuth 2.1 it is mandatory for every authorization code flow. For a head of engineering evaluating this, the practical upshot is that connecting an agent to Ollang's MCP server follows the same authorization discipline your team already expects from any OAuth-secured internal service. It identifies which user authorized the connection, it scopes what the connection can access, and it provides a standard mechanism for token refresh so long-running agent sessions do not need to re-authenticate.

Practically, once your team connects an agent to the hosted server, that agent can call localization tools natively from inside Claude Code, Cursor, or Devin, with no separate dashboard session and no manual export/import cycle. Setup and endpoint details are covered in Ollang's API documentation.

Agent skills: lighter-weight, no server required

MCP is not the only way in, and it is not always the right one. If your agent stack does not need a persistent hosted connection, or your team would rather avoid running OAuth flows for every environment, Ollang's agent skills offer a local alternative. Skills are local instruction files that teach your agent how to call the Ollang REST API directly, with no proxy server or MCP connection required. Skills and MCP support different architectures: skills are file-based and agent-local, while MCP is a hosted protocol server.

A skill is a package of procedural instructions that sits in your agent's local skills directory rather than on a remote server you have to authenticate against. Agent skills are reusable capability packages for AI coding agents; they give the agent procedural knowledge, step-by-step instructions, and API details, so it can accomplish domain-specific tasks without custom prompts. Skills work with agents like Cursor, Claude Code, Windsurf, Cline, Codex, and other compatible tools.

A developer working in Claude Code can say "upload this video to Ollang and create a French subtitle order," and the agent already knows which endpoint to hit, what payload shape to send, and what to do with the response, because the skill file, not a live server connection, carries that knowledge. This is the lighter-weight path, with fewer moving parts and no token lifecycle to manage, at the cost of the agent needing local file access rather than a network-addressable tool server. Full setup steps and the skill catalog are at Ollang's Skills documentation.

Inside the 12 sub-skills

The skills library is not a single monolithic instruction file. It is twelve documented sub-skills, each covering a specific slice of the API, with a master skill that routes to the right one based on what you ask your agent. Walking through several of them shows how granular the coverage is.

Health check pings the Ollang API to verify it's online, with no API key required, useful as a pre-flight check before an agent kicks off a batch job.

Upload uploads a source file to Ollang, supporting video, audio, documents, spreadsheets, and VTT subtitle files, and returns a projectId used to create orders.

Order creation creates one or more translation orders for a project, supporting order types including closed captions, subtitles, document translation, AI dubbing, and studio dubbing.

Order rerun regenerates a completed order's translation using the latest AI models, letting an agent retry output without a human re-submitting the job.

Revisions creates, lists, or deletes revision requests on a completed order, used to flag subtitle timing issues, mistranslations, or other problems.

Human review upgrades AI-generated output with expert review, giving an agent a documented escalation path rather than a dead end.

QC evaluation runs an AI-powered quality control evaluation that returns scores for accuracy, fluency, tone, and cultural fit, plus segment-level analysis.

Projects and folders lists and searches Ollang folders and projects for organizing work, so an agent can navigate a workspace the same way a human would in the dashboard.

Each sub-skill maps to a specific documented endpoint rather than a natural-language wrapper. The full endpoint-by-endpoint breakdown is in the sub-skills reference. That specificity matters for a technical evaluator: the agent follows a maintained instruction set tied to a real reference.

Why framework-agnostic matters more than it sounds

The skills layer is not built for one agent framework and later ported to others. By design, once a skill is connected to an agent, that agent uses its own reasoning about the surrounding codebase, task, and context to decide when and how to invoke it. The Ollang team has described the goal as a skills layer that is framework-agnostic. In practice, the same instruction set works whether the calling agent is Claude Code reasoning over a git diff, Cursor mid-refactor, or Devin executing a multi-step task plan. The agent supplies the workflow context, and the skill supplies the domain knowledge of how to turn that context into a correctly formed localization call.

The status quo this replaces

None of this matters if the alternative is manageable. It usually is not. Getting to 240+ languages requires stitching together five or more separate APIs, managing file conversions, handling dubbing, subtitles, and i18n files separately, all while keeping quality consistent. Each seam is a place where an agent-driven pipeline breaks down into a manual handoff: someone has to notice the job finished on vendor A, reformat the output for vendor B, and re-trigger vendor C.

Consolidating that surface under one authenticated connection point, whether MCP or skills, saves integration time and changes what can be automated. A pipeline that pauses for a human to move a file between three vendor dashboards cannot be a background step in a CI job. A pipeline where the same agent that wrote the code can also trigger and check on the localization order can be.

Choosing the right surface

For a team already standardized on MCP-compatible agents across the org, Claude Code, Cursor, Devin, the hosted server is the lower-maintenance choice: connect once with OAuth, and every compatible agent inherits access without redistributing credentials or instruction files. For teams running lighter or more heterogeneous agent setups, or that want localization logic versioned alongside the rest of their skill library, skills avoid standing up a server connection entirely. For custom backend services or CI pipelines that are not conversational agents, the SDK or raw REST API remain the direct route, both documented at https://api-docs.ollang.com/home.

The actual argument

The distinction between MCP, skills, SDK, and API is not a feature comparison, it is a statement about what layer of your stack localization is allowed to live in. A platform that only offers a dashboard assumes a human is always the trigger. A platform that exposes OAuth-secured protocol access and locally installable agent instructions assumes the trigger might be code. Once that assumption changes, localization becomes a step a pipeline simply executes, checked, versioned, and auditable like everything else the agent touches. Evaluate vendors on that assumption, not on whether they have added an AI feature to an existing portal.