Skip to main content
Glama
Sign In

EaseWeb

by host.easeweb
OverviewDiscussionsAdmin

Change the language of a presentation

set_language

Say which language the texts of a presentation you may edit are written in, when the site guessed it wrong (all its texts are Russian, but it was made English). Every text, slide name and the title is put right: where a translation into the new language exists, it becomes the text and the text becomes the translation into the old language; texts that are in the new language already stay; the ones that are in neither are listed as "untranslated". Returns the counts and what is still to translate.

Input Schema

NameRequiredDescriptionDefault
langYesThe language the texts are written in.
slugYesThe presentation's slug (its address: /movie/<slug>/).

Output Schema

NameRequiredDescriptionDefault
keptNoTexts that were in the language already.
langYes
swappedNoTexts whose translation became the text.
untranslatedNoTexts in neither language.
previous_langNo
untranslated_blocksNoThe first of those blocks.
missing_translationsNoWhat is not translated yet into the other languages of the site (add it): the first ones; "missing_translations_count" says how many there are.
missing_translations_countNoHow many texts are not translated yet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / missing_translations / items / properties / outdated
      Added value: +{
+  "description": "There is a translation, written for an earlier text.",
+  "type": "boolean"
+}
  2. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare the mutation profile (readOnly=false, destructive=false, idempotent=false), and the description adds substantial behavior beyond them: which elements are affected (texts, slide names, title), that existing translations are swapped rather than overwritten, that already-correct texts stay untouched, and that unmatched texts are surfaced as 'untranslated'. What is missing is the access requirement beyond the vague 'a presentation you may edit' and any note about whether the swap can be undone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

All the information is relevant, but the delivery is a run-on sentence with the usage condition buried in a mid-sentence clause and an awkward register ('is put right'). Restructuring as 'what it does / when to use / what it changes' would cost fewer words and front-load the purpose.

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

Completeness4/5

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

With an output schema present and annotations covering safety, the description's job is behavioral explanation, which it largely delivers: affected fields, swap semantics, untouched texts, and the untranslated bucket. Only the permission model and reversibility are left implicit for a non-idempotent write tool.

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

Parameters3/5

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

Schema coverage is 100% and the lang enum (ru/en) is documented, so the schema already carries the parameter burden. The description adds the crucial framing that lang is the language the texts are currently written in and that the mismatch scenario is the point, but it does not elaborate on slug handling or edge cases, so baseline 3 applies.

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 makes clear this tool declares/corrects the language a presentation's texts are written in, and then re-pairs texts with their translations. The verb is phrased indirectly ('Say which language the texts ... are written in') rather than as 'set/change', and it never names the sibling translate_presentation, so the agent must infer the boundary itself.

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 gives a concrete triggering condition: use it 'when the site guessed it wrong (all its texts are Russian, but it was made English)'. That is a clear when-to-use signal, but there is no explicit when-not and no reference to alternatives like translate_presentation, which an agent could easily confuse with this tool.

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

All EaseWeb toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources