MCP Server for next-intl internationalization in Next.js
Four well-defined tools with clear naming (verb_noun pattern), comprehensive descriptions (150 - 250 chars each), and explicit Zod schemas with type constraints and parameter descriptions. Tool annotations (readOnlyHint, openWorldHint) are present. However, output schemas are not documented, responses are JSON-stringified but the structure of internalize(), syncLocales(), validateLocaleJson(), and scaffold() results is not formally declared. Error handling is minimal; no recovery guidance or actionable error messages visible in the tool implementations. Parameter descriptions are strong but some lack explicit format/range guidance (e.g., srcDir default 'src' but no validation shown).
Analyzes a Next.js TSX component, detects its type (server/client/shared), extracts all hardcoded strings, and returns the internationalized source code plus a ready-to-paste message JSON for next-intl. Handles JSX text, accessibility attributes (alt, aria-label, placeholder), and generateMetadata strings.
Generates the complete next-intl configuration boilerplate for a Next.js App Router project. Supports two routing modes: • 'locale-prefix' (default) — locale appears in the URL (/en/about). Generates: routing.ts, navigation.ts, request.ts, proxy.ts (Next.js 16+), next.config.ts, app/[locale]/layout.tsx, and message JSON files. • 'none' — locale is NOT in the URL (SPA, admin panels, cookie/header/domain resolution). Generates: request.ts, next.config.ts, app/layout.tsx, message JSON files, and optionally a switchLocale Server Action.
Compares multiple next-intl locale JSON files against a reference locale to detect missing or extra keys. Returns a diff per locale and a suggested patch (minimal JSON with placeholder values) for each locale that is out of sync.
Validates ICU message format syntax inside a next-intl locale JSON file. Checks for unclosed braces, missing plural 'other' category, unclosed rich-text tags, and key naming conventions. Returns errors, warnings, and a stats summary.
Output schemas not documented. Tools return JSON.stringify(result) but the structure of result objects (fields, types, nesting) is not declared. LLMs cannot plan downstream operations or extract specific fields without guessing the response shape.
Error handling absent. No try-catch blocks, validation errors, or recovery guidance visible in tool implementations. If internalize() receives invalid TSX or scaffold() gets mismatched locales/defaultLocale, the error response will not guide the LLM to self-correct.
next_intl_scaffold: localeSource parameter (cookie|header|domain) is only valid when routing='none', but this dependency is not documented in parameter descriptions. LLMs may pass localeSource with routing='locale-prefix', causing silent misuse.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
next_intl_internalize: targetLocales default is ['en'], but description does not explain what happens if a non-English locale is passed without 'en' in the array. Will the output always include 'en' as a fallback, or only the requested locales?
next_intl_sync_locales: locales parameter expects a map of locale code → raw JSON string, but no validation is shown for malformed JSON. If an LLM passes invalid JSON, the error response will not guide recovery.