MCP server

What an agent can do

An agent with this server connected has six tools. It can look up which languages a project has and how far along each one is, find the key behind a string it can see in the code, read the translation files, check whether a branch is ready to merge, make a branch's key list match the code it just wrote, and fill in values.

Which means the thing that used to interrupt the work no longer does. You ask for a checkout button; the agent writes the component, adds checkout.submit to a branch in Mergua with its English text, writes the German alongside it, and tells you the branch is waiting for review. Nobody opened a second tab, and nothing was pasted between two of them.

Connecting your agent

Two things are the same in every client: the URL below, and an X-API-Key header carrying a project API key. The transport is streamable HTTP. There is nothing to install and no login step — the key is the credential.

The key comes from the project itself: open it, go to API keys, and create one. That tab shows the same configuration block you are about to read, already filled in with the right URL. The key is shown once, when it is created. API keys, and therefore MCP, need a plan with API access — Starter and up, see pricing.

claude mcp add --transport http mergua https://develop.backend.mergua.com/v1/mcp \
  --header "X-API-Key: mergua_your_key_here"

{
  "mcpServers": {
    "mergua": {
      "type": "http",
      "url": "https://develop.backend.mergua.com/v1/mcp",
      "headers": { "X-API-Key": "${MERGUA_API_KEY}" }
    }
  }
}

{
  "mcpServers": {
    "mergua": {
      "url": "https://develop.backend.mergua.com/v1/mcp",
      "headers": { "X-API-Key": "mergua_your_key_here" }
    }
  }
}

[mcp_servers.mergua]
url = "https://develop.backend.mergua.com/v1/mcp"
http_headers = { "X-API-Key" = "mergua_your_key_here" }

Any other client that speaks streamable HTTP and lets you set a header will work; those three are written out because their configuration lives in three different places. Ask your agent to list its tools once it has restarted — six names starting with list_locales means it is connected.

The key names the project

This is the property to know before anything else, because it explains a shape you would otherwise go looking for: no tool takes a project argument. An API key belongs to exactly one Mergua project, and the server reads the project off the key on every request. There is nothing for an agent to guess, and nothing it can address by mistake.

So a second project is a second key and a second entry in your client's configuration — under a different name, say mergua-admin and mergua-web. A repository holding one application usually wants one.

Creating and revoking keys is the project owner's to do; every member of the project can see which keys exist, when each was made and when it was last used. That last-used stamp counts MCP calls too, so a key used only by an agent still reports as busy. Treat the key like any other credential: an environment variable, not a line in a file you commit. If one leaks, revoke it in the same tab — the agent loses access with the next call.

The tools

Six, four of which only read. Your agent picks between them on its own — this table is here so you can tell what it is about to do, and so you can name a tool when you want a particular one.

The two writing tools answer different questions, and mixing them up is the one mistake worth pre-empting. set_translations is a partial write: the keys you send are written over, everything else is left alone, and a key that does not exist yet is created. sync_keys is a manifest — it makes a branch's key list match what you sent, which means a key you leave out is deleted on that branch. That is exactly right after an agent has added and removed keys in the source, and exactly wrong when it only has part of the list.

One shape is worth knowing before an agent writes anything: a locale code the project does not have is added to the project rather than refused, so a typo in a language code creates a language. The tool description says so and tells the agent to take codes from list_locales, which is what makes it rare rather than impossible.

sync_keys refuses the main line and needs a branch, so an agent's key changes arrive as a branch you review rather than in the file everyone is loading. It can open that branch itself as part of the call.

set_translations reports placeholder problems in the same answer — a German string that lost the {count} from the original comes back named, while the agent is still in the turn that wrote it. The values are written either way; the report is there so it can fix the text, not a reason for it to try again. sync_keys carries no such report, and could not: it writes the original rather than a translation of one, so there is nothing to compare against.

get_translations hands over the same files the rest of Mergua does — nested, flat, arb and xliff — so an agent can read a value, check whether a key exists, or write the files straight into your repository. An xliff document holds one language pair, so that format is one locale per call and asking for every locale at once is refused; the tool says so in its own description, which is what keeps an agent from spending a turn finding out. For finding one string, search_keys is the cheaper move: it returns the matching lines instead of the whole file, and it searches the translated text as well as the key names, so the German sentence on screen is enough to get the key back.

Limits

Sized for an agent working rather than for a pipeline, and worth knowing because an agent that hits one of them will tell you the server said no.

None of these is a quota you are meant to work against. They are ceilings on a loop that has gone wrong, and on an answer large enough to fill the context window the agent has to think in afterwards.