Skip to main content
Glama

HebrewCore by baba Hebrew

Translate text

translate

Translate one text between Hebrew, English, Russian and the other languages from list_languages. Use it for product, support, interface, finance, legal and general clinical text. Returns the translation with its direction metadata.

Protected translation: set protect: true, a domain (general, clinical, finance, legal) or any protection field, and prices, quantities, numbers, dates, codes, identifiers, product names, interface variables ({name}, %s) and protected_terms are kept exactly as written, and every sentence is verified; a sentence that cannot be verified comes back in the source language (status fallback) instead of a wrong value. finance also protects IBANs, card and account numbers and checks credit/debit direction; legal keeps clause references, citations and defined terms and checks shall/may modality; clinical protects drugs, doses and lab values.

Gender: listener_gender is the reader ("you"), speaker_gender the speaker ("I", e.g. an assistant). glossary maps source terms to required renderings; redact_terms keeps names exact and hidden from the model. message_format: "icu" translates an ICU MessageFormat string and rewrites plural branches for Hebrew and Russian. quality: fast, balanced (default) or smartest.

Uses the monthly character quota. For many short strings use translate_batch; for full English clinical documents into Hebrew use clinical_translate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bidiNo`isolate` wraps protected values in Unicode isolates in Hebrew output. Default none; see /v1/wrap.
textYesText to translate, 1 to 20,000 characters. Counts toward the monthly character quota.
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. For assistants, prefer `listener_gender` and `speaker_gender`.
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.
qualityNo`fast`: lowest latency, for high volume and short strings. `balanced`: the default. `smartest`: maximum nuance for long or sensitive text.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) to detect it.
target_langYesBCP 47 target language, e.g. `he`, `en`, `ru`. See GET /v1/languages.
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`: the text is an ICU MessageFormat message. The 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
idNoRequest identifier. Include it when you contact support.
usageNoWhat this request consumed.
sourceNoThe source text with its directionality metadata.
qualityNoQuality tier used.
translationNoThe translation with its directionality metadata.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give hints (readOnlyHint=false, etc.); the description adds materially more: monthly character quota, verified sentences fallback to source language with status 'fallback', protection of values, finance/legal/clinical checks, gender handling, and ICU plural rewriting. No contradiction with annotations (translation mutates quota but is not destructive).

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?

Long but appropriately structured and front-loaded with the core purpose before diving into protection, gender, glossary, and quality. Every block carries distinct information; minor redundancy with the schema keeps it from a 5.

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?

With 19 parameters, 2 required, an output schema, and complex domain behavior, the description covers purpose, alternatives, protections, quota, gender, and quality modes. Nothing needed to select or invoke the tool correctly appears to be missing.

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 baseline is 3; the description earns a point above baseline by explaining parameter interactions (domain implies protect, finance/legal/clinical add specific protections, listener_gender vs speaker_gender roles, message_format implies protection). It adds a coherent model rather than only restating the schema.

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 first sentence names a specific verb/resource ('Translate one text') and scope (Hebrew, English, Russian and languages from list_languages), then lists concrete domains. It is easily distinguishable from siblings like translate_batch by the 'one text' phrasing.

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 gives domains to use it for, and ends with routing guidance: 'For many short strings use translate_batch; for full English clinical documents into Hebrew use clinical_translate.' This tells an agent when to choose alternatives.

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.