Translation & localization agents: state of play

The short version

Agents are becoming useful operators inside localization workflows. They can inspect a repository, find localizable content, prepare a brief, create or update translation records, check project status, move files, run mechanical tests, and assemble evidence for review. They are much less reliable as unsupervised judges of meaning, tone, cultural fit, legal effect, accessibility, or final release quality.

MCP is one way to give an agent a structured connection to a localization system or service. It does not make the agent a translator, a project manager, or an accountable reviewer. It makes named actions and data available through a common protocol. The quality of the result still depends on the brief, the tool contract, permissions, language expertise, and the release process.

What is real today

The leading edge is therefore not a fully autonomous translation department. It is an agent that coordinates bounded operations around a versioned source, a localization platform, qualified language reviewers, and explicit approval gates.

Lokalise documents a beta MCP server that can let compatible assistants check project progress, list untranslated keys, create tasks, add languages, and update glossary terms. Evidence: lokalise-mcp-2026

SimpleLocalize documents an MCP server that exposes translation-key, language, tag, and translation operations through its API. Evidence: simplelocalize-mcp

Apple documents agent-assisted Xcode localization that can add languages, update string catalogs, translate strings, add plural variants, preserve machine-translation provenance, and support review in a running app. Evidence: apple-localization-agents-2026

Multilingual agent benchmarks report that performance and security can degrade outside English and that errors can compound over multi-step work, so an English-only success case is not a release argument. Evidence: maps-benchmark-2026, polyworkbench-2026

Three different things people call a localization agent

• A coding agent changes source code and localization files: extracting strings, adding keys, updating catalogs, or fixing hard-coded text.
• A workflow agent operates a TMS or vendor process: creating projects and tasks, moving files, checking status, applying a glossary, or preparing a delivery.
• A language agent proposes translations, summaries, subtitles, metadata, or QA findings. This is the layer where subject knowledge, language variety, context, and independent review matter most.
• One system may do all three, but its permissions, evidence, and approval rules should still be separated by job.

A useful service-request flow

A reliable agent should collect the brief before it creates work or promises a price. It should then ask a service endpoint for options, show assumptions, obtain approval, create the job, and keep the requester informed without silently changing scope.

1. DISCOVER   inspect files, formats, counts, locale setup, and known constraints
2. CLARIFY    ask for missing languages, audience, service level, deadline, and review owner
3. ESTIMATE   request a quote with assumptions and excluded work
4. CONFIRM    show price, scope, data destination, deadlines, and side effects
5. CREATE     open the job with an idempotency key and least-privilege credentials
6. TRACK      report status, questions, blockers, and approved scope changes
7. VALIDATE   run technical checks and route linguistic review to qualified people
8. DELIVER    return files, reports, provenance, unresolved issues, and acceptance steps

What a translation or localization request must contain

• Source language, every target language and market, and the requested response language. Do not infer market from language alone.
• Service requested: translation, transcreation, editing, MT post-editing, terminology, internationalization review, localization QA, subtitling, captioning, dubbing, voice-over, transcription, data annotation, or evaluation.
• Content inventory: files, formats, word or minute counts, media duration, strings, screenshots, build, repository or TMS location, and version.
• Audience, subject, purpose, tone, brand terms, references, prohibited terms, and existing translation memory or glossary.
• Deadline, time zone, launch dependency, review stages, acceptance criteria, delivery format, and named decision owner.
• Accessibility requirements, privacy classification, allowed processing locations and providers, retention, confidentiality, and whether model training is prohibited.
• Commercial assumptions: pricing unit, minimum fee, rush or complexity factors, pass-through costs, taxes where applicable, currency, and change-control rule.

A practical MCP tool surface

Keep tool names narrow and make their side effects obvious. A quote request should not create a project; a validation tool should not publish a release. The agent can chain tools, but each tool remains understandable and auditable.

inspect_localization_scope({ sourceRef, contentType, sourceLanguage })
request_language_service_quote({ service, sourceRef, sourceLanguage, targetLocales, volume, deadline, reviewLevel, constraints })
create_language_service_job({ acceptedQuoteId, requester, approver, idempotencyKey })
check_language_service_job({ jobId })
submit_scope_change({ jobId, reason, addedVolume, deadlineImpact, priceImpact })
validate_localized_delivery({ jobId, buildRef, targetLocales, checks })
approve_localized_delivery({ jobId, reviewer, evidenceRefs, localeDecisions })

