Docs · Features

AI agents and MCP

How an AI agent, script, or automated integration drives Localization OS, through the same HTTP API a person's browser uses, a CLI, and a purpose-built MCP server.

What it does#

Localization OS is designed so that most features exist on the web UI, the API and the CLI equally, and a page that names a real gap says so rather than leaving you to discover it. A few surfaces are still web-only in the current release, among them OAuth connector setup, launching an LQA re-score, and the segmented CAT editor's own save path. An agent driver, any non-human caller such as an MCP server, a script, a CI job, or an LLM with tools, authenticates with a personal API key and acts inside a tenancy that already has its own access rules: every object belongs to exactly one organization, which contains customers, which contain projects.

A project is either a document project (files in, files out) or a key-based project (string keys, for continuous localization), chosen at creation and fixed afterward. Work runs through workflows: an ordered list of steps such as an LLM translation step, an automated quality check, a pause for human review, a translation-memory pre-fill step, or a dispatch to an external vendor.

An MCP server packages this same API as a set of task-shaped tools for an MCP-compatible client, so an agent runtime can drive the product the same way a person or a script does, without hand-rolling HTTP calls.

Getting started#

Issue a personal API key from the Account page, or with the CLI's key-issuing command. Keep it out of prompts, logs and version control.
Authenticate every API request with that key in a request header.
For scripted or CI use, the CLI can run directly against a local install with no server or login at all, or be pointed at a remote install with the key and its URL.
For an agent runtime, point an MCP-compatible client at the bundled MCP server to get a curated set of tools instead of raw HTTP calls.

curl -H "X-Loc-Token: YOUR_API_KEY" \
  https://your-install.example.com/api/projects

project create "Acme Site" --customer-id 7 --targets de-DE
doc upload 7 ./handbook.docx
doc translate 12 --locale de-DE
doc export 12 --locale de-DE --out handbook.de-DE.docx

The same flow applies to a key-based project, substituting key import and key translation for document upload and document translation.

Works with#

Documents: the document pipeline is what most of the API drives, upload, segment, translate, review, export.
Keys: key-based projects and their change feed are the continuous-localization half of the API surface.
Workflows: every run an agent launches executes a workflow, with the same steps and quality checks as a person-driven run.
Engines: a step that names no engine falls back to the install's configured default.

Current limits#

Current limits

A completed run status does not by itself mean the output is good. Segment status and any quality flags need to be read alongside it, since a run can complete with content still held for review.

A small number of the busiest routes are rate-limited; the rest are unthrottled but should not be hammered.

Some operator-level actions, database operations, initial setup, and cross-organization administration, are host-only and not reachable over the API at all.

Configuration and credential changes are more tightly gated than everyday translation work, and a few install-level switches can only ever be changed on the host itself, never remotely.

An agent driver should never fabricate a confirmation a human is meant to supply, an exact name to confirm a delete, a cost estimate to launch a paid run. Those checks exist because the action is not reversible.

Output flagged for review is never a finished translation. Treat "needs review" and a "partial" result as exactly that, not as done.