Which integrations are available for this server?

Provides tools for managing Angular internationalization (i18n) using XLIFF formats, including extracting strings, listing translations, and updating translation files via the Angular CLI.

How do I use angular-i18n-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@angular-i18n-mcp list new translations for locale fr" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

angular-i18n-mcp

by ffeldhaus

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Angular i18n MCP Server

This MCP server provides tools to manage Angular internationalization (i18n) using XLIFF 1.2 and 2.0 formats. It integrates with ng-extract-i18n-merge to automate the extraction and merging of translation strings.

Why use this MCP server?

Managing translation files (XLIFF) in Angular projects can be challenging for AI models due to the size and complexity of the XML files. This MCP server solves this by:

LLM-Friendly Interface: Provides concise JSON output for translation units, avoiding the need for AI to parse large XML files.
Accurate Extraction: Leverages the Angular CLI to extract strings directly from source code, ensuring all i18n attributes are captured.
Structured Updates: Automatically handles XML serialization and ensures proper escaping of special characters, maintaining the integrity of your translation files.
Efficient Workflow: Supports listing only new translations and performing bulk updates, making the localization process faster and more reliable.

Related MCP server: xliff-processor

Features

Extract i18n: Runs the Angular CLI command to extract strings and merge them into target locale files.
List New Translations: Identifies units that are newly added and haven't been translated yet (marked with state="initial").
List All Translations: Provides a paginated list of all translation units.
Update Translations: Updates multiple translation units in a single call.
I18N Settings: Retrieves the i18n configuration from angular.json.

Prerequisites

Node.js installed.
An Angular project configured for i18n as described in the Angular i18n Guide.
The project should be configured with ng-extract-i18n-merge:
```
ng add ng-extract-i18n-merge
```
Angular configuration (angular.json) should define the target locales and the translation format (xlf or xlf2).

Configuration

While this is a standard MCP server that works with any MCP-compatible client, the following configuration example is specifically for the Gemini CLI.

The server requires configuration in .gemini/settings.json. You can place this file in either:

Your user home directory: ~/.gemini/settings.json
The project root directory: ./.gemini/settings.json

Add the following to your configuration:

{
  "mcpServers": {
    "angular-i18n": {
      "command": "npx",
      "args": ["-y", "angular-i18n-mcp"],
      "env": {
        "LOCALE_DIR": "src/locale"
      }
    }
  }
}

Environment Variables:

LOCALE_DIR: (Optional) The directory where translation files are stored. Defaults to src/locale.

It is recommended to add src/locale to your .geminiignore file to prevent Gemini from reading large translation files directly or attempting manual updates.

It is strongly recommended to use I18N metadata for translation to provide additional context for translators. This will allow the AI to provide better suggestions and translations.

Tools

`extract_i18n`

Extracts strings from the source code and merges them into the .xlf files.

`get_i18n_settings`

Retrieves the i18n section from angular.json to identify configured locales and source language.

`list_new_translations`

Lists newly added translation units that haven't been translated yet (marked with state="initial").
Arguments:
- locale: The target language code (e.g., de).
- page (optional): Page number for pagination.
- pageSize (optional): Number of units per page.

`list_all_translations`

Lists all translation units in a locale file.
Arguments:
- locale: The target language code.
- page (optional): Page number.
- pageSize (optional): Number of units per page.

`update_translations`

Updates multiple translation units (up to 50) in a single call. Sets the state to translated.
Arguments:
- locale: The target language code.
- updates: An array of objects, each containing id and translation.

Available Tools

5 tools

extract_i18nB

Extract i18n strings and merge into target files using Angular CLI

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a file-writing mutation ('merge into target files') but does not say whether existing content is overwritten, what permissions or project setup are needed, or whether the operation is reversible.

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

Conciseness5/5

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

A single, front-loaded sentence with no wasted words. It states the core action clearly and efficiently.

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

Completeness2/5

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

The tool has no parameters, no output schema, and no annotations, so the description must carry all context. It fails to explain what 'target files' are, how they are determined without parameters, or what the result of the extraction looks like, leaving significant gaps for an agent trying to invoke it correctly.

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

Parameters4/5

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