Design the contract for incomplete information

Localization requests are usually incomplete on the first turn. Let the server return structured missing fields and a resumable request identifier. The agent can ask the user, resume the same request, and require confirmation when a price, deadline, upload, external provider, or irreversible action changes.

The July 2026 MCP specification formalizes patterns for stateless operation, explicit state handles, multi-round-trip requests, task-oriented work, and stronger authorization behavior. Evidence: mcp-spec-2026-07-28

status: needs_input
requestId: l10n_req_0184
missing: [targetLocales, audience, deadline, reviewLevel]
assumptions: [sourceLanguage=en, contentType=software_strings]
nextAction: collect_missing_fields
expiresAt: 2026-08-27T17:00:00Z

Where people remain essential

• Deciding what the source means when product context, intent, humor, brand voice, law, or cultural knowledge changes the answer.
• Choosing the right language variety, register, terminology, representation, and market adaptation.
• Reviewing safety-critical, regulated, contractual, medical, financial, political, or reputation-sensitive content.
• Judging subtitles against picture, performance, reading speed, speaker identity, sound cues, accessibility, and delivery specifications.
• Validating speech, voice, and audiovisual work for pronunciation, timing, emotion, identity, consent, and cultural fit.
• Owning the final acceptance decision and feeding corrections back into the glossary, guide, tests, and workflow.

Security, privacy, and commercial controls

• Give read, quote, create, modify, approve, and publish actions separate permissions. Most agents should not hold all six.
• Show the user which files, strings, media, personal data, credentials, and provider endpoints will be used before upload.
• Use short-lived credentials, tenant and project scoping, idempotency keys, audit records, and dry runs for consequential operations.
• Treat source files, translation memories, glossaries, prompts, embeddings, recordings, faces, and voices as distinct data assets with explicit retention and deletion behavior.
• Do not let the agent accept a quote, expand a target-language list, approve a change order, or publish content without the authority named in the request.

Worked failure: one prompt becomes the wrong job

A product manager asks an agent to translate the launch into Portuguese by Friday. The agent assumes Brazilian Portuguese, sends only the visible UI strings to a model, misses email and App Store content, reuses European Portuguese terminology from an old glossary, and publishes without in-product review. Every individual API call succeeds; the launch still fails.

The repair is procedural, not cosmetic:
- ask which market and content inventory are in scope
- identify every source and version
- bind the correct glossary and style guide
- return a quote and schedule before creating the job
- preserve machine-generated provenance
- test the localized build
- require a qualified pt-BR or pt-PT reviewer, as selected
- publish only after named approval

Release-gate checklist

• The request records source, targets, markets, modalities, volume, deadline, service level, acceptance criteria, and owner.
• Every agent and MCP tool action has the minimum permission, a documented side effect, and an audit identifier.
• Prices and dates show assumptions; changes require a visible change order rather than silent recalculation.
• Machine-generated and machine-edited content remains identifiable through review and delivery.
• Technical QA covers missing content, placeholders, tags, plural variants, formats, layout, directionality, timing, and delivery integrity as relevant.
• Qualified reviewers evaluate meaning, terminology, style, cultural fit, accessibility, and risk in every material target market.
• A dry run, rollback path, incident owner, and final human approval exist before publishing or another irreversible action.

A sensible first project

Start with a reversible workflow whose inputs and outputs already exist: inspect one repository or TMS project, produce a scope report, request a quote, create a draft task after confirmation, and report status. Measure missing-field recovery, correct tool use, unauthorized-action rate, time saved, and reviewer corrections by language. Add translation generation only after the operating path is reliable.

How this was built

Admas reviewed the current MCP specification, official product documentation, and primary multilingual-agent research. Product examples describe documented capabilities, not an endorsement. The service contracts, operating model, failure scenarios, and release checks are Admas implementation patterns to adapt to the languages, content, systems, permissions, and consequences of each project.