MCP, skills, and SDK: How AI agents call localization natively without filing a ticket

An engineering team ships a feature. The i18n keys land in the repo. Someone, a PM, a localization coordinator, or an engineer exports the strings, opens a vendor portal, uploads a file, picks languages, and waits. Three days later, translated strings come back in a format that needs reformatting before it merges. Multiply that by every release, every video asset, every legal doc, every product surface that needs more than one language, and localization sits outside the pipeline, waiting on a human to notice it needs doing.

That handoff is the actual bottleneck, not translation quality. Coding agents are now positioned to remove that handoff by calling localization the same way they call a linter, a test runner, or a database migration: inline, mid-task, without a ticket.

This piece describes the mechanics of that shift for Ollang specifically: the hosted MCP server, file-based agent skills, and the TypeScript/Node.js SDK. Three distinct integration surfaces, each suited to a different point in an engineering workflow, all built on the same REST API.

Three ways in, one execution layer

Ollang's documentation states the platform orchestrates AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows in one place, and exposes these through APIs, an MCP server, an SDK, and agent skills. The docs include account setup, your first upload and order, and REST API, MCP, SDK, skills, and workflows, and explain when to use each and how they fit together.

The question of when to use each matters. These are not three branding wrappers around the same call, they are different architectures for different callers:

• MCP is a hosted, authenticated server your agent connects to over a network protocol. No local files, no code to write. You authorize once and the agent gets a set of callable tools.
• Skills are local instruction files that live in your repo or agent config. They teach your agent how to call the Ollang REST API, and no proxy server or MCP connection is needed.
• SDK is a typed client library for when you're writing the integration code yourself, not delegating the call pattern to an agent.

The docs draw the line directly: if you prefer a server-based integration with OAuth, see Ollang MCP, skills and MCP support different architectures: skills are file-based and agent-local, MCP is a hosted protocol server.

The hosted MCP server: authorize once, let the agent drive

For a Head of Engineering evaluating this, the MCP server is the piece that matters most for team-wide agent tooling, because it's centrally hosted rather than something every developer clones into their repo. Ollang runs a hosted Model Context Protocol server using OAuth 2.0 and PKCE, built to work with agents and tools that support the MCP protocol.

Ollang uses OAuth 2.0 with PKCE for a reason. MCP servers that accept remote, authenticated connections need something stronger than a shared API key baked into a config file, because MCP servers serve multiple clients acting on behalf of different users, and the server needs to know who is asking for what. PKCE binds the authorization code to the client that requested it, so an intercepted code cannot be exchanged for a token by an attacker. Practically, that means a developer authorizes their agent once through a standard OAuth consent flow, gets a scoped, revocable token, and subsequent tool calls are authenticated without anyone passing raw credentials around a team's IDE configs.

Because MCP is a protocol rather than a per-vendor integration, the same server connection works across tools that speak the protocol. One hosted endpoint, added once per agent, lets each developer session invoke Ollang's tools directly rather than routing through a shared service account or a manually shared API key. Setup and tool-level detail are in Ollang's API documentation, which is the right place to check exact configuration steps before wiring this into a shared team environment.

Skills: natural-language ops with no server to run

MCP is the right model when you want a persistent, authenticated connection running centrally. Skills solve a narrower, more common case: an individual developer wants their coding agent to handle localization tasks without provisioning server-side infrastructure.

Agent skills are reusable capability packages for coding agents, files that give the agent procedural knowledge, step-by-step instructions, and API details so it can accomplish domain-specific tasks without custom prompts. Skills are files, not services. They work with agents that support local instruction files.

The architecture is deliberately thin. The agent reads a local SKILL.md, which teaches it how to shape a REST call, and the agent makes that call directly against the Ollang API, no proxy server or MCP connection is needed.

