Skip to main content
Glama
Sign In

localize.dev

by io.github.ufortstephen
OverviewDiscussionsAdmin

Read localization settings

config
Read-only

The project's localization settings: source and target languages, where locale files live, the folder scanned, the framework and i18n library, and its glossary (terms kept untranslated, preferred translations per language, tone). Read it before writing UI copy or translations by hand, so new strings follow the same conventions. 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": "config"
  }
}

Input Schema

NameRequiredDescriptionDefault
appNoMonorepo: the app to work in (e.g. apps/web), relative to the repository root. Default: the root.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true; the description adds the crucial data-flow model, that the tool never touches the caller's disk and that the answer's `files` must be written back in full with whole new content — a non-obvious contract for a 'read' tool. The instruction 'write them back unchanged' is slightly muddy about what exactly changes, which keeps it from a 5. Nothing here contradicts readOnlyHint, since the tool itself performs no writes.

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?

Three tight sentences: what is returned, when to read it, and the disk/round-trip contract — the most decision-relevant content is front-loaded. The final clause about writing files back is compressed to the point of ambiguity, costing a point.

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 only two parameters, no output schema, and full schema coverage, the description does the important extra work of describing the return payload (files with paths and whole content) and the no-disk-access model. The one gap is that it never explains why a settings reader returns file bodies, leaving the agent to infer the round-trip purpose.

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%, and the schema already documents both `files` and `app` including which files to include. The description restates the `files` requirement ('Send the files in `files`') and links the input files to the returned files, but adds no new syntax, defaults, or edge-case guidance for either parameter. Baseline 3 applies.

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 enumerates exactly what the tool returns: source/target languages, locale file locations, scanned folder, framework, i18n library, and glossary (kept terms, per-language preferred translations, tone). That is far more specific than the vague name 'config' and its title. It stops just short of a crisp single verb+resource statement and never names a sibling to distinguish itself from.

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

Usage Guidelines4/5

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

'Read it before writing UI copy or translations by hand, so new strings follow the same conventions' gives a clear trigger condition and an implied alternative path (manual authoring vs. the automated localize/translate siblings). There is no explicit when-not guidance or named alternative tool, so it stops at 4.

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