If you've been building with AI assistants (Claude, Cursor, Copilot), you've probably noticed a pattern: the assistant is great at writing code, but the moment you need it to interact with an external service, you're back to copy-pasting between tabs.
"Hey Claude, what's the translation status for our German locale?"
Claude doesn't know. It can't check. You tab over to your TMS dashboard, look it up, tab back, paste the info, and ask your follow-up question. The AI is powerful but disconnected.
MCP changes that. And for translation workflows specifically, the impact is bigger than you'd expect.
What MCP actually is
Model Context Protocol (MCP) is a standard that lets AI assistants connect to external tools and services. Think of it as a way for your AI to call APIs on your behalf, with your authorization, without you having to copy-paste data back and forth.
Instead of the assistant just reading and writing code, it can query your project management tool, check your deployment status, or, relevant to this post, manage your translation pipeline.
The key distinction from just using an API: MCP integrations are conversational. You talk to your assistant in natural language, and it figures out which tools to call and in what order. You don't write code to interact with the integration. You just ask.
What this means for translations
Translation management is a workflow with a lot of small, repetitive interactions: checking completion status per language, searching for specific strings, pushing new source strings after a code change, pulling translations before a deploy.
None of these are hard. All of them interrupt your flow. You tab to a dashboard, click through a UI, find the info you need, tab back. Multiply by 10 languages and you're spending real time on what should be background tasks.
With an MCP-enabled TMS, these become conversational:
"How many strings are untranslated in Japanese?"
Your assistant queries the TMS, gets the count, and tells you. No tab switch. No dashboard.
"Push the new strings I just added to the auth module."
The assistant runs the push command and reports what was created, what changed, and what's unchanged. Done.
"Show me all strings in the checkout namespace."
The assistant searches your strings by key, lists everything under checkout.*, and you can see exactly what's there before making changes.
"Pull the French translations and show me the diff."
The assistant pulls the translations, generates a diff against your current language files, and you review it before committing.
This isn't hypothetical. This is what we built into Stringhive.
How Stringhive's MCP server works
Stringhive ships an MCP server that exposes your translation data to compatible AI assistants. Currently that means Claude Desktop, Claude Code, and Cursor, with more clients adopting MCP regularly.
The server provides these tools:
list_hives - Show all your projects (Stringhive calls them "hives") with their source locale, string counts, and target languages.
hive_stats - Get translated and approved counts per locale for a hive. "German is 94% complete, Japanese is 71%, Arabic is 45%." Instant overview without opening a dashboard.
list_strings - Search source strings in a hive by key or value. "Show me all strings in the auth.php file of my-app."
push_strings - Push source strings into a hive. Provide key-value pairs and a filename, and Stringhive creates or updates them. The assistant can do this after you've made code changes, or as part of a larger task ("refactor the settings page and push the new strings").
pull_translations - Export translated strings for one or all locales in JSON or PHP format. The assistant writes the files directly into your project.
import_translations - Push translated strings for a specific locale into Stringhive. The counterpart to pull: useful when you already have translation files and want to get them into the workflow.
list_locales - Look up any locale Stringhive supports, with codes, names, and RTL flags. Handy when you're not sure if it's zh-TW or zh-Hant.
The assistant handles the MCP calls transparently. You don't need to know the tool names. You just talk.
A real workflow, not a demo
Here's what a typical session looks like when you're building a feature that needs new translatable strings.
You're working in Claude Code or Cursor. You've just built a new onboarding flow with 15 new strings.
You: "Push the new strings I added in lang/en/onboarding.php to Stringhive."
Assistant: Calls push_strings, reports 15 new strings created, 0 updated, 0 unchanged.
You: "What's the translation status for this hive?"
Assistant: Calls hive_stats. Reports: German 85% complete, French 82%, Japanese 71%, Korean 45%. The 15 new onboarding strings need translation in all locales.
You: ...continue coding for an hour. Translators pick up the new strings in Stringhive's editor, where machine translation drafts (from your BYOK provider) are waiting for review...
You: "How are the translations looking now?"
Assistant: Calls hive_stats. Reports: German 92% complete (the onboarding strings are mostly translated), French 89%. Looking good.
You: "Pull the German translations."
Assistant: Calls pull_translations for German, writes the translated strings to lang/de/onboarding.php.
The entire translation management happened inside your editor. No dashboard. No tab switching. No spreadsheets. The translators did their work in Stringhive's editor (with translation memory, glossary, and context). You managed the developer side of the pipeline without leaving your code.
What this replaces
Let's be honest about what this is actually replacing. It's not replacing translators. Machine translation provides drafts. Humans review and approve. That hasn't changed.
What it replaces is the developer overhead of managing the pipeline: the pushing, pulling, status checking, format converting, and deploy coordinating. Those tasks used to require either a dashboard session or a series of CLI commands. Now they're conversational side-effects of your normal coding workflow.
For a team working across 10 languages, this saves 15-30 minutes per developer per day in context switches alone. That's not a made-up number. We tracked it across our own projects when we integrated the MCP server. The translation work didn't change. The time developers spent managing it did.
The BYOK machine translation angle
Stringhive's machine translation is bring-your-own-key. You connect your DeepL, Google Translate, Azure Translator, OpenAI, ModernMT, or Mistral API key. Stringhive calls the API with your key and charges you nothing on top. No per-word markup. No hidden translation fees.
Translators get machine translation drafts in the editor, either one string at a time or in bulk for an entire queue. They review, edit if needed, and approve. Through MCP, the developer side stays in your editor: push new strings after a code change, check completion per locale with hive_stats, pull translated strings when they're ready. The human review happens in Stringhive. The pipeline management happens in your terminal.
The cost of machine translation is whatever your API provider charges. For most applications, that's a few dollars per language, per batch.
Who this is for (and who it isn't)
This workflow makes sense if you're already using an AI assistant for development (Claude Code, Cursor, etc.) and you're managing a multilingual application with enough strings and languages that translation management takes real time.
It doesn't make sense if you have 50 strings in 2 languages. At that scale, editing files manually is faster than setting up any tool.
It also doesn't replace a localization team's workflow for content-heavy products (marketing sites, documentation, help centers). Those workflows need different tools. Stringhive and its MCP integration are built for application strings managed by developer teams.
Getting started
If you're already using Stringhive, the MCP server is available on all plans including the free tier. Set it up in your assistant's MCP configuration and start talking to your translations.
If you're not using Stringhive yet, the free tier gives you 1,500 strings and full MCP access. stringhive.com to get started.
The MCP integration works with Claude Desktop, Claude Code, Cursor, and any MCP-compatible client.
Building multilingual apps?
We've built and maintained multilingual applications for clients across Europe and Asia. If you need help with localization architecture, translation workflows, or integrating AI into your development pipeline, talk to us. We'll tell you what you actually need (which might be less than you think).
