What is an MCP localization server?

It's a server exposing localization actions — uploading source strings, setting context, translating, retrieving results — as Model Context Protocol tools. strings.dev ships one as the strings-mcp-server npm package, so an MCP client like Claude, Cursor, or Copilot can run the whole localize loop by calling typed tools instead of navigating a web dashboard.

How do I localize my app with Claude?

Register strings-mcp-server in your MCP client with your per-project key, then ask in plain language — e.g. 'localize my strings.xml into German and Japanese, keep AppName and %1$s untouched.' The agent uploads your native file, requests the locales, and writes the translated files back in the same format. Setup details are at docs.strings.dev.

Can I localize an Xcode String Catalog with Cursor?

Yes. strings.dev reads .xcstrings String Catalogs (and .xcloc) natively and returns them in the same format, preserving plural variations and placeholders like %1$@. Cursor drives it through the MCP server or the pre-filled CLI scripts, so you localize without any XLIFF conversion.

Does the free tier work with agents and MCP?

Yes. The free Indie tier (1 project, 1 language, unlimited words, app + brand localization) runs the full MCP and CLI loop for a single target locale. To translate into unlimited languages with 2 projects, brand context, and the QA & analytics dashboard, upgrade to Indie Plus at $20/mo, or $10/mo billed annually.

Can agents run localization continuously in CI?

Yes. The generated per-project CLI scripts and REST API can be wired into a git hook or CI pipeline, so changed strings are re-localized automatically on every merge — an agent or an automated job runs the same push/translate/pull loop headlessly.

AI localization built for coding agents — an MCP localization server for your app strings

strings.dev is localization designed for agents, not a chatbot glued to a translation management system. Every project ships an MCP localization server, a per-project REST key, pre-filled CLI scripts, and a generated AI-skill prompt — so Claude, Cursor, or Copilot can run the entire localize loop from inside your editor.

You describe the outcome. The agent uploads your native .xcloc or strings.xml, requests locales, and writes the translated files back — same format in, same format out.

Localize your app with Claude, Cursor, or Copilot

Most "AI localization" is a language model bolted onto a legacy TMS: you still click through a web dashboard, export XLIFF, and re-import. strings.dev inverts that. The product surface an agent needs — file upload, locale selection, context, retrieval of finished translations — is exposed as tools your assistant can call directly.

Point your agent at the strings-mcp-server package and it can drive a real localization backend through an MCP localization server, not scrape a UI. This is what makes agentic localization actually work: the agent isn't guessing translations token-by-token, it's orchestrating a pipeline that returns native, review-ready files.

The MCP localization server

strings-mcp-server is an npm package that connects any MCP-capable client (Claude Desktop, Claude Code, Cursor, Copilot-style agents) to your strings.dev project using a per-project API key. Once it's registered, the agent has typed tools for the whole loop: push source strings, set app-description context, kick off translation, and pull results.

// MCP client config — one project, one key
{
  "mcpServers": {
    "strings": {
      "command": "npx",
      "args": ["strings-mcp-server"],
      "env": { "STRINGS_PROJECT_KEY": "prj_live_…" }
    }
  }
}

Setup depth — auth, tool reference, CI usage — lives at docs.strings.dev. You can also start a project and grab a key at platform.strings.dev.

What a developer actually asks the agent

Because the tools are conversational, the request looks like plain intent:

"Localize the Xcode String Catalog in App/Localizable.xcstrings into German, Japanese, and Brazilian Portuguese. Keep AppName and %1$@ untouched, and use the app description for tone."

The agent then, on your behalf:

Reads the native file (.xcstrings String Catalog, .xcloc, or Android strings.xml).
Uploads the source strings and attaches your app-description context.
Requests the target locales and any per-string translation notes.
Waits for translation, then writes the returned files back into your repo in the same format — String Catalog plural variations and Android <plurals> quantity strings preserved.

To localize an Xcode String Catalog with Cursor, or run the same loop headlessly in CI, the pre-filled CLI scripts wrap the identical REST endpoints:

# Generated per project — the agent (or your CI) can run these directly
strings push ./App/Localizable.xcstrings
strings translate --to de,ja,pt-BR --context "$(cat store-desc.txt)"
strings pull --out ./App/

Why native formats matter for agents

An agent is only as good as what comes back. strings.dev takes native files and returns native files — no XLIFF round-trip to corrupt your catalog:

Apple: iOS, iPadOS, macOS, tvOS, visionOS, watchOS, CarPlay via .xcloc and .xcstrings.
Android: Android, Android TV, Wear, Auto via strings.xml.
Placeholders preserved: iOS %@ %lld %1$@, Android %s %d %1$s, plus plural rules on both platforms.
Protected: brand phrases, URLs, emails, handles, and proper nouns pass through untouched.

This scopes cleanly: strings.dev localizes in-app native strings only. It does not translate marketing sites, and App Store / Play Store metadata and screenshots are out of scope — localize those separately once your in-app strings ship.

Continuous, agent-run localization

The same tools that power a one-off request power continuous localization. Wire the CLI into a git hook or CI step, and a Cursor/Copilot agent — or an automated job — re-localizes changed strings on every merge. New key in your catalog, translated variants back before the PR lands. The generated AI-skill prompt gives your agent the exact loop to follow, so agent-run app translation stays consistent across runs instead of drifting per prompt.

Free to start, priced flat

The free Indie tier gives you 1 project, 1 language, unlimited word translations, and app + brand localization — enough to run the full MCP loop for a single target locale. To go multi-locale, Indie Plus ($20/mo, or $10/mo billed annually) adds unlimited languages, 2 projects, brand context, and a QA & analytics dashboard that flags failed translations for retry — useful precisely because agents run unattended and you want a place that surfaces what needs a second look. See pricing for the full split.

Unlike per-seat, web-and-enterprise TMS platforms (as of 2026 — check any competitor's current pricing), strings.dev is a mobile-native, flat-priced backend an agent can actually drive. Fewer clicks, no XLIFF, same format in and out.