Skip to main content
Glama

Join a document to the languages of another, or take it out of its own

tongue_doc
Idempotent

Joins a document to another document’s language group or removes it, keeping multilingual versions together under one folder; set the document’s language tag when needed.

Instructions

A document told in several languages is several documents, one per language, that the person sees as one with a switch between them; read_doc, outline_doc, docs and find name them under languages. With of, this joins doc to the languages of that document, moving it into the same folder; both have to say their language, in a lang: line of their properties or, for doc, in lang, which is written there. Without of, it takes doc out of its languages and the others stay together. To write a new translation, write_doc with translation_of does it in one call. A page is in the language of its document and joins nothing.

Input Schema

NameRequiredDescriptionDefault
ofNoThe id of a document whose languages it joins. Left out, it is taken out of its own
docYesThe id of the document to join or take out — an opaque name like `q7ntmzbm-0001`, not its title
langNoThe language `doc` is in, as a tag like `es`, `en` or `pt-BR`, when its properties do not say it

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.41.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare the mutation/idempotency/safety profile, and the description still adds real behavior: joining also moves the document into the target's folder, a side effect not visible in the schema. It also states the precondition that both documents must declare a language, either in a `lang:` property line or via the `lang` parameter, which explains the failure mode. What's missing is any statement of what happens on a language mismatch or what the call returns.

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?

It is dense and front-loads the conceptual model before the operational detail, and every sentence carries information (the model, the `of` branch, the no-`of` branch, the write_doc alternative, the page exclusion). The first sentence is long and stylistically circuitous, costing a little readability, but there is no filler.

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 three-parameter, non-destructive, idempotent reorganization tool with no output schema, the description covers scope, both operational modes, preconditions, side effects (folder move), an alternative tool, and an explicit exclusion (pages). Nothing an agent needs in order to call it correctly appears to be missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it clarifies that `of` switches the operation between join and detach, and that `lang` is only needed when the document's own properties don't already declare it — and that the supplied value is written there ('which is written there'), implying a persisted side effect the schema does not mention.

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 establishes a specific model (a document is really one document per language) and names both operations: with `of` it joins `doc` to another document's language set, without `of` it removes `doc` from its own. It also distinguishes itself from `write_doc` with `translation_of` and notes that `read_doc`, `outline_doc`, `docs` and `find` are the read-side siblings. The metaphorical 'tongue' framing adds some indirection, but the concrete semantics are recoverable.

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?

The when-to-use is fully explicit and branching: 'With `of`, this joins... Without `of`, it takes `doc` out.' It also names the alternative for creating a new translation ('write_doc with translation_of does it in one call') and excludes pages ('A page is in the language of its document and joins nothing'). An agent can pick between this and write_doc without further inference.

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