Skip to main content
Glama

HebrewCore by baba Hebrew

Translate a batch of strings

translate_batch

Translate 1 to 50 strings (each up to 5,000 characters) into one target language in a single call; results come back in input order. Use it for the interface strings of a screen, a string file, or the fields of a product.

Takes every option of translate: protect, domain (general, clinical, finance, legal), protected_terms, glossary, listener_gender, speaker_gender, message_format: "icu" and quality. With protection, interface variables such as {count}, {{name}} and %s, numbers, prices and dates stay exactly as written, and each item carries its own verification status. Uses the monthly character quota.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bidiNo`isolate` wraps protected values in Unicode isolates in Hebrew output. Default none; see /v1/wrap.
itemsYes1 to 50 strings, each up to 5,000 characters. A protected batch carries at most 20,000 characters in total.
domainNo`general` (default) for product, commerce, support and interface text. `clinical` adds clinical register and drug, dose, lab and abbreviation detection. `finance` adds a formal banking register, protects IBANs, SWIFT/BIC codes, bank account numbers (including Israeli bank-branch-account), Israeli ID numbers and card numbers (check digits verified; these values are never shown to the model), invoice, policy and transaction references, signed amounts, rates and basis points, and checks that every money direction (credit/debit, deposit/withdrawal, buy/sell, increase/decrease, gain/loss, who owes whom) is kept. `legal` adds a formal legal register, protects clause and section references (Section 4.2, Clause 7(b), סעיף 12(א), § 3) and case and statute citations, renders each defined term ("the Company") the same way throughout, and checks that modality (shall, may, shall not, is not required to) is kept. Any value implies `protect`.
genderNoGrammatical gender for the reader where the target language marks it.
protectNoKeep prices, quantities, numbers, dates, codes, identifiers, product names, interface variables ({name}, %s) and <keep>…</keep> text exactly as written, and verify every sentence. Implied by any protection field. Hebrew, English and Russian. Account terms switch it on automatically for these pairs.
qualityNoQuality tier, applied to every item.balanced
audienceNoClinical domain register. `clinician` (default) keeps shorthand such as BID and PO; `patient` writes it as plain words.
glossaryNoSource term → required rendering in the target language. Up to 500 entries. Wins over an account term with the same text.
date_orderNoHow to read ambiguous numeric dates such as 04/03/2026. Default MDY for English sources, DMY for Hebrew and Russian.
date_styleNo`hebrew` (default) spells the month out in the target language ("4 במרץ 2026", "4 марта 2026 г."); `iso`; `keep` (unambiguous dates only).
source_langNoBCP 47 source language, or `auto` (default).
target_langYesBCP 47 target language, applied to every item.
redact_termsNoKept exactly and never shown to the model: customer names and other personal data. Up to 200.
transliterateNoInclude a Latin transliteration when the target is Hebrew.
message_formatNo`icu`: every item is an ICU MessageFormat message. Each result is a valid ICU message in the target language: arguments ({name}, {count, number}, {d, date, short}) and `#` are kept, plural and selectordinal branches are rewritten for the target language's CLDR categories (Hebrew one, two, other; Russian one, few, many, other; English one, other; exact matches such as =0 kept), and select keys are kept. A plural or select inside a sentence is moved to the top so every branch is a whole sentence; `protection.segments` lists each branch sentence. Always protected; Hebrew, English and Russian. Invalid ICU returns 400 `invalid_message_format`; a message that cannot be verified comes back unchanged with `protection.status: "fallback"`.
patient_genderNoClinical domain: gender of a patient referred to in the third person.
speaker_genderNoGender of the speaker ("I"), for an assistant or brand voice: מצאתי, я нашла / я нашёл.
listener_genderNoGender of the reader ("you"): תרצי / תרצה. Hebrew and Russian mark it; English does not. Without it, Hebrew interface text uses neutral forms.
protected_termsNoTerms kept exactly as written: product names, brand names, SKUs. Up to 500, each up to 200 characters. Added to the account terms list for this request.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
usageNoWhat this request consumed.
resultsNoOne translation per item, in input order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the sparse annotations, the description discloses meaningful behavioral traits: results are returned in input order, the call consumes the monthly character quota, and each item carries its own verification status under protection. It also describes protection behavior for variables, numbers, prices, and dates.

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 first sentence is front-loaded with the core purpose, limits, and ordering guarantee. The second paragraph is dense but relevant, covering inherited options and behavioral notes; it is slightly redundant with the schema's option list but still well structured.

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?

Given the large schema and existing output schema, the description covers what an agent needs: batch limits, use cases, ordering, quota impact, protection behavior, and verification status. No critical operational context appears missing for selecting and invoking this tool.

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 coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description lists inherited options such as protect, domain, glossary, and quality, but does not add per-parameter meaning beyond what the schema already provides.

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 names a specific verb and resource: 'Translate 1 to 50 strings ... into one target language in a single call.' It adds clear scope constraints, result ordering, and concrete intended use cases, which distinguishes it from the single-string translate sibling.

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?

It explicitly says when to use the tool: 'Use it for the interface strings of a screen, a string file, or the fields of a product.' However, it does not explicitly name alternatives or state when not to use it, such as preferring the single translate tool or clinical_translate for specialized clinical work.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.