Skip to main content
Glama

translate-doc

PREMIUM: translate a long document into any language. input='en | '. [x402: 0.05 USDC on Base, pay-per-use]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYes'<idioma_destino> | <documento>'

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations available, the description carries the full burden and does well by disclosing the pay-per-use cost via '[x402: 0.05 USDC on Base].' It does not describe output characteristics or failure cases, but for a translation call the pricing disclosure is the main behavioral risk.

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?

The description packs purpose, input format, and cost into a single compact line with no waste. The PREMIUM label is front-loaded, and the pricing detail is cleanly isolated.

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?

For a one-parameter tool with full schema coverage, this is complete: it states what is translated, how to format the input, and what financial consequence the call carries. The output schema is absent, but a translation tool's output is evident from its purpose.

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?

The schema already documents the input as '<idioma_destino> | <documento>' with 100% coverage, so the baseline is 3. The description adds a concrete worked example ('en | <long text>') that reinforces the pipe-delimited order and clarifies the target-language parameter.

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 uses a clear verb+resource pair, 'translate a long document into any language,' and immediately makes the scope concrete with an example input format. This distinguishes it from siblings like translate-to or translate-en by emphasizing the long-document and premium positioning.

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

Usage Guidelines4/5

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

It explicitly positions the tool for long-document translation, which gives a clear context for when to choose it. It does not explicitly mention lighter alternatives like translate-to for short text, so it falls just short of full when/not guidance.

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.

TDQS

C2.6/5.0
Disambiguation1/5

The set contains many trivially indistinct tools: ai-inference/inference, compress/comprimir, count-tokens/contar-tokens, detect-language/language-detect, and multiple overlapping OCR receipt variants. With 160 tools and pairs that differ only by language or suffix, an agent cannot reliably distinguish several capabilities.

Naming Consistency3/5

Most names are readable lower-hyphen identifiers, but they mix action verbs, noun phrases, domain prefixes, pipeline suffixes, Spanish/English, and arbitrary demo/batch labels. There is a loose convention, but no consistent verb_noun pattern.

Tool Count1/5

160 tools on one server is an extreme count and clearly unwieldy. Even as a marketplace, exposing every variant, demo, and composed bundle as a top-level MCP tool overwhelms agent selection and adds little distinct capability.

Completeness3/5

The set covers a huge range of text, image, audio, code, market, compliance, and content-workflow tasks, so many intents have some available tool. However, it is a grab-bag rather than a defined service surface, and the arbitrary demo/specialized variants make it unclear whether a needed operation truly exists or is just a duplicate.

Resources