XC-MCP: XCode CLI wrapper

Overview Schema Source Related Servers Discussions Admin

Audit Localization Catalog

localization-audit

Read-onlyIdempotent

Audits .xcstrings, .strings, and .stringsdict catalogs to find missing translations, placeholder mismatches, and unused or missing keys compared to Swift source code.

Instructions

localization-audit

Audit .xcstrings, .strings, or .stringsdict catalogs for localization gaps, placeholder mismatches, and unused or missing keys relative to Swift source code.

What it does

Pure file analysis — no simulator required. Parses localization catalogs and reports:

Per-locale missing/untranslated keys
Keys with needs_review, new, or stale states
Format-specifier placeholder count mismatches across locales
Keys in Swift source but absent from catalog (missing_from_catalog)
Keys in catalog but absent from Swift source (unused_in_source)

Parameters

catalogPath (string, required): Path to .xcstrings, .strings, or .stringsdict catalog file
sourceDir (string, optional): Swift source root for unused/missing key cross-reference
strict (boolean, optional): Set isError:true in response if any findings are present
verbose (boolean, optional): Include detailed per-key breakdown in summary text

Supported Catalog Formats

.xcstrings: Xcode 15+ JSON catalog with multi-locale support
.strings: Legacy single-locale plist (binary/XML/text format)
.stringsdict: Pluralization rules plist

Returns

JSON response with:

catalogPath, sourceLanguage, totalKeys, locales
gaps: array of { key, locale, reason } objects
missingFromCatalog: keys in Swift source not in catalog
unusedInSource: keys in catalog not referenced in Swift source
placeholderMismatches: keys where placeholder counts differ across locales
summary: compact human-readable summary text

structuredContent: { totalKeys, localeCount, gapCount, placeholderMismatchCount }

Examples

Audit .xcstrings catalog

await localizationAuditTool({
  catalogPath: '/path/to/Localizable.xcstrings'
})

Full audit with source cross-reference

await localizationAuditTool({
  catalogPath: '/path/to/Localizable.xcstrings',
  sourceDir: './MyApp',
  verbose: true
})

Strict mode (error on any findings)

await localizationAuditTool({
  catalogPath: '/path/to/Localizable.xcstrings',
  strict: true
})

Gap Reasons

missing: Key has no translation for that locale
needs_review: Translation exists but marked for review
new: Translation is new and unverified
stale: Translation is outdated relative to source

Placeholder Matching

Extracts printf-style format specifiers (%@, %d, %s, %lld, positional %1$@, etc.) and reports keys where the count differs between source and a target locale. Empty-value locales are skipped (gaps reported separately).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`strict`	No
`verbose`	No
`sourceDir`	No
`catalogPath`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`gapCount`	Yes
`totalKeys`	Yes
`localeCount`	Yes
`placeholderMismatchCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv4.1.0Sep 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive, and the description reinforces this with 'Pure file analysis — no simulator required.' It also adds meaningful behavioral detail such as strict mode setting isError:true and placeholder mismatch handling skipping empty-value locales.

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?

The description is long but well-structured and front-loaded with a one-line summary, followed by sections for behavior, parameters, formats, returns, examples, gap reasons, and placeholder matching. It is somewhat detailed, but most sections earn their place given the complexity of the audit output.

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

Completeness5/5

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

For a 4-parameter tool with sparse schema, the description covers input semantics, supported file formats, output JSON fields, gap reason meanings, placeholder-matching rules, and complete usage examples. This is sufficient for an agent to select and invoke the tool correctly without external documentation.

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

Parameters5/5

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

Schema description coverage is 0%, but the Parameters section documents all four parameters with types, requiredness, and plain-language meaning, such as catalogPath being 'Path to .xcstrings, .strings, or .stringsdict catalog file' and strict setting isError:true when findings are present. The examples further clarify how catalogPath, sourceDir, strict, and verbose are used together.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Audit .xcstrings, .strings, or .stringsdict catalogs for localization gaps, placeholder mismatches, and unused or missing keys relative to Swift source code.' This is precise enough for an agent to distinguish it from unrelated siblings such as accessibility-audit or visual-diff.

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?

The description gives clear context by noting 'Pure file analysis — no simulator required' and enumerating supported catalog formats and example invocations. It does not explicitly name alternatives or when-not-to-use conditions, but no sibling tool provides the same localization-catalog audit function.

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

Deploy Server