There are zero parameters, so the baseline is 4. The schema is empty and there is no parameter information to add; the description appropriately does not discuss parameters.

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 names a specific verb ('Extract') and resource ('i18n strings'), and adds the action of merging into target files. It distinguishes itself from siblings like list_all_translations or update_translations by emphasizing extraction and merge, though it does not explicitly name an alternative.

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

Usage Guidelines2/5

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

No guidance is given about when to use this tool versus the sibling tools (e.g., get_i18n_settings, list_new_translations). The mention of 'using Angular CLI' hints at a required context but does not state prerequisites or exclusions.

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

get_i18n_settingsB

Get i18n settings from angular.json

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only operation but does not disclose error behavior, required file presence, or return characteristics.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with zero wasted words. It is appropriately sized for a zero-parameter read tool.

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

Completeness3/5

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

For a simple zero-parameter tool, the description covers the source and purpose. However, with no output schema and no annotations, it does not describe the returned settings or any failure conditions, leaving some gaps.

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

Parameters4/5

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

The tool has zero parameters, which sets the baseline at 4 per the scoring rules. There are no parameter semantics to add 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 states a specific verb ('Get') and resource ('i18n settings'), plus the source location ('from angular.json'). It is clear enough to distinguish from translation-list siblings, but it does not explicitly contrast itself with tools like extract_i18n.

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

Usage Guidelines2/5

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

The description gives no guidance about when to use this tool versus the sibling tools. It does not mention prerequisites, alternatives, or usage context.

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

list_all_translationsC

List all units in the translation file

ParametersJSON Schema

Name	Required	Description
`page`	No
`locale`	Yes	Target locale (e.g., 'de')
`pageSize`	No

TDQS

C2.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It only says 'List all units,' omitting read-only status, pagination behavior, ordering, authentication needs, and return format, which are all relevant for a tool with page and pageSize parameters.

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

Conciseness2/5

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

The description is a single short sentence, but it is under-specified rather than appropriately concise. Given the tool's three parameters and lack of annotations, it does not earn its brevity by covering essential context.

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

Completeness2/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, and incomplete parameter documentation, the description is not complete enough for an agent to invoke the tool confidently. It omits what the translation file is scoped to, how pagination works, and what the results contain.

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

Parameters2/5

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

Schema description coverage is only 33%, so the description should compensate for the undocumented page and pageSize parameters, but it does not. It also adds no meaning beyond the schema for the required locale parameter, leaving parameter usage largely unclear.

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 states a clear verb (List) and resource (units in the translation file), making the core action understandable. However, it does not differentiate this tool from siblings like list_new_translations or extract_i18n, leaving scope ambiguity.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives. Sibling names imply overlapping listing/extraction tools, but the description offers no conditions, exclusions, or prerequisites to guide selection.

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

list_new_translationsC

List new (untranslated) units with state='initial'

ParametersJSON Schema

Name	Required	Description
`page`	No
`locale`	Yes	Target locale (e.g., 'de')
`pageSize`	No

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-only listing operation and a state filter, but omits pagination behavior, permission requirements, what 'untranslated' means operationally, and what the response contains.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no filler. It immediately states the operation and its filtering condition.

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

Completeness2/5

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

For a simple list tool with no output schema and no annotations, the description is too thin. It omits pagination semantics, the required 'locale' parameter, and any comparison to the sibling 'list_all_translations', leaving an agent to infer important context.

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

Parameters2/5

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

Schema description coverage is only 33%, with just the 'locale' parameter documented in the schema. The description does not add any parameter-level meaning for 'page' or 'pageSize', nor does it clarify the required 'locale' beyond the schema description.

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 states a specific verb ('List') and resource ('new (untranslated) units'), with an additional state filter ('state='initial''). It clearly distinguishes itself from a generic list operation, but does not explicitly contrast with its sibling 'list_all_translations'.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus 'list_all_translations' or other siblings. The purpose implies a use case (finding untranslated units), but no explicit exclusions or alternative routing are provided.

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

update_translationsC

Update multiple translations in a single file (max 50)

ParametersJSON Schema

Name	Required	Description	Default
`locale`	Yes	Target locale
`updates`	Yes	Array of translation updates

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. 'Update' implies mutation, but nothing is said about what happens to existing translation text, whether the operation is atomic, whether partial failures are possible, what permissions are required, or whether the changes are reversible. Only the batch-size limit is disclosed.

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?

A single front-loaded sentence with zero filler; the constraint is stated right after the core action. It is efficient, though for a mutation tool this brevity is arguably at the edge of being undersized.

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

Completeness2/5

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

A batch mutation tool with no annotations and no output schema should explain failure semantics, atomicity, and permission requirements. Since neither structured field covers these, the agent has no way to know what a call will actually do beyond writing the supplied text.

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 description coverage is 100%, so the schema already documents locale, updates, id, and translation; the baseline is 3. The description adds only the batch-size constraint on the updates array and the file scope, nothing about id format or locale syntax.

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?

States a specific verb (update) and resource (translations), with the batch scope ('multiple ... in a single file') and a hard cap (max 50). It reads clearly as the write/mutation counterpart to the list_* and extract_* siblings, though it never names any of them.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus the sibling listing tools, and no prerequisites stated (e.g. that the units must already exist or that a file/locale must exist). The max-50 cap is a constraint, not usage guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.3.0Sep 13, 2026
- First observedextract_i18n
- First observedget_i18n_settings
- First observedlist_all_translations
- First observedlist_new_translations
- First observedupdate_translations

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-09-13 05:45 across 5 tools

Disambiguation4/5

Most tools target distinct operations (config read, extraction, update), but list_new_translations and list_all_translations are close cousins that an agent could conflate. Descriptions clarify the difference (state='initial' vs all units), keeping ambiguity low.

Naming Consistency5/5

All names use a consistent snake_case verb_noun pattern (get_i18n_settings, extract_i18n, list_new_translations, list_all_translations, update_translations). The convention is predictable throughout.

Tool Count5/5

Five tools is well-scoped for an Angular i18n workflow, covering config, extraction, listing, and updating without redundancy. Each tool clearly earns its place.

Completeness4/5

The core lifecycle (read settings, extract, list untranslated/all, update) is covered. Minor gaps exist, such as reading a single unit or compiling/validating translations, but these are largely handled by the underlying Angular CLI.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

translate A
io.github.pipeworx-io
Translate MCP — wraps LibreTranslate API (https://libretranslate.com/)
Language Translation AI & Machine Learning App Automation
2
crowdin A
io.usefulapi
MCP server for Crowdin — projects, files, strings, translation progress, tasks, and members.
Language Translation Project Management
122
Translation Services Mcp A
io.github.varvararatta
MCP server for Translation Services
Language Translation AI & Machine Learning
2
main A
dev.lingo
Lingo.dev MCP Server - World-class i18n implementation with ICU MessageFormat.
Developer Tools Language Translation Content Management Systems
42

Related MCP Servers

i1n
Developer Tools Language Translation AI & Machine Learning
Pakvothe
A
license
Not graded
quality
B
maintenance
Localization as code — push, pull, translate, and extract strings from code with AI. 7 MCP tools for type-safe i18n across 182 languages.
Updated 12 days ago (2026-09-09 03:43 UTC)
165 npm
2
MIT
xliff-processor
Language Translation
langlink-localization
A
license
C
quality
C
maintenance
An MCP server for processing XLIFF and TMX translation files, enabling parsing, validation, and manipulation of translation units in localization workflows.
Updated a month ago (2026-08-25 05:39 UTC)
9
2
MIT
@langapi/mcp-server
Language Translation Developer Tools
TedyHub
A
license
A
quality
B
maintenance
MCP server for AI-powered translation management in i18n projects, enabling automated locale detection, translation status checks, and sync via LangAPI.
Updated a month ago (2026-08-21 13:15 UTC)
4
40 npm
1
MIT
i18n-mcp
Language Translation File Systems
robin-heat
A
license
A
quality
B
maintenance
MCP server for managing i18n JSON translation files. Provides Claude with structured read/write access to translation files for adding keys, checking coverage, and finding duplicates.
Updated 21 days ago (2026-08-31 10:39 UTC)
12
14 npm
1
MIT