Hebrew translation that keeps prices, names and dates exact, RTL display, nikud, clinical Hebrew.
Scored across 16 tools
The tools are mostly distinct: translation, batch translation, clinical translation, clinical query, clinical verify, terms management, nikud, direction analysis, wrapping, detection, transliteration, and health checks each target a clear task. The only mild ambiguity is between `translate` with a clinical domain and `clinical_translate`, but their descriptions and the cross-reference in `translate` resolve the boundary.
The vast majority of names follow a clear verb_noun pattern such as add_terms, strip_nikud, detect_language, list_terms, and wrap_for_display, and all names are lowercase snake_case with `clinical_` used consistently as a domain prefix. Minor deviations are `health` as a bare noun and `clinical_query`, which reads more like a noun phrase than a verb action, but the overall pattern is predictable.
Sixteen tools is just above the ideal 3-15 range, but the count is justified by the broad Hebrew-processing surface: core translation, batch/clinical variants, term management, nikud, direction/display, language detection, transliteration, and health. Each tool earns its place and none feels redundant.
The tool surface covers the domain thoroughly: full CRUD for protected terms, single/batch/clinical translation paths, clinical query and verification, nikud add/strip, direction analysis and display wrapping, language detection and discovery, transliteration, and health. There are no dead-end workflows or obvious missing operations for the stated Hebrew language processing scope.
Add full nikud (vowel points) to Hebrew text, for learners, vocalized display and text-to-speech, where unvocalized Hebrew is ambiguous. English terms and numbers pass through unchanged. The result is verified: verified: true means removing the points gives back the input; when false, nikud is the input unchanged. Up to 10,000 characters. Uses the monthly character quota.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Hebrew text to vocalize, up to 10,000 characters. English terms and numbers pass through. |
| Name | Required | Description |
|---|---|---|
| text | No | The input. |
| nikud | No | The vocalized text, or the input unchanged when `verified` is false. |
| verified | No | True when removing the points gives back exactly the input. When false, `nikud` is the input unchanged: send it to speech unvocalized or retry. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the sparse annotations. It discloses that English terms and numbers pass through unchanged, explains the verification semantics ('verified: true' vs fallback to unchanged input), states the 10,000 character limit, and notes the monthly quota. This is rich, non-obvious behavioral context that an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, pass-through behavior, verification semantics, limits, and quota. It is front-loaded with the core action and use cases, then moves to details an agent needs for correct invocation and result interpretation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers input constraints, behavioral edge cases, output verification, and usage context. Nothing essential is missing for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema description already documents the max length and English/number pass-through behavior. The tool description repeats this but adds no meaningful new parameter semantics beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Add full nikud (vowel points) to Hebrew text'. The purpose is elaborated with concrete use cases (learners, vocalized display, text-to-speech) and the motivation (unvocalized Hebrew is ambiguous), making it clear what the tool does and why it exists. The sibling strip_nikud is implicitly distinct as the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use the tool: for learners, vocalized display, and text-to-speech, or when unvocalized Hebrew is ambiguous. It does not explicitly name alternatives or exclusion cases, but the use-case framing is sufficiently clear for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add protected terms to the account, or update existing ones (matched by exact term text). Every later protected translation on the account (translate, translate_batch and the clinical tools) keeps these terms exactly as written, or uses translations.he / .en / .ru for that target language when set. Sending a term that already exists replaces its translations and note. Up to 2,000 terms per account, each up to 200 characters. Changes apply to new requests within 30 seconds. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| terms | Yes |
| Name | Required | Description |
|---|---|---|
| count | No | |
| terms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations: it discloses that existing terms are matched by exact text and replaced, that terms are protected in later translations, that changes take up to 30 seconds to apply, and that there are account-wide limits. The destructiveHint=true annotation is fully supported rather than contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The five sentences are dense but each adds meaningful information: the upsert behavior, the protected-term effect, replacement semantics, limits, and propagation latency. The core purpose is front-loaded and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an add/update tool with an output schema, the description covers what an agent needs: how terms behave downstream, how updates happen, constraints (2,000 terms, 200 characters), and eventual consistency. No significant selection or invocation information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must carry the semantic load. It explains that terms are matched by exact text, that translations.he/.en/.ru are used for the target language when set, and that sending an existing term replaces its translations and note. This is strong compensation, though it does not describe the note field's exact purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Add protected terms to the account, or update existing ones (matched by exact term text).' This clearly separates it from the sibling delete_term and list_terms tools and explains that it is an upsert rather than a simple append.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states exactly when to call it: to add or update protected account terms, with updates triggered by exact term text. It does not explicitly name alternative tools for deletion or listing, but the context is clear enough that an agent can route to add_terms correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the right-to-left / left-to-right structure of mixed Hebrew text: base direction, whether it mixes directions, dominant language and script, and the runs to render, where every left-to-right unit (a Latin term, a price, a range such as 10–20%, a date, a model number) stays whole. Send one text, or fields (a map of name → string, up to 100) to analyze a whole record at once. base: auto (default), ltr or rtl. Deterministic and free: no model, no character quota.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Paragraph direction to resolve against. `auto` (default) uses the first strong letter. | auto |
| text | No | A single string, up to 20,000 characters. Send this or `fields`. | |
| fields | No | A map of field name → string, up to 100 fields and 20,000 characters in total. Send this or `text`. |
| Name | Required | Description |
|---|---|---|
| fields | No | Present when the request sent `fields`: one analysis per field name. |
| analysis | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond those: it is deterministic, free, has no character quota, and preserves left-to-right units whole during run generation. This provides useful expectations for an agent without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the core purpose and outputs, the second gives invocation instructions and the `base` options, and the third adds the determinism/quota guarantee. No fluff or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema is present, the description need not explain return values. It adequately covers the tool's purpose, input alternatives, constraints (20k chars, 100 fields), and the `base` enum behavior. An agent can determine whether and how to call this tool correctly with the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds value by explaining the intended use of `text` versus `fields` ('analyze a whole record at once') and by defining the run-splitting rule with concrete examples (Latin term, price, range, date, model number). This enriches the parameters beyond the schema's basic definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Resolve') and resource ('the right-to-left / left-to-right structure of mixed Hebrew text') and enumerates the concrete outputs: base direction, mix status, dominant language/script, and render runs. This clearly distinguishes it from siblings like detect_language or transliterate, which target different aspects of text processing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to invoke the tool — sending either a single `text` or a `fields` map, and choosing `base` — but it does not explicitly state when to prefer this tool over siblings (e.g., when not to use detect_language). The 'Deterministic and free' note hints at selection criteria but leaves the comparison to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a Hebrew clinical question (up to 2,000 characters) into an English query for a record search or an English model. English terms, numbers and dates are kept exactly, and Hebrew spellings of drug names are mapped back to English, preferring the patient's own terms in known_terms and the account terms. Needs a key with Clinical access (the medical scope). Uses the monthly character quota.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The Hebrew question, up to 2,000 characters. | |
| glossary | No | English term → Hebrew rendering, used to map the Hebrew back to English. | |
| known_terms | No | English terms from the patient's record, used to map Hebrew spellings back. Up to 500. Account terms are added automatically. |
| Name | Required | Description |
|---|---|---|
| query | No | English query for your record search. |
| terms | No | Hebrew spellings that were mapped back to English terms. |
| usage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavior beyond the annotations: it requires a key with Clinical access, consumes monthly character quota, preserves English terms/numbers/dates exactly, and maps Hebrew drug spellings back to English while preferring known_terms and account terms. These details are valuable and non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. It front-loads the core task, then adds the most important operational details: faithfulness of the conversion, parameter preferences, and access/quota constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the parameter schema is rich, the description completes the picture by covering auth requirements, quota impact, and transformation rules. No critical operational detail needed to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents text, glossary, and known_terms individually. The description adds value by explaining the mapping preference and how glossary/known_terms fit into the overall behavior, going slightly beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Turn') and the specific resource: a Hebrew clinical question becomes an English query for record search or an English model. This distinguishes it from generic translation siblings by focusing on query generation rather than general text translation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives useful context about when to use it ('for a record search or an English model') and mentions the prerequisite clinical access key and quota. It does not explicitly name alternatives like clinical_translate or translate, so the agent must infer the distinction from the purpose rather than from explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate a complete English clinical text (a discharge summary, patient instructions, a visit note, a model's answer) into Israeli medical Hebrew for a clinician or a patient. Drug names, doses, lab values, units, ICD-10 codes, clinical abbreviations, identifiers and every number are kept exactly; every sentence is checked for numbers, negation and laterality and reviewed for meaning. A sentence that fails is retried, then returned in English with status fallback: unverified Hebrew is never returned. Treat fallback sentences as untranslated.
audience: clinician (default, keeps BID/PO shorthand) or patient (plain words). Pass the patient's medication and problem lists as protected_terms, names as redact_terms (hidden from the model), reader_gender and patient_gender when known, and date_order (US records are MDY). Needs a key with Clinical access (the medical scope). Uses the monthly character quota.
| Name | Required | Description | Default |
|---|---|---|---|
| bidi | No | `isolate` wraps English values in Unicode isolates so "5 mg" never renders as "mg 5". `none` returns plain text. | isolate |
| text | Yes | English text, 1 to 20,000 characters. Markdown lists, headings and tables keep their structure. Counts toward the monthly character quota. | |
| audience | No | Who reads the Hebrew. `clinician` (default) keeps shorthand such as BID and PO; `patient` writes dosing shorthand (BID, PRN) as plain words. | clinician |
| glossary | No | English term → required Hebrew rendering. Up to 500 entries. | |
| date_order | No | How to read ambiguous numeric dates in the source. US records are MDY. | MDY |
| date_style | No | `hebrew` writes "4 במרץ 2026"; `iso` writes 2026-03-04; `keep` leaves unambiguous dates as written (an ambiguous one is still rewritten). A two-digit year is kept as written. | hebrew |
| redact_terms | No | Kept verbatim and never shown to the model (patient and staff names). Up to 200. | |
| reader_gender | No | Gender of the reader, the person the text calls "you". Omit when unknown. | |
| patient_gender | No | Gender of the patient in third-person references. Inferred from he/she when omitted. | |
| protected_terms | No | Kept verbatim. Pass the patient's medication and problem lists from the record. Up to 500, each up to 200 characters. Added to the account terms list for this request. |
| Name | Required | Description |
|---|---|---|
| id | No | Request identifier. |
| text | No | The whole Hebrew document: every segment joined with its prefix and suffix. |
| stats | No | |
| usage | No | |
| segments | No | One entry per sentence, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the exact preservation rules for drug names, doses, lab values, and numbers, as well as the retry-and-fallback behavior with the `fallback` status. It also explains that unverified Hebrew is never returned and warns the agent to treat fallback sentences as untranslated, which is critical operational knowledge.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place, front-loading the core behavior before moving to parameter guidance. It avoids fluff and organizes information into clear, scannable sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers authentication requirements, quota implications, fallback semantics, audience-specific behavior, and how to handle sensitive terms. With an output schema available, the description does not need to explain return values, and nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaningful guidance by explaining how to populate protected_terms from the patient's medication and problem lists, why redact_terms should contain names, and when to pass reader_gender, patient_gender, and date_order. This contextual advice helps an agent make better parameter choices than the schema alone would.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Translate'), a precise resource ('complete English clinical text') and the target output ('Israeli medical Hebrew'), with concrete examples of accepted inputs. It clearly differentiates itself from the generic sibling 'translate' by emphasizing clinical verification and the fallback behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context about when to use the tool and how to configure it for the audience, protected_terms, redact_terms, and date_order. It does not explicitly name alternative tools or state when not to use it, but the clinical-specific framing makes the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Hebrew that was produced some other way (for example by your own model) against its English clinical source: every drug, dose, lab value, code and number must appear exactly, no number may be added, dates must be unambiguous, and negation and laterality must survive. verification: "strict" adds an independent model review for meaning changes; standard (default) is deterministic. Returns pass or fail with every issue. Needs a key with Clinical access (the medical scope). Uses the monthly character quota.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | The English source, up to 20,000 characters. | |
| glossary | No | English term → required Hebrew rendering. | |
| date_order | No | How to read ambiguous numeric dates in the source. | MDY |
| translation | Yes | The Hebrew to check, up to 40,000 characters. | |
| redact_terms | No | Names replaced before the reviewer sees the text. Up to 200. | |
| verification | No | `standard` (default) runs the deterministic checks. `strict` adds an independent model review for meaning changes. | standard |
| protected_terms | No | Terms that must appear verbatim. Up to 500. |
| Name | Required | Description |
|---|---|---|
| pass | No | True when no issue has severity `error`. |
| usage | No | |
| issues | No | Every problem found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the basic annotations, the description discloses meaningful behavioral details: standard mode is deterministic, strict mode adds an independent model review, it returns pass/fail with every issue, it requires a Clinical-access key, and it consumes the monthly character quota. This is exactly the kind of auth, quota, and mode behavior an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: it front-loads the core operation, then covers modes, output, and access constraints in a logical order. Every sentence carries useful information, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with full schema coverage and an output schema, the description covers the essential non-schema context: operation, verification modes, return behavior, authentication, and quota. The schema handles parameter details, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does restate the verification-mode distinction already present in the schema but adds no new parameter-level meaning beyond that. Thus it neither penalizes nor elevates the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check') and resource ('Hebrew ... against its English clinical source'), and enumerates exactly what is checked (drugs, doses, lab values, dates, negation, laterality). This clearly differentiates clinical_verify from translation siblings like clinical_translate or translate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by saying the Hebrew 'was produced some other way (for example by your own model)', which implies this is a post-generation verification tool rather than a translation tool. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of the strongest guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete one account term by its id (from list_terms or add_terms). Protected translations stop using it within 30 seconds. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The term id, from list_terms or add_terms. |
| Name | Required | Description |
|---|---|---|
| deleted | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool destructive and idempotent. The description adds genuinely useful behavioral context: deletion is permanent, and protected translations stop referencing the term within 30 seconds. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no redundant filler. The main action is front-loaded, the source of the id is included, and the 30-second propagation detail is valuable and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter delete operation with an output schema and clear annotations, this description is complete. It explains permanence, source of the id, the effect on protected translations, and cost, leaving no critical ambiguity for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the only parameter, including its type and source. The description repeats the 'from list_terms or add_terms' guidance but does not add meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Permanently delete') on a specific resource ('one account term') and identifies how to get the id. It clearly differentiates from sibling tools like list_terms and add_terms by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when a specific account term must be deleted, with the id sourced from list_terms or add_terms. It does not explicitly name alternatives not to use, but the deletion purpose is unambiguous given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect the dominant language, script and direction of a string, with one segment per language. Built for short, code-switched input (chat messages, search queries, voice transcripts): a brand or acronym such as "PayPal" or "API" inside a Hebrew or Russian sentence does not change the dominant language. Use it to pick source_lang or the reply language before translating. Latin script is tagged en. Deterministic and free: no character quota.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to classify, up to 20,000 characters. Built for short, code-switched input. |
| Name | Required | Description |
|---|---|---|
| dir | No | Base direction of the dominant language. |
| lang | No | Dominant language (BCP 47). Latin script is tagged `en`. |
| script | No | Dominant ISO 15924 script. |
| segments | No | Same-script stretches in order, e.g. ru · en ("CBC") · ru. Latin script is tagged en. |
| languages | No | Every language found, largest share first. |
| confidence | No | Share of letters in the dominant language, 0 to 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds valuable behavioral detail: brand/acronym tokens do not shift dominant language, Latin script is tagged as 'en', results are deterministic, and there is no character quota. This gives the agent useful expectations about the tool's behavior without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense: purpose first, then use case, language-tagging behavior, and operational guarantees. Every sentence contributes to correct selection and invocation, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with an output schema, the description covers what the tool does, how to use it in a workflow, what to expect (segments, en tagging, code-switching tolerance), and its operational characteristics. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is only one parameter, text, whose purpose and max length are already documented in the schema. The description reinforces that the input is short and code-switched, but adds no new parameter syntax or format information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: detect the dominant language, script, and direction of a string, with one segment per language. This clearly distinguishes it from siblings like translate, transliterate, analyze_direction, and add_nikud, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance to use the tool to pick source_lang or the reply language before translating, and explains it is built for short, code-switched input. It does not explicitly describe when not to use it or mention alternative tools by name, so it stops just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that the HebrewCore API is up and its database reachable. Needs no API key and uses no quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| db | No | `ok`, or `error` when the database check failed. |
| status | No | `ok` when the API is serving. |
| version | No | API version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's added value is the no-key/no-quota detail, which is beyond annotations. It also clarifies that the database reachability is part of the check. No contradictions. It doesn't describe the return format, but the output schema covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. The purpose is front-loaded, and the auth/quota caveat is stated directly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent tool with an output schema, the description is complete. It covers the operation's scope, auth requirements, and quota usage. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (trivially), so the description has no parameter burden. Baseline is 4 for zero-param tools. The description correctly omits parameter details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks API and database health, which is a specific verb+resource. It's distinct from all sibling tools (translation, term management, etc.), so an agent can immediately identify it as the health check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: it's a lightweight check that requires no API key and no quota, suggesting it can be used freely. It doesn't explicitly name alternatives or exclude other tools, but the context is clear enough for an agent to infer it's for verifying service availability before other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every language HebrewCore translates to and from, with its code (use it as source_lang / target_lang), English and native name, and writing direction. Protected translation covers Hebrew, English and Russian. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| languages | No | Every supported language. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: that the call is 'Free', that protected translation covers Hebrew, English and Russian, and what fields are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences that front-load the core operation, then list the returned fields and relevant constraints. No filler or repetition of the schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with an output schema and safety annotations, the description fully covers what the tool does, what it returns, and how the output is meant to be used. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, there is nothing for the description to document. It still clarifies how the returned language codes relate to tool parameters, which is a helpful semantic addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource: 'List every language HebrewCore translates to and from.' It specifies the exact fields returned (code, English and native name, writing direction), which clearly defines the tool's purpose and distinguishes it from translation and detection siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical usage guidance by noting the code can be used as `source_lang` / `target_lang`, which tells the agent how the output feeds into other tools. It does not explicitly exclude alternatives, but the tool is a unique listing operation and no sibling competes with it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's protected terms: drug, product and brand names that every protected translation on the account keeps exactly as written (or renders with the term's per-language translation when one is set). Returns each term's id, which delete_term needs. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| limit | No | |
| terms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds meaning beyond those annotations by defining what 'protected terms' are)Skip? and by noting the per-language translation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, starts with the core action and resource, and packs the important distinguishing details (what the terms are, id output, relationship to delete_term, cost) without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, a rich annotation set, and an output schema present, this description covers everything an agent needs to decide whether to call the tool. It explains the returned content and even notes why the id matters, making it fully sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool takes zero parametersabbvie, so the schema is trivially complete and there is nothing for the description to explain about parameter syntax. The baseline of 4 applies because no parameter documentation burden exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'List' and names the resource ('the account's protected terms'), then elaborates what those terms are and which ids are returned. It also explicitly connects the output to delete_term, which helps an agent distinguish this listing tool from its sibling mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this is a read-only listing operation and says 'Returns each term's id, which delete_term needs', giving a concrete reason to invoke it. It does not explicitly exclude alternatives or spell out when not to use it, but for a zero-parameter listing tool the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove nikud, dagesh and cantillation marks from Hebrew text, keeping punctuation such as the maqaf. Use it to normalize text for search keys, comparison and de-duplication, or to get display text back from vocalized text. Deterministic and free: no character quota.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Hebrew text with nikud or cantillation, up to 20,000 characters. |
| Name | Required | Description |
|---|---|---|
| text | No | The input. |
| stripped | No | The text without nikud, dagesh or cantillation. Punctuation such as the maqaf is kept. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, and the description adds useful behavioral context: it is deterministic, has no character quota, and preserves punctuation such as the maqaf. This goes beyond the structured data without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the action is front-loaded, use cases follow, and the operational note about determinism and character quota is concise. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter, read-only, idempotent transformation tool. The description covers what it does, when to use it, and key behavioral traits, while the output schema can provide return details. There is no meaningful gap for safe selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'text' parameter already has a clear description, length limits, and an example. The tool description adds broader purpose but not much parameter-specific detail, so the schema carries the load and the description neither hurts nor substantially improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Remove nikud, dagesh and cantillation marks') and a clear resource ('Hebrew text'), then clarifies that punctuation like the maqaf is retained. This distinguishes it from the sibling add_nikud and makes the tool's exact scope obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases: normalize text for search keys, comparison, de-duplication, or retrieving display text from vocalized text. It does not explicitly name alternatives or state when not to use it, but the contexts are specific enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| bidi | No | `isolate` wraps protected values in Unicode isolates in Hebrew output. Default none; see /v1/wrap. | |
| text | Yes | Text to translate, 1 to 20,000 characters. Counts toward the monthly character quota. | |
| domain | No | `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`. | |
| gender | No | Grammatical gender for the reader where the target language marks it. For assistants, prefer `listener_gender` and `speaker_gender`. | |
| protect | No | Keep 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. | |
| quality | No | `fast`: lowest latency, for high volume and short strings. `balanced`: the default. `smartest`: maximum nuance for long or sensitive text. | balanced |
| audience | No | Clinical domain register. `clinician` (default) keeps shorthand such as BID and PO; `patient` writes it as plain words. | |
| glossary | No | Source term → required rendering in the target language. Up to 500 entries. Wins over an account term with the same text. | |
| date_order | No | How to read ambiguous numeric dates such as 04/03/2026. Default MDY for English sources, DMY for Hebrew and Russian. | |
| date_style | No | `hebrew` (default) spells the month out in the target language ("4 במרץ 2026", "4 марта 2026 г."); `iso`; `keep` (unambiguous dates only). | |
| source_lang | No | BCP 47 source language, or `auto` (default) to detect it. | |
| target_lang | Yes | BCP 47 target language, e.g. `he`, `en`, `ru`. See GET /v1/languages. | |
| redact_terms | No | Kept exactly and never shown to the model: customer names and other personal data. Up to 200. | |
| transliterate | No | Include a Latin transliteration when the target is Hebrew. | |
| message_format | No | `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_gender | No | Clinical domain: gender of a patient referred to in the third person. | |
| speaker_gender | No | Gender of the speaker ("I"), for an assistant or brand voice: מצאתי, я нашла / я нашёл. | |
| listener_gender | No | Gender of the reader ("you"): תרצי / תרצה. Hebrew and Russian mark it; English does not. Without it, Hebrew interface text uses neutral forms. | |
| protected_terms | No | Terms 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. |
| Name | Required | Description |
|---|---|---|
| id | No | Request identifier. Include it when you contact support. |
| usage | No | What this request consumed. |
| source | No | The source text with its directionality metadata. |
| quality | No | Quality tier used. |
| translation | No | The translation with its directionality metadata. |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| bidi | No | `isolate` wraps protected values in Unicode isolates in Hebrew output. Default none; see /v1/wrap. | |
| items | Yes | 1 to 50 strings, each up to 5,000 characters. A protected batch carries at most 20,000 characters in total. | |
| domain | No | `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`. | |
| gender | No | Grammatical gender for the reader where the target language marks it. | |
| protect | No | Keep 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. | |
| quality | No | Quality tier, applied to every item. | balanced |
| audience | No | Clinical domain register. `clinician` (default) keeps shorthand such as BID and PO; `patient` writes it as plain words. | |
| glossary | No | Source term → required rendering in the target language. Up to 500 entries. Wins over an account term with the same text. | |
| date_order | No | How to read ambiguous numeric dates such as 04/03/2026. Default MDY for English sources, DMY for Hebrew and Russian. | |
| date_style | No | `hebrew` (default) spells the month out in the target language ("4 במרץ 2026", "4 марта 2026 г."); `iso`; `keep` (unambiguous dates only). | |
| source_lang | No | BCP 47 source language, or `auto` (default). | |
| target_lang | Yes | BCP 47 target language, applied to every item. | |
| redact_terms | No | Kept exactly and never shown to the model: customer names and other personal data. Up to 200. | |
| transliterate | No | Include a Latin transliteration when the target is Hebrew. | |
| message_format | No | `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_gender | No | Clinical domain: gender of a patient referred to in the third person. | |
| speaker_gender | No | Gender of the speaker ("I"), for an assistant or brand voice: מצאתי, я нашла / я нашёл. | |
| listener_gender | No | Gender of the reader ("you"): תרצי / תרצה. Hebrew and Russian mark it; English does not. Without it, Hebrew interface text uses neutral forms. | |
| protected_terms | No | Terms 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. |
| Name | Required | Description |
|---|---|---|
| usage | No | What this request consumed. |
| results | No | One translation per item, in input order. |
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.
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.
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.
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.
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.
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.
Romanize Hebrew into Latin letters (direction: "he-to-latin", the default), or write Latin spelling in Hebrew letters (direction: "latin-to-he") for name entry and search. Up to 5,000 characters. Uses the monthly character quota.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to transliterate, up to 5,000 characters. | |
| direction | No | `he-to-latin` (default) romanizes Hebrew. `latin-to-he` writes Latin spelling in Hebrew letters, for name entry and search. | he-to-latin |
| Name | Required | Description |
|---|---|---|
| text | No | The input. |
| scheme | No | Romanization scheme used. |
| direction | No | Direction used. |
| transliteration | No | The transliterated text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses two behavioral facts beyond annotations and schema: the 5,000-character limit (restated as operational context despite also being in schema maxLength) and the non-obvious 'Uses the monthly character quota', which is important for an agent deciding whether to call this in a loop or batch. All four annotation hints are false, so the description carries the burden and largely meets it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, roughly 40 words, front-loaded with the core operation and direction semantics before the limits and quota. Every clause carries information; there is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity 2-param tool with complete schema coverage and an output schema present, the description adequately covers direction options, the length limit, and quota cost. The only minor gap is not explicitly routing agents to translate when semantic meaning conversion is intended, but that omission is low-risk given the self-explanatory name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both text and direction are fully documented with defaults, examples, and enums. The description restates the direction semantics and the name-entry/search use case, but adds no parameter detail beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States precise bidirectional behavior: 'Romanize Hebrew into Latin letters' and 'write Latin spelling in Hebrew letters', clearly identifying script conversion rather than language translation. This distinguishes it from the translate sibling and from Hebrew-text utility tools like add_nikud/strip_nikud without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for both directions, explicitly tying latin-to-he to 'name entry and search' and noting the he-to-latin default. However, it never names alternatives or states when not to use it (e.g., that translate is the correct sibling when meaning conversion, not script conversion, is needed), so explicit exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make one mixed Hebrew/English display line render correctly: every left-to-right unit (a Latin term, a price, a number with its unit, a range such as "10–20%", a date, a comparison such as "<5") is kept whole and in order, so nothing is reversed or mirrored inside a Hebrew line. format: html (dir spans, for web and React), isolate (Unicode isolates, for iOS, Android 7+ and browsers) or marks (LRM/RLM, for any renderer including older Android). Pass base: "rtl" for a Hebrew line that starts with a Latin term. Deterministic and free: no character quota.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Paragraph direction of the display surface. Pass `rtl` for a Hebrew line even when it starts with a Latin term. | auto |
| text | Yes | The display line, up to 20,000 characters. | |
| format | No | `html` for the web; `isolate` (Unicode isolates) for modern text engines; `marks` (LRM/RLM) for every renderer, including older Android. | html |
| Name | Required | Description |
|---|---|---|
| dir | No | Paragraph direction used. |
| runs | No | The display runs the output was built from. |
| format | No | Format used. |
| output | No | Render-ready text: HTML with `dir` spans, or the text with Unicode isolates or direction marks inserted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/idempotent annotations by disclosing that the operation is deterministic, free, and has no character quota, and by explaining the output mechanisms (dir spans, Unicode isolates, LRM/RLM marks). It also clarifies the ordering problem it solves, giving agents a concrete model of the transformation. No contradiction exists between the description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense with every sentence earning its place: purpose, format alternatives with renderer guidance, base-direction note, and a determinism/no-quota reassurance. It is front-loaded with the core behavior and avoids repetition of the input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and an output schema, the description covers the essential invocation details: text scope, renderer-specific format behavior, and the rtl base case. The main gap is the meaning of base: 'auto', which is left to the schema default and is not clarified in prose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 genuine value beyond the schema: it explains what the format enum values produce in practical renderer terms and specifies when to pass base: 'rtl' for Hebrew lines that start with a Latin term. It enriches the meaning of text as well by listing example left-to-right units. Auto behavior for base is not explained, which keeps this from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Make one mixed Hebrew/English display line render correctly' and explains the exact transformation: keeping left-to-right units whole and in order so nothing is reversed inside a Hebrew line. This clearly distinguishes it from sibling tools like translate, detect_language, or analyze_direction, which address different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: whenever a mixed Hebrew/English display line needs correct visual ordering. It also provides strong format-selection guidance (html for web, isolate for modern engines, marks for older Android) and tells when to pass base: 'rtl'. It does not explicitly mention exclusions or compare against sibling tools, but those tools are functionally distinct enough that the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_nikudadd_termsanalyze_directionclinical_queryclinical_translateclinical_verifydelete_termdetect_languagehealthlist_languageslist_termsstrip_nikudtranslatetranslate_batchtransliteratewrap_for_displayAccurate, brand-controlled translation for text, code, images, and documents with terminology.
Translation that never breaks structure: .srt timings, i18n key trees, PDF layout.
Real .docx and .xlsx files from structured data, with automatic Hebrew/Arabic RTL.
Add one secure layer between your agents and this server.
