Skip to main content
Glama
simplelocalize

SimpleLocalize MCP Server

Official
by simplelocalize
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

create_glossary_entry

Add a glossary term with source text and translations to your SimpleLocalize project. Update existing entries when the source text matches, and set case-sensitive matching or grammatical forms for accurate quality checks.

Instructions

This tool will create a glossary entry in your SimpleLocalize project.

  • Provide 'sourceText' (the term, max 128 characters), 'sourceLanguage', and a non-empty 'targets' array with 'targetLanguage' and 'targetText' for each translation.

  • 'sourceLanguage' and every 'targetLanguage' must be existing language keys in the project - use the 'get_languages' tool first if unsure.

  • If an entry with the same 'sourceText' already exists, its translations are updated instead of creating a duplicate.

  • Optionally set 'caseSensitive' to true for terms whose capitalization matters (product names); quality checks then require exact capitalization.

  • Optionally add 'forms' to a target: alternative forms of the translation (plural, grammatical cases) that quality checks accept as a correct use of the term. Omit 'forms' to keep the ones already stored.

  • Glossary is not available in the Community plan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetsYesTranslations of the term, one entry per target language.
sourceTextYesTerm in the source language (e.g. Sign in).
caseSensitiveNoWhen true, quality checks match the term and its translations exactly as written, including capitalization (useful for product and feature names). Omit to keep the current value of an existing term; defaults to false for a new term.
sourceLanguageYesSource language key, must exist in the project (e.g. en).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.0
    • addedInput schema / properties / caseSensitive
      Added value: +{
+  "description": "When true, quality checks match the term and its translations exactly as written, including capitalization (useful for product and feature names). Omit to keep the current value of an existing term; defaults to false for a new term.",
+  "type": "boolean"
+}
    • addedInput schema / properties / targets / items / properties / forms
      Added value: +{
+  "description": "Alternative forms of the translated term (plural, grammatical cases, e.g. ['Zalogowanie się']) accepted by quality checks and passed to AI translation as inflection hints. Omit to keep the current forms, pass an empty array to clear them.",
+  "items": {
+    "maxLength": 128,
+    "type": "string"
+  },
+  "maxItems": 64,
+  "type": "array"
+}
  2. Addedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important behavioral traits: the upsert behavior for existing sourceText, the semantics of omitting caseSensitive and forms, and the plan limitation. These details are valuable because they affect the outcome of the call. There is no contradiction with the provided annotations.

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 uses five tight bullets with no filler. The most decision-relevant facts—required fields, language key prerequisite, and upsert behavior—are front-loaded. Each sentence adds useful information and aids an agent in correctly invoking the tool.

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 is unusually complete: it lists required fields, max lengths, constraints on language keys, update behavior, defaults, and plan eligibility. The agent has enough information to invoke the tool correctly without needing to inspect the schema in detail. Missing return-value details are not required 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?

The input schema already covers all parameters thoroughly, so the baseline is 3. The description adds practical meaning by explaining why caseSensitive matters for product names, how forms affect quality checks, and what happens when forms are omitted. While it partly restates schema constraints, the additional explanatory context raises it above baseline.

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: 'create a glossary entry in your SimpleLocalize project.' It also clarifies the exact scope by explaining that an existing entry is updated rather than duplicated, which differentiates it from related tools like create_translation_key. This is far from a tautology and clearly tells the agent what the tool does.

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 an explicit prerequisite: use get_languages first when unsure about language keys. It also warns that glossary is unavailable in the Community plan and explains when the tool updates rather than creates. It does not explicitly contrast with alternative glossary tools like delete_glossary_entry, but the conditions for use are clear enough.

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