Why we're building an MCP connector for AI translation

I spend a lot of time watching how people actually use translation tools. Not how they say they use them, how they actually behave. And one pattern has become impossible to ignore: the friction isn't in the translation itself. It's in the switching.

A writer is drafting content in Claude. A developer is debugging logic in ChatGPT. A researcher is synthesizing a report in Gemini. At some point, they need to translate something (a phrase, a paragraph, a document) and they leave. They open a new tab, paste text, get a result, copy it back. The translation might be good. But the workflow is broken. The context they've built in the AI conversation (the tone, the terminology, the task) gets interrupted every single time.

This is the problem we've decided to solve. We're building a Model Context Protocol (MCP) connector for MachineTranslation.com, and this post is about why.

Most people use AI translation the wrong way

This isn't a criticism, it's a structural problem. AI translation tools, including ours, were built as destinations. You go there, you translate, you leave. That model made sense when translation was a standalone task. You had a document, you needed it in another language, you uploaded it somewhere.

But that's not how translation fits into work anymore. It's embedded. It happens inside broader workflows — content production, customer support, legal review, software localization, research. And increasingly, those workflows are happening inside AI environments. People are not just using AI to assist their work; they are doing their work inside AI conversations.

When translation lives outside those conversations, it creates a seam. Every time someone switches contexts to translate, they lose something: momentum, focus, the specific framing of what they were working on. Small translations get skipped entirely. Longer ones introduce delays. The result is that translation (the thing that should be invisible) becomes a friction point.

We've been thinking about this for a while. The MCP connector is our answer to it.

What is MCP, and why does it matter for translation?

The Model Context Protocol is an open standard that lets AI applications (Claude, ChatGPT, and others) connect to external tools and data sources directly within a conversation. Instead of switching tabs, you stay inside your AI environment and call on the tool from there. The tool responds in context. The conversation continues.

For most use cases, MCP is a workflow convenience. For translation, it's something more fundamental. Translation is not just about converting text — it's about maintaining meaning across languages, often within a specific domain, tone, or terminology framework. When you translate inside a conversation, the AI already knows what you're working on. It knows the subject matter, the register, the task. That context improves the output in ways that pasting text into a separate tool simply cannot replicate.

This is the shift that matters: moving translation from a UI layer (something you visit) to a context layer, something that works where you already are.

MCP makes that possible. And we think it's one of the most important infrastructure changes happening in the AI ecosystem right now.

The decision we made, and what we ruled out first

We didn't arrive at MCP immediately. We had other options on the table.

A browser extension was one of them. Extensions are familiar, they work across websites, and they're relatively straightforward to build. We considered it. But a browser extension still operates at the surface — it intercepts what you see on a page, not what you're working on inside an AI conversation. It's useful for reading foreign-language content. It's not useful for translation that needs to be embedded in a workflow.

A platform-specific integration (a Shopify connector, for example) was another option. These have obvious distribution appeal. But they're narrow by definition. You build for one platform, serve one audience, and start the process again for the next one.

MCP is different. The value of building a connector there is that users are already inside AI environments doing real work. They're not browsing — they're thinking, writing, building. If we can bring translation into that space, we're not adding a step to their workflow. We're removing one.

That's the argument that convinced us. Not the technical elegance of it, not the novelty — the actual user experience improvement for people who translate as part of something larger.

We made the call: MCP first.

What the MachineTranslation.com MCP connector will actually do

I want to be careful here about how much I share, because this is still in development and the specifics will evolve. But the core concept is simple enough to describe without overpromising.

The connector will allow users to access MachineTranslation.com's translation capabilities directly within their AI environment, without leaving the conversation. Authentication happens once. After that, translation is available on demand — as part of whatever the user is already doing.

What makes this different from a basic translation API call is what MachineTranslation.com brings to the translation itself. We run a multi-model consensus mechanism (our SMART consensus system) that doesn't rely on a single AI model. It queries multiple models, compares outputs, and surfaces the translation that most of the AI models agree on. That's the same quality layer that powers the MachineTranslation.com platform, now available inside the AI conversations where people are actually working.

The technical architecture relies on existing APIs, which means the connector doesn't require a separate application layer. From the user's perspective, it should feel like a native capability of the AI environment they're working in.

Why we're restricting the first release to paid users

This is a deliberate choice, and I think it's worth being transparent about the reasoning.

The initial release of the MCP connector will be available to registered, paid MachineTranslation.com users only. There are two reasons for this.

The first is operational. We need to track usage in order to manage costs, monitor quality, and iterate on the connector based on real behavior. Anonymous or unregistered usage makes that impossible at this stage.

The second is about quality signal. Paid users are more likely to be using MachineTranslation.com for professional or production workflows, the use cases where the connector's value is most apparent. Starting with them means we get feedback from the people who need this most, not from users who are experimenting casually.

We'll evaluate expanding access once the connector has been tested in real conditions and we understand how people are using it. But the first version is intentionally constrained so we can do this right.

What comes after the connector

The connector itself is phase one. But I want to be honest about where this is heading, because the longer-term potential is what actually motivated the investment.

Right now, when you translate something with MachineTranslation.com, the platform doesn't know you. It doesn't know what industry you work in, what terminology you prefer, which AI models consistently produce better results for your language pair, or how your clients want documents formatted. Every session starts from scratch.

An MCP connector changes that over time. A user who translates consistently through the connector builds a translation history. That history is the foundation for a personalized translation experience — one that learns preferred terminology, surfaces the models that perform best for a user's specific language pair and domain, and carries that context forward.

This is what we mean by moving from a UI layer to a context layer. A UI is something you visit when you need it. A context layer is something that learns from your work and improves as you use it.

There's a longer vision here that involves human review as well — giving users the ability to request a native linguist review of AI-generated translations directly through the connector, without leaving their workflow. That's further out. But it's part of why we think MCP is worth building for now, even when the short-term scope is intentionally modest.

Why we're sharing this now

We haven't launched this yet. We're in development. So why write about it?

A few reasons.

One: we build in public. That's a choice we've made deliberately, and I think it creates better products. When we share what we're working on and why, we get pushback, questions, and perspective that we wouldn't get if we waited until launch. If you're reading this and you think we've got something wrong (about MCP, about the connector, about what translation inside AI conversations should look like), I want to hear it.

Two: the people who should use this when it launches are probably not thinking about it yet. MCP adoption is still early. Most users of AI translation tools haven't considered what it would look like to access translation directly from inside Claude or ChatGPT. We want to put that idea in front of the people who would benefit most from it, before the connector exists, so they're ready when it does.

Three: I think the shift from UI layer to context layer is genuinely significant, and it deserves to be articulated before everyone is doing it. Translation infrastructure is about to change. The tools that position themselves as destinations are going to find that harder to defend as AI environments become the primary place where professional work happens. We'd rather be ahead of that change than reactive to it.

We'll update this as the connector moves toward launch. If you're a current MachineTranslation.com user and you want early access, watch this space.