What makes this workable for a full localization workflow rather than a single API call is the master-skill-to-sub-skill routing model. The Ollang master skill routes to the right sub-skill based on what you ask your agent, every sub-skill has a defined trigger and an API surface it covers. You don't invoke ollang-order-create by name; you tell your agent "localize this file into Japanese and German," and the master skill resolves that intent to the correct sub-skill chain.

Ollang documents 12 sub-skills covering the full lifecycle, from a no-auth health check through upload, order creation, status polling, quality evaluation, and revision handling. The core sequence for a typical job runs:

1. Upload file → ollang-upload → returns projectId
2. Create order → ollang-order-create → returns orderId(s)
3. Monitor status → ollang-order-get → poll until "completed"
4. Quality check → ollang-qc-eval → scores + segment analysis
5. Report issues → ollang-revision → create revisions if needed
6. Upgrade to human → ollang-human-review → optional linguist review

The last step matters for teams focused on governance: QC evaluation and revision reporting are first-class sub-skills an agent can invoke on its own, so an agent can localize a file, score it, and flag it for human review inside a single autonomous run, with no separate governance tool in the loop. Query parameters using bracket notation are handled automatically by the skills rather than requiring the agent to work around curl formatting quirks, a detail that affects whether an agent's tool calls succeed.

Every operation except the health check requires an API key, obtained from the Ollang dashboard, and the full parameter reference for each of the 12 sub-skills is in the Sub-Skills Reference. A Skills-based setup is meant to be quick, the Quick Start is scoped for install-and-go rather than a multi-day integration project.

The SDK: when you're writing the integration, not delegating it

MCP and skills both assume an agent is deciding when to call localization. The SDK is for the opposite case, your own code needs to own that decision, deterministically, as part of a build or content pipeline.

Ollang ships a TypeScript/Node.js SDK for asset scanning, i18n workflows, CMS capture, and a typed REST client. This is the layer a Head of Engineering uses when localization needs to be a build step rather than an agent judgment call: a CI job that scans a repo for new or changed i18n strings, a content pipeline that captures fields out of a CMS on publish, or a service that needs typed request/response objects instead of raw JSON over HTTP. Where skills teach an agent to construct REST calls from natural language, the SDK gives your TypeScript code the same REST surface with types, so asset scanning and translation-status polling can be written as normal application logic.

The dividing line is this: if a human or an agent decides "translate this now," use MCP or skills. If a system decides it, a webhook fires, a build runs, a CMS entry publishes, use the SDK. All three ultimately hit the same underlying endpoints documented in the REST API reference.

What this looks like inside an actual agent session

Inside an agent session, a developer working a ticket that adds a new onboarding flow finishes editing the English strings file, then tells the agent to localize it into the product's supported languages. With the MCP server connected or the skills files present in the repo, the agent does not stop and tell the developer to file a request, it can localize files directly from its workflow, using the upload-to-order-to-status chain described above, without the developer switching context to a vendor portal.

The same pattern extends to i18n JSON specifically, where structural integrity matters as much as translation quality: a translated string file that breaks key structure is worse than no translation at all, since it fails silently at build time. An agent that understands your tech stack and workflow context can trigger the right multimodal localization actions accordingly.

What changes operationally

None of this replaces the underlying localization work, QC scoring, human review escalation, and the review-gate model documented at the API layer still apply. What changes is where the request originates and how much latency sits between "content needs translating" and "translation starts." A traditional vendor or TMS setup treats localization as a project: someone opens a ticket, a coordinator triages it, a linguist is assigned, and status lives in a portal disconnected from the codebase. With MCP, skills, and the SDK, that request can originate from inside the same agent session that wrote the code, poll its own status, run its own QC check, and escalate to a human reviewer only when the QC score warrants it, all without a ticket ever existing.

This is the reason to treat this as infrastructure rather than a vendor relationship. The measure of whether a localization provider qualifies as infrastructure is whether an agent already running inside your engineering workflow can reach it without anyone leaving that workflow to go ask.