Skip to main content
Glama
astroway

astroway-mcp

Official
by astroway

Translate (astro-aware)

astroway_content_localization_translate_astro
Read-onlyIdempotent

Translate text into 21 languages with astrology glossary pinning for accurate terminology, defaulting source to English and allowing custom source languages.

Instructions

Translate one text into any of 21 languages with astrology-domain glossary pinning. Source defaults to English; pass source_lang to override. Credits: 15 + ceil(chars/40). Max 3000 chars.

[Group: Content Localization] [Endpoint: POST /v1/translate/astro] [Required: text, target_lang] [Cost: 16 credits (Tier 1)]

Input Schema

NameRequiredDescriptionDefault
textYes
domainNo
source_langNo
target_langYes

Output Schema

NameRequiredDescriptionDefault
charsNo
domainNo
creditsNo
providerNo
translatedNo
source_langNo
target_langNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description earns credit for adding behavior beyond that: an explicit credit formula (15 + ceil(chars/40)), a hard 3000-character ceiling, and a documented default language. It doesn't describe the response shape, 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.

Conciseness4/5

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

The substantive content is a tight two sentences front-loaded with purpose, defaults, cost, and limits. The trailing boilerplate block (Group/Endpoint/Required/Cost) partly repeats the credit formula already stated and the schema's required list, adding some redundancy but no real confusion.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations, an output schema, and a sibling that enumerates supported languages, most of the agent's needs are covered elsewhere. The notable hole is the unexplained 'domain' parameter, which materially changes glossary behavior and is documented nowhere - a real gap for a translation tool.

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

Parameters2/5

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

Schema description coverage is 0%, so the description carries the burden, and it only explains two of four parameters: the text size limit and the source_lang default. The 'domain' parameter (vedic/western/tarot/numerology/hd/marketing/generic) is never explained despite being central to the 'astrology-domain glossary pinning' claim, and target_lang semantics are left entirely to the enum.

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

Purpose4/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 one text') and adds a distinguishing scope qualifier: single-text translation with astrology-domain glossary pinning, which implicitly separates it from the sibling translate_batch tool. It stops short of naming the sibling alternatives explicitly, so it's clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a usage-relevant default ('source defaults to English; pass source_lang to override') and a hard input limit (max 3000 chars), which are useful decision inputs. However, it never says when to prefer this over translate_batch or translate_glossary_lang, nor any prerequisites, so routing guidance is only implied.

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