DEV Community: Łukasz Nawrocki

I Built an MCP Server for My Translation Tool - Here's How (and Why)

Łukasz Nawrocki — Thu, 12 Feb 2026 19:04:10 +0000

Outside of my usual 9-5 mobile dev work (but due to issues found at it), I've decided to build verba.dev, a light and fully automated translation management system for small businesses and indie devs. As usual, one idea and project, once started, made my brain generate tons of new ideas and potential projects.

One of them being: what if developers could manage their translations without ever leaving their AI coding assistant?

No dashboard tabs. No copy-pasting keys. Just tell Claude Code or Cursor: "Add a French translation for the checkout button" and it happens.

That's what MCP lets you do. And I'm open-sourcing the server.
Repo: github.com/verbadev/mcp-server

What is MCP, quickly

Model Context Protocol is an open standard (originally from Anthropic, now under the Linux Foundation) that lets AI assistants connect to external tools.

If you've used Claude Desktop, Claude Code, Cursor, or Windsurf, you've probably seen MCP servers in action. The GitHub MCP server lets Claude read your repos. The Slack MCP server lets it search messages. The filesystem MCP server lets it read and write files.

The pattern is simple: you build a server that exposes "tools" (functions the AI can call), and any MCP-compatible client can use them.

Why I built one for a TMS

With most translation tools, the developer workflow looks like this:

Write code
Switch to browser
Open translation dashboard
Find the right project
Add a key
Type the default value
Click "translate"
Switch back to editor
Repeat 47 times

Verba already made this much better. With our SDK, you just write verba.t('checkout.success', 'Payment successful!') in your code and the key gets created automatically with AI translations to all your configured languages. No dashboard, no context switching. You stay in your editor.

But there's still a gap. What about checking which keys are missing translations? Reviewing what's been translated? Adding a new language to the project? Cleaning up unused keys? For those tasks, you still had to open the dashboard.

The MCP server closes that gap entirely. Now the workflow is:

Write code
When you need anything translation-related, just ask your AI assistant

"Show me all untranslated French keys." "Add Japanese to the project." "Delete all keys that start with old." - all from your editor, zero context switching, zero dashboard.

The architecture

The MCP server is intentionally simple - it's a thin TypeScript wrapper around the Verba REST API. No database access, no business logic, no secrets baked in. Just HTTP calls.

Developer <-> AI Assistant (Claude/Cursor) <-> MCP Server <-> Verba API

The server runs locally via stdio transport. Your AI assistant spawns it as a subprocess and communicates over stdin/stdout using JSON-RPC. Your Verba API key stays in your local environment.

Building it

Setup

mkdir verba-mcp-server && cd verba-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk
npm install -D @types/node typescript

The whole server lives in a single file: src/index.ts.

The API helper

Every tool needs to call the Verba API, so I wrote a small wrapper:

const API_KEY = process.env.VERBA_API_KEY;
const API_URL = (process.env.VERBA_API_URL || "https://verba.dev").replace(
  /\/$/,
  ""
);

if (!API_KEY) {
  console.error("VERBA_API_KEY environment variable is required");
  process.exit(1);
}

async function verbaApi(
  method: string,
  path: string,
  body?: unknown
): Promise<{ ok: boolean; status: number; data: unknown }> {
  const url = `${API_URL}${path}`;
  const options: RequestInit = {
    method,
    headers: {
      Authorization: `Bearer ${API_KEY}`,
      "Content-Type": "application/json",
    },
  };
  if (body) {
    options.body = JSON.stringify(body);
  }

  const response = await fetch(url, options);
  const data = await response.json();
  return { ok: response.ok, status: response.status, data };
}

Instead of throwing on errors, the helper always returns { ok, status, data } so each tool can decide how to surface failures to the LLM.

Registering tools

The SDK makes this clean. Each tool gets a name, description (this is what the LLM reads to decide when to use it), a Zod schema for inputs, and a handler:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "verba",
  version: "0.1.0",
});

