Developer docs

MCP server

Loclint hosts an MCP (Model Context Protocol) server, so its checks show up as tools inside your client. Connect it once, and Claude Code, Cursor, Claude Desktop, or your own agent can translate and check game strings without leaving the task — before a commit, during review, or while you're writing new UI text.

Endpoint

https://api.loclint.com/mcp

Add to Claude Code

claude mcp add --transport http loclint https://api.loclint.com/mcp

Add to other MCP clients (Cursor, Claude Desktop)

{
  "mcpServers": {
    "loclint": {
      "url": "https://api.loclint.com/mcp"
    }
  }
}

The first call opens Loclint's sign-in page in your browser (OAuth 2.1). There are no API keys to create, store, or rotate.

qa_check runs on the rule engine alone — nothing you check with it reaches any external AI. translate_and_check is the one tool that calls out (to the OpenAI API); the full data path is at the bottom of this page.

MCP tools

• qa_check

  Checks source/target pairs you already have, using the deterministic rule engine only: missing or broken placeholders, markup and tag mismatches, empty translations, source text left untranslated, duplicate keys. No AI is involved — your text never leaves Loclint's infrastructure. Up to 200 pairs per call.

• translate_and_check

  Writing new strings? This translates them with AI (English → Japanese by default; pass sourceLanguage / targetLanguage for other pairs), then runs every translated line through the same rule engine before it comes back — so a broken placeholder never reaches your commit. Up to 50 entries per call. Strings go to the OpenAI API — never used for training, deleted within 30 days.

MCP calls don't currently count against your monthly checked-entry allowance — that applies to file checks in the web app.

What comes back

{
  "checkedEntries": 2,
  "issueCount": 1,
  "issues": [
    {
      "key": "quest_reward",
      "category": "PLACEHOLDER_MISMATCH",
      "severity": "CRITICAL",
      "title": "Placeholder mismatch",
      "explanation": "Placeholders differ between source and target (missing in target: {count}). This can break variable substitution at runtime."
    }
  ]
}

A real qa_check response: two entries checked, one missing placeholder caught.

Checking a release build

1. 1Upload the updated CSV or JSON to your project — one project per title and language pair. Encoding and placeholder format ({curly}, {{double}}, %s, printf) are auto-detected.
2. 2Run the check. Issues come back grouped by category and severity, each with a suggested fix.
3. 3See what changed since last time — the diff against the previous check of the same file: what's new, what's fixed, and what came back.
4. 4Download the fix-list CSV — only the rows with issues, each with its suggested fix — send it to your translator, then re-upload and re-run.

GitHub integration — a check on every push — is on the way. Until it ships, automate pre-commit checks through the MCP server: have your agent run qa_check on the strings you touched.

There's no public REST API yet — the MCP server is the integration surface today.

Where your text goes

qa_check and rules-only checks run entirely on Loclint's infrastructure — no external AI sees your text. translate_and_check and AI review send strings to the OpenAI API, where they're never used for training and are deleted within 30 days. AI review is a per-run toggle, so an unannounced title can stay on rules-only checks until launch.

The complete data path — storage, retention, and deletion — is on the security page.