Loading ToolBench
Localization as code — CLI and SDK for i1n with MCP server support for translation management
The i1n server provides 9 tools with reasonable naming conventions and generally clear descriptions. All tools follow the pattern of action verbs (i1n_status, i1n_pull, i1n_push, i1n_check, i1n_translate, i1n_add_language, i1n_extract_and_translate, i1n_search, i1n_setup_bridge). Descriptions range from adequate to detailed, averaging ~150-250 characters. Input schemas are present for most tools with appropriate type definitions. However, several critical gaps emerge: (1) output schemas are not documented in the visible code; (2) error handling and recovery guidance is not evident; (3) parameter constraints are often minimal (e.g., no bounds on array sizes despite maxItems declarations); (4) descriptions, while present, lack context about when to use each tool relative to others and do not consistently include recovery hints for errors.
Add new languages to the project and optionally auto-translate existing keys
Validate local translation files offline: missing keys per language, broken interpolation placeholders, empty values, and coverage. Returns a JSON report. Safe for CI — no API calls.
Accept extracted strings, push them to i1n, translate to all active languages, and pull updated types. Pass an array of {key, value, namespace?} objects.
Pull translations from i1n and generate TypeScript types
Push local translation files to i1n (with diff detection, only changed keys are pushed)
Search existing translations by key name, namespace, or source value
Output schemas not documented. LLMs cannot infer the structure of responses (e.g., what fields does i1n_status return? What is the shape of i1n_check's JSON report?). This forces agents to reason about downstream tool inputs without knowing what data will be available.
Error handling and recovery guidance missing. Descriptions do not indicate what errors the tools may return, when they are retryable, or what the LLM should do if a call fails. For example, i1n_push or i1n_translate (write operations) do not document failure modes or recovery steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Detect any i18n library (i18next, vue-i18n, next-intl, react-intl, etc.) and configure i1n bridge mode in this project — end-to-end, with no terminal needed. Use when the user asks to 'set up / configure the bridge', 'wire up i1n with my existing i18n library', or 'install i1n on top of <library>'. If `i1n.config.json` doesn't exist yet, pass `apiKey` (and optionally `projectId`) and the tool runs init non-interactively (validate, pick project, write config) before wiring the bridge. If `apiKey` is missing, the tool returns status `needs_api_key` so you can ask the user for it. If multiple projects exist, it returns status `multiple_projects` with the list — re-call with the chosen `projectId`. Pass `write=true` to actually write the bridge helper file (do this whenever the user asks to *configure*/*install*; only leave it false if they explicitly asked to *analyze* or *preview*). For libraries outside the known list, the tool still emits a best-effort snippet flagged for verification.
Get project status including plan, limits, languages, and configuration
Translate to specified languages with AI. Estimates cost, translates, polls for completion, and auto-pulls results.
Tool disambiguation unclear. i1n_pull, i1n_push, i1n_extract_and_translate, and i1n_search all interact with translations. Descriptions do not clearly explain when to use each vs. the others. For example, when should an agent call i1n_extract_and_translate vs. i1n_push followed by i1n_translate? This forces the LLM to guess at composition.
i1n_setup_bridge has a very long, complex description (>500 chars) with multiple conditional paths (api_key required only if config doesn't exist; projectId required only if multiple projects; write param changes behavior). While detailed, this complexity is hard for LLMs to parse. Consider breaking it into clearer sections or splitting into separate tools for init vs. bridge setup.
Parameter descriptions lack actionable constraints for some tools. For example, i1n_translate's 'languages' parameter accepts a comma-separated string but does not specify valid language codes, expected format (e.g., 'en', 'es-MX'), or what happens if an invalid code is passed. i1n_extract_and_translate's 'strings' array maxItems=5000 is generous but descriptions do not warn about batch limits or performance implications.
Tool composition requires IDs to chain calls, but response schemas are not visible. For example, i1n_search likely returns translations with IDs, but we cannot verify whether those IDs are usable by other tools (e.g., for deletion or update). Broken chaining forces extra lookup calls.