server.tool(
  "list_keys",
  "List translation keys with optional search, locale filter, and pagination",
  {
    projectId: z.string().describe("The project ID"),
    search: z.string().optional().describe("Search in key names and values"),
    locale: z.string().optional().describe("Filter by locale"),
    untranslated: z
      .boolean()
      .optional()
      .describe("Only show keys with missing translations"),
    page: z.number().optional().describe("Page number (default 1)"),
    pageSize: z
      .number()
      .optional()
      .describe("Results per page (default 50, max 100)"),
  },
  async ({ projectId, search, locale, untranslated, page, pageSize }) => {
    try {
      const params = new URLSearchParams();
      if (search) params.set("search", search);
      if (locale) params.set("locale", locale);
      if (untranslated) params.set("untranslated", "true");
      if (page) params.set("page", String(page));
      if (pageSize) params.set("pageSize", String(pageSize));

      const qs = params.toString();
      const { ok, data } = await verbaApi(
        "GET",
        `/api/v1/projects/${projectId}/keys${qs ? `?${qs}` : ""}`
      );
      if (!ok) {
        return {
          content: [{ type: "text", text: `Error: ${JSON.stringify(data)}` }],
          isError: true,
        };
      }
      return {
        content: [{ type: "text", text: JSON.stringify(data, null, 2) }],
      };
    } catch (error) {
      return {
        content: [
          { type: "text", text: `Error: ${(error as Error).message}` },
        ],
        isError: true,
      };
    }
  }
);

The pattern is identical for every tool. Here's the one that triggers AI translation - probably the most powerful one:

server.tool(
  "translate",
  "AI-translate one or more keys to target locales. Max 20 keys per request.",
  {
    projectId: z.string().describe("The project ID"),
    keys: z.array(z.string()).describe("Array of key names to translate"),
    targetLocales: z
      .array(z.string())
      .optional()
      .describe(
        "Specific locales to translate to (defaults to all non-default locales)"
      ),
  },
  async ({ projectId, keys, targetLocales }) => {
    try {
      const { ok, data } = await verbaApi(
        "POST",
        `/api/v1/projects/${projectId}/translate`,
        { keys, targetLocales }
      );
      if (!ok) {
        return {
          content: [{ type: "text", text: `Error: ${JSON.stringify(data)}` }],
          isError: true,
        };
      }
      return {
        content: [{ type: "text", text: JSON.stringify(data, null, 2) }],
      };
    } catch (error) {
      return {
        content: [
          { type: "text", text: `Error: ${(error as Error).message}` },
        ],
        isError: true,
      };
    }
  }
);

Connect the transport

Last step - wire it up to stdio:

const transport = new StdioServerTransport();
await server.connect(transport);

That's the entire server. Build it with tsc and you're done.

The 9 tools

Here's what the server exposes:

Tool	What it does
`list_projects`	List all your Verba projects
`get_project`	Get project details (locales, key count)
`list_keys`	List translation keys with search, filter, pagination
`add_key`	Add a new key with auto AI-translation
`set_translation`	Set a translation for a key + locale
`translate`	AI-translate keys to target locales
`list_untranslated`	Find keys missing translations
`add_locale`	Add a new locale to a project
`delete_key`	Delete a translation key

Testing with MCP Inspector

Before connecting to Claude, test your tools in isolation:

VERBA_API_KEY=sk_your-key npx @modelcontextprotocol/inspector build/index.js

This opens a browser UI where you can click any tool, fill in parameters, and see the raw response. Invaluable for debugging.

Using it in Claude Desktop

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "verba": {
      "command": "node",
      "args": ["/path/to/mcp-server/build/index.js"],
      "env": {
        "VERBA_API_KEY": "sk_your-secret-key"
      }
    }
  }
}

Restart Claude Desktop, and you'll see the hammer icon showing 9 available tools.

