Skip to main content
Glama
equalang

Equalang

Official
by equalang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Translate text

translate_text

Translate plain text or up to 50 separate strings into a target language, with automatic source detection and support for long articles up to 100,000 characters.

Instructions

Translate plain text and answer with the translation. Pass texts for separate strings -- labels, messages: each translated on its own, answered in order, at most 50 texts of 5,000 characters, 20,000 characters per call. Pass text for one long text -- an article, a chapter, up to 100,000 characters: it is cut at sentences by Equalang, so do not split it yourself. For anything that is a file, use translate_file, which keeps its formatting. Charged by length, a small amount; the answer says how much.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoOne whole text, paragraphs and line breaks included, instead of texts.
textsNoSeparate strings, each translated on its own. Omit when passing text.
source_languageNoLanguage of the text; omit to detect it.
target_languageYesLanguage to translate into. A language code such as en, zh-CN, zh-TW, ja, ko, es, fr, de. list_languages has the codes: fewer for files than for text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.4

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint false, destructiveHint false, openWorldHint true), the description discloses charging ('Charged by length, a small amount; the answer says how much'), sentence-based splitting by Equalang, and ordering guarantees ('answered in order'). It also clarifies Limits (50 texts, 5000 chars each, 20000 total, 100000 for text), which are not in 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the core action, then input modes, constraints, and the alternative tool. Every clause carries operational guidance; no filler or redundancy. The structure flows logically from what to use to how to use it and when not to.

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 tool's multimodal inputs, limits, and cost behavior, the description covers all essentials: purpose, input selection, constraints, splitting behavior, cost disclosure, and file-related routing. With annotations and full schema coverage, nothing critical is missing for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema has 100% coverage, the description adds critical semantics: the mutual exclusivity of text and texts, per-item and aggregate character limits, the instruction not to split long text because Equalang cuts at sentences, and that the response includes the cost. These details go well beyond the schema properties.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Translate plain text and answer with the translation') and explicitly contrasts with translate_file for files. It also distinguishes the two input modes (text vs texts), so an agent knows exactly what this tool does and how it differs from siblings.

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?

It explicitly tells when to use 'texts' (separate strings like labels/messages) versus 'text' (one long article/chapter), and when to use the alternative translate_file for anything file-like. It also mentions the cost implication, which helps an agent decide based on trade-offs.

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

Deploy Server

Other Tools