Engine Setup with the Localization MCP

The Lingo.dev MCP server gives AI coding assistants direct access to your localization engine configuration. This guide walks through setting up a localization engine from scratch - from installation to a fully configured engine with per-locale brand voices, glossary rules, linguistic instructions, and model routing.

What you'll configure#

The result is a stateful translation API. Call it from code via the localization API, from the command line via the CLI, or automatically on every pull request via CI/CD. Every request applies all layers automatically.

The problem#

Each localization engine needs brand voices per locale, glossary rules, linguistic instructions, and model routing. Configuring all of this through a dashboard is time-consuming and repetitive - especially the first time, when you're learning what each layer does and how they interact.

The Lingo.dev MCP server lets your AI coding assistant handle the initial setup in a single conversation. You point it at your product's content, and it creates the engine, writes brand voice profiles, identifies terms for the glossary, adds locale-specific instructions, and configures model routing - all in one pass. You review the output and tailor from there.

Step 1: Install the MCP#

Generate an API key from the API Keys section of the Lingo.dev dashboard. Then add the MCP server to your coding agent's configuration.

{
  "lingo": {
    "type": "http",
    "url": "https://mcp.lingo.dev/account",
    "headers": {
      "x-api-key": "your_api_key"
    }
  }
}

Restart your agent and verify the connection by asking it to list your existing localization engines. If the MCP is active, it returns results (or an empty list for new organizations).

Step 2: Configure the engine#

Copy the prompt below and paste it into your AI coding assistant. Replace the URL at the end with your product's website, documentation, or README - the agent needs representative content to infer your voice, terminology, and audience.

Create a localization engine called 'My Product' for localizing into
German, French, Japanese, and Spanish. Study the content at the URL
below to understand our tone, terminology, and audience. Then configure
everything in one pass: brand voices for each locale (and English),
glossary entries for terms that need consistent translations or should
stay untranslated, and locale-specific linguistic instructions.

https://docs.yourproduct.com

The agent reads your content, creates the engine, and configures all layers in a single pass. The next steps are about reviewing and tailoring what it produced.

Step 3: Tailor brand voices#

Review the brand voices the agent created for each locale. A brand voice defines how your product speaks in a specific language - tone, formality, and style. The agent infers these from your content, but the cultural nuances are worth checking.

What to look for:

A well-configured German brand voice looks like this:

Use informal "du" address. Keep a direct, technical tone.
Prefer short sentences. Use active voice. When a German equivalent
exists for a technical term, use it (e.g., "Bereitstellung" for
deployment), but keep widely-adopted English terms as-is
(e.g., API, CLI, Token).

If the register is wrong, tell your assistant directly:

The German brand voice is too informal for our enterprise docs.
Switch it to formal "Sie" register.

Step 4: Tailor glossary#

Review the glossary entries the agent created. The glossary gives the engine exact control over specific terms - either enforcing a translation or preventing translation entirely. The agent identifies terms from your content, but it may miss product-specific ones or pick wrong translations.

A typical glossary after the initial pass:

What to check:

• Missing terms - product feature names, internal jargon the agent didn't encounter
• Wrong translations - the agent may pick a synonym that doesn't match your established usage
• Missing non-translatables - brand names, protocol names, or acronyms that should stay as-is

Glossary entries are matched by semantic similarity - an entry for "Deploy" also matches "Deploying", "deployment", and "deploy your application" without needing separate entries. Use * wildcards for terms that apply across all locales.

Add a glossary entry: 'checkout' should stay as 'Checkout' in
German - it's our product feature name, not the shopping action.

Step 5: Tailor instructions#

Review the instructions the agent created. Instructions are discrete, testable rules for specific locales. Unlike brand voices (which set overall tone), instructions encode rules that generic models miss - punctuation, abbreviations, character width, number formatting.

A typical set of instructions after the initial pass:

Each instruction addresses one concern, making them individually testable - if German abbreviations break, update that one instruction without touching anything else.

What to check:

• Missing rules - number formatting, date formats, currency conventions for your target locales
• Source language - English instructions for Oxford commas, title case, or number formatting are often missing

In French, there should always be a non-breaking space before
colons and semicolons. Add that as an instruction for fr.

Step 6: Configure model routing (optional)#

New engines come pre-configured with model defaults optimized for quality across common and low-resource languages. Most teams don't need to change them.

If you have specific requirements - a model that performs well for your domain, a budget constraint, or a compliance need - override the defaults:

Set Claude Sonnet as the primary model for European language pairs,
with GPT-4o as fallback for Japanese.

Each model config supports ranked fallbacks. If the primary model fails (outage, rate limit, deprecation), the engine automatically tries the next one.

Next Steps#