Using it in Claude Code

claude mcp add verba -- node /path/to/mcp-server/build/index.js

Then set the environment variable:

export VERBA_API_KEY=sk_your_key_here

Now you can say things like:

"Show me all untranslated keys for French in my project"
"Add a key 'checkout.success' with value 'Payment successful!' and translate it to all languages"
"What languages does my app support? Add Japanese."

The AI figures out which tool to call, extracts the parameters from your natural language, and executes it. You never touch a dashboard.

Three things I learned building this

1. Tool descriptions are prompts. The LLM reads your tool descriptions to decide which tool to use. Write them like you're explaining the tool to a junior developer. Be specific about what each parameter does.

2. Return structured data, not prose. The LLM will format the output for the user. Give it clean JSON or structured text, not sentences. Let the AI do the presentation.

3. Error handling matters more than usual. When a tool fails, the LLM needs to understand why so it can either retry or explain the issue to the user. Return clear error messages, not stack traces.

Why open source it?

The MCP server contains zero business logic. It's just an HTTP client with tool definitions. The value is in the Verba platform - the AI translations, OTA delivery, and dashboard. Open-sourcing the MCP server lowers friction for developers and lets the community contribute tool improvements.

If you're building a developer tool, I'd encourage you to do the same. MCP servers are the new API clients. They're how developers will interact with your product in 2026.

What's next

I'm working on adding the MCP server to the official MCP Registry so it shows up in MCP-compatible clients by default. I'm also exploring adding resources (read-only data the LLM can pull from) and prompts (templates for common translation workflows).

If you're building a SaaS product for developers, consider this: the next generation of developers won't visit your dashboard. They'll talk to their AI assistant, and their AI assistant will talk to your MCP server. Build for that future.

Verba (verba.dev) is a translation management system built for small businesses and indie developers. Three lines of code, AI-powered translations, OTA delivery. $29/month for unlimited everything.

MCP Server: github.com/verbadev/mcp-server (open source, MIT)

If you found this useful, I'm @verbadotdev on X.

Code Sharing with React Native & Webpack

Łukasz Nawrocki — Mon, 29 Mar 2021 13:10:17 +0000

Time is a crucial factor in modern software development – clients need features delivered in a flash. Time – we could always do with more of it. As software engineers, though, we are often faced with such situations and have developed strategies to better use time. We work to reduce the amount we spend on unnecessary tasks. On repetitive work. On duplication of effort.

One target of such efforts is code duplication – something of particular relevance for multi-platform applications.

Code sharing is a technique that enables applications to reuse the same code across desktop, web, and mobile platforms. When done successfully, an application does not sacrifice its native look and feel on each platform. As it’s a large topic, I will limit the discussion in this post to sharing a single component across multiple platforms. Also, in reality, it’s a more likely scenario – one where we want to add a shareable component to a long-running project with an established codebase.

A conservative approach to code sharing would be to share business logic, for example, a set of JavaScript functions in a common Node module, and develop the UI of the application separately. However, this approach would not fulfil our primary objective. We would still need to implement the UI from scratch, using two different technologies, making one developer create the same feature twice, or even worse – engaging two developers for the same job.

Instead, I’ll go with a strategy based on the React Native framework that has more code sharing potential. It enables developers to create mobile applications in JavaScript and deliver them as native applications with a native look and feel.

But the best feature of React Native is yet to be fully utilised in the programming world. It is the package called React Native Web that allows web developers to use React Native components and run on the web using React DOM. React Native Web is widely used in the React Native community and makes it easy to reuse components used to create mobile React Native applications in ReactJS web apps. Let’s create an example component and see what it takes to “learn once, write everywhere”.

Project Structure

In this post we’ll only be talking about a single component. In the real world, it would likely be part of a larger component library. We’ll be using TypeScript, but there’s nothing preventing you from using JavaScript should you wish – obviously you’d need to change the configuration and webpack loaders though. Apart from including typings and creating a need for tsconfig.json file, this assumption also matters when it comes to choosing appropriate webpack loaders.

Let’s create the main structure of our project:

-src/
-web/
-package.json
-tsconfig.json
-webpack.config.js

The UI and login of our shareable component will sit in the src directory. We create a simple round button which will accept onPress callback and imageSource as properties:

src/components/Button.tsx:

import React from "react";
import { TouchableOpacity, StyleSheet, ImageSourcePropType } from "react-native";

Interface ButtonProps {
  onPress: () => void
  imageSource: ImageSourcePropType
}

export default function Button({ onPress, imageSource }: ButtonProps) {
  return (
    <TouchableOpacity style={styles.button} onPress={onPress}>
      <Image
        style={styles.image}
        source={imageSource}
      />
    </TouchableOpacity>
  );
}

const styles = StyleSheet.create({
  container: {
    width: 56,
    height: 56,
    borderRadius: 28,
    justifyContent: "center",
    alignItems: "center",
    backgroundColor: "#fff",
  },
  image: {
    width: 28,
    height: 28,
  },
});

We will keep all the components in the src directory. This way, every time someone installs the package, the code will appear in node_modules of the mobile React Native app. The other thing we could do would be to build it into a separate lib directory, for example with the tsc command, but we’re not going to do that here today.

The other important directory in the project tree is web. This is a place where we will keep the JavaScript component bundle. This is important because we can’t rely on React Native and React Native Web being installed in the React app, so in order to use our component in a web application we should have a pure React version of it prepared. How to make this bundle is discussed in the next section – for now it is important to note we will have a separate directory for the web.

We should also have a way to differentiate between the web, bundled version and React Native version of the component when importing from our library. We will do it by differentiating import paths. For web applications, we will be using /web directory to import, as presented below. For the React Native we will use the root directory represented by the name of the library. We should not have one entry point for it, because that will bring a risk of importing the bundle in React Native or importing React Native version in the React app. This is why inside the web directory we will add a new package.json file:

web/package.json:

{
  "main": "build/bundle.web.js",
  "types": "build/src/index.d.ts"
}

bundle.web.js file is the file with React bundle and the entry point to our components’ library from within the web application. Because we have put package.json inside the web directory, if we want to use the Button component in the React web application we will import it like:

/**
* importing from build/bundle.web.js under the hood
*/

import { Button } from 'our-components-library/web'

While in React Native app it will simply be:

import { Button } from 'our-components-library'

Except from src and web directories, in the project root we also defined three files:

package.json as the main configuration file of the whole library, containing dependencies, scripts, entry point for React Native etc.
tsconfig.json with definitions of typescript rules we use in the app
webpack.config.js with settings for bundling the code for web usage.

We will now take a closer look at the last file as bundling for the web is one of the focal points of the whole process of creating sharable components.

Bundling React Native for web

To bundle the code I will use the most common solution by far – Webpack. In order to use it we first need to install a couple of modules. Depending on preference you could use Yarn or NPM, I will use Yarn in the examples. We install to dev dependencies using command:

yarn add --dev webpack webpack-cli

Because we have installed the webpack-cli package, we can now use the webpack command to bundle our code. Let’s do it and also let’s add a script to package.json and name it accordingly so other developers can easily identify the purpose of it.

package.json:

"scripts": {
   "build-react": "webpack"
 }

Now, the most important part of the bundling process – we need to define configuration file, so the Webpack knows how to translate our React Native code into a React bundle. Let’s first take a look at the whole config and go through it section-by-section later.

webpack.config.js:

const path = require("path");

module.exports = {
 entry: path.join(__dirname, "src/index.ts"),
 output: {
   filename: "bundle.web.js",
   path: path.join(__dirname, "/web/build"),
   library: "our-components-library",
   libraryTarget: "umd",
   umdNamedDefine: true,
 },
 module: {
   rules: [
     {
       test: /\.(ts|tsx)?$/,
       include: path.resolve(__dirname, "src"),
       exclude: /node_modules/,
       use: [
         {
           loader: "babel-loader",
           options: {
             cacheDirectory: true,
             presets: ["module:metro-react-native-babel-preset"],
             plugins: ["react-native-web"],
           },
         },
         {
           loader: "awesome-typescript-loader",
           options: {
             configFileName: "tsconfig.json",
           },
         },
       ],
     },
     {
       test: /\.(gif|jpe?g|png|svg)$/,
       use: {
         loader: "url-loader",
         options: {
           name: "[name].[ext]",
           esModule: false,
         },
       },
     },
   ],
 },
 resolve: {
   extensions: [".ts", ".tsx", ".js", ".jsx"],
   alias: {
     "react-native$": "react-native-web",
   },
 },
 externals: {
   react: {
     commonjs: "react",
     commonjs2: "react",
     amd: "React",
     root: "React",
   },
   "react-dom": {
     commonjs: "react-dom",
     commonjs2: "react-dom",
     amd: "ReactDOM",
     root: "ReactDOM",
   },
 },
};

First thing we need to define for Webpack is the input file. This is where we export all the components in our library, for example:

src/index.ts:

import Button from "./components/Button";

export { Button };

In the next section, we define what should be the result of the bundling process:

output: {
   filename: "bundle.web.js",
   path: path.join(__dirname, "/web/build"),
   library: "our-components-library",
   libraryTarget: "umd",
   umdNamedDefine: true,
 },

Filename and path are self–explanatory, but it’s worth remembering that the path to the final bundle and its name must be the same as what’s defined in web/package.json, otherwise we won’t be able to import components of the library correctly as they won’t be found. Setting library name and libraryTarget to “umd” and umdNamedDefine allows us to import components from the library individually.

In the module section one needs to define all the loaders used to build particular file types. While awesome-typescript-loader and url-loader probably sound familiar as they are often used with React applications, I’d like to focus on configuration for babel-loader. Two settings are worth mentioning here – we need to use metro-react-native-babel-presets to obtain Babel presets for our React Native components, and we also add react-native-web Babel plugin. The plugin basically rewrites paths to import only the modules needed by the app. That allows us to vastly reduce the size of the result bundle.

Size concern is also the purpose for externals part of the config:

react: {
     commonjs: "react",
     commonjs2: "react",
     amd: "React",
     root: "React",
   },
   "react-dom": {
     commonjs: "react-dom",
     commonjs2: "react-dom",
     amd: "ReactDOM",
     root: "ReactDOM",
   },
 },

Thanks to this configuration, libraries mentioned are not bundled into the final file. Without it, we could have the whole React framework bundled and passed between packages. Because React and ReactDOM have to be installed in the parent project of our components library anyway, it wouldn’t make any sense to have it in the bundle.

Finally, we instruct webpack to use React Native Web library whenever we import something from react-native. This is obtained with alias configuration:

resolve: {
   extensions: [".ts", ".tsx", ".js", ".jsx"],
   alias: {
     "react-native$": "react-native-web",
   },
 },

Full list of React Native modules supported by React Native Web is available in it’s documentation.

After running the build-react script, we obtain a nicely compressed bundle of about 80kB. Thanks to web/package.json configuration, it is enough to import from the bundle like described before:

import { Button } from 'our-components-library/web'

Summary

Module bundlers allow us to develop React Native Web and React Native component libraries that can be shared across web and native mobile applications. In the example presented, we used the webpack bundler, but could have used an alternative such as rollup.

It’s also worth noting the way presented above is still a bit complex because it requires a lot of manual setup. A vast effort has been recently put into development of React Native and React Native Web libraries, together with an awesome React Native dev environment called Expo, which makes building React Native apps even simpler. Taking that into account, we can expect even more examples of cross-platform development in the upcoming years.