Skip to main content
Glama
ffeldhaus

angular-i18n-mcp

by ffeldhaus

update_translations

Batch update up to 50 Angular i18n translations in an XLIFF file by locale, so multiple string changes apply in one operation.

Instructions

Update multiple translations in a single file (max 50)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
localeYesTarget locale
updatesYesArray of translation updates

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

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.