Skip to main content
Glama
symbionix-sl

airstrings-mcp

Official
by symbionix-sl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

airstrings_strings_set

DestructiveIdempotent

Add or update a single localization string key in the local workspace CSV, overwriting only specified locales while keeping the rest. Optionally push to the active environment; publish to deploy.

Instructions

Add or update one string key in the local workspace CSV (.airstrings//.csv, or .airstrings/strings.csv without a section). Overwrites the given locales of that key and keeps its other locales. Local only unless push=true, which also upserts the key in the active environment; on a protected environment that push is refused and the local change is rolled back. Returns the key, section and whether it was pushed. Use this for a few keys; after editing many keys, run airstrings_push once instead. Apps see the change only after airstrings_publish.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesDot-separated string key, e.g. 'onboarding.welcome'. Created if it does not exist.
pushNoDefault false. When true, also upsert this key in the active environment right after the local write.
formatYes'text' for plain strings or 'icu' for ICU MessageFormat (plurals, select, {placeholders}). Applies to every locale of the key.
valuesYesJSON object string of locale code to text, e.g. {"en": "Hello", "it": "Ciao"}.
sectionNoSection (group of keys) to write to; created on push if missing. Omit for unsectioned strings.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.22.4
    • changedInput schema / properties / format / description
      Previous value: -"String format: 'text' or 'icu'. Required."New value: +"'text' for plain strings or 'icu' for ICU MessageFormat (plurals, select, {placeholders}). Applies to every locale of the key."
    • changedInput schema / properties / key / description
      Previous value: -"The string key (e.g., 'onboarding.welcome')"New value: +"Dot-separated string key, e.g. 'onboarding.welcome'. Created if it does not exist."
    • changedInput schema / properties / push / description
      Previous value: -"Also push this key to the API immediately after the local write."New value: +"Default false. When true, also upsert this key in the active environment right after the local write."
    • changedInput schema / properties / section / description
      Previous value: -"Section name. If omitted, string goes to flat strings.csv"New value: +"Section (group of keys) to write to; created on push if missing. Omit for unsectioned strings."
    • changedInput schema / properties / values / description
      Previous value: -"JSON object of locale=value pairs, e.g. {\"en\": \"Hello\", \"it\": \"Ciao\"}"New value: +"JSON object string of locale code to text, e.g. {\"en\": \"Hello\", \"it\": \"Ciao\"}."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses merge semantics (overwrites given locales, keeps others), that writes are local unless push=true, that a protected environment refuses the push and rolls back the local change, and what is returned. The destructiveHint=true annotation is consistent with 'Overwrites'.

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?

Front-loaded with the core action, then behavior, then routing guidance, with no filler. The long middle sentence packs several clauses but each carries distinct operational information.

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 mutation tool with no output schema, the description covers write scope, push/publish lifecycle, rollback behavior, and the return shape, leaving no material gap for correct invocation.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real value: the CSV path layout, the sectionless fallback file, and section creation on push. These clarify how section and push interact beyond the field-level text.

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?

States a specific verb and resource ('Add or update one string key') and pins the exact target file, distinguishing it from siblings like airstrings_strings_rm and airstrings_push. An agent can select it without opening the schema.

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

Usage Guidelines5/5

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

Explicitly scopes usage ('Use this for a few keys; after editing many keys, run airstrings_push once instead') and notes that apps see changes only after airstrings_publish, naming the relevant alternative tool.

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

Deploy Server

Other Tools