Skip to main content
Glama
Sign In

localize.dev

by io.github.ufortstephen
OverviewDiscussionsAdmin

Localize hardcoded text

localize
Destructive

Extracts hardcoded UI strings into translation keys, rewrites the code to call the i18n library (setting it up when missing), and translates the new messages into every target language. Follows localize.config.json. Needs a localize.dev API key. Send the files in files; nothing is read from or written to your disk. The answer's files are the ones to create or overwrite, each with its whole new content: write them back unchanged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "files": "<files>"
    },
    "name": "localize"
  }
}

Input Schema

NameRequiredDescriptionDefault
appNoMonorepo: the app to work in (e.g. apps/web), relative to the repository root. Default: the root.
dirNoSource folder to scan, relative to the app (default: localize.config.json, else the framework's own).
filesYesThe project files this call needs, with paths relative to the project root: the UI files to work on, package.json, localize.config.json when there is one, and the existing locale files (for example locales/en.json and locales/es.json). Leave out node_modules, build output and binary files.
pathsNoOnly these files or globs, relative to the source folder (e.g. ["components/Cart.tsx"]). Pass the files you just changed, so a run stays quick.
localesNoTarget languages, e.g. ["es","fr"] (default: localize.config.json).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations it discloses the API key prerequisite, the config file dependency, and crucially that nothing is read from or written to the caller's disk — the returned `files` must be written back whole and unchanged. That return contract is valuable context the annotations do not convey. The 'nothing is written to your disk' claim sits in mild tension with destructiveHint=true, but the description resolves it by making the caller responsible for overwriting, so it is not a true contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action is front-loaded in the first sentence, with prerequisites and the return contract following in short, dense sentences. Minor redundancy between 'nothing is read from or written to your disk' and the follow-up instruction about writing `files` back, but nothing is wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, no annotations on return shape, and five parameters, the description carries real weight — and it does explain the response payload, the config dependency, and the API key need. It leaves some gaps typical of a mutation-adjacent tool: no mention of failure modes (invalid key, no i18n setup, oversized payloads) or how existing locale files are merged.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter including `paths`, `locales`, and the nested `files` objects is already documented; the baseline is 3. The description reinforces that input goes in `files` and that returned `files` should be written back unchanged, adding a little meaning to the `paths` hint about keeping runs quick, but no syntax or format details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses concrete verbs — extracts hardcoded UI strings, rewrites the code to call the i18n library, translates into every target language — so an agent knows exactly what the tool produces. It implicitly separates itself from the sibling `translate` by covering extraction and code rewriting, but never names or contrasts siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives operational preconditions ('Follows localize.config.json', 'Needs a localize.dev API key') and a calling hint ('Pass the files you just changed, so a run stays quick'), which shape how to invoke it. It never states when to choose this over `translate`, `check`, or `add_language`, nor any when-not-to-use condition, so guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All localize.dev toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources