Skip to main content
Glama

SuprSend

Get translation

translations_get
Read-onlyIdempotent

Gets a translation file with all its keys and text. The file name is the locale, optionally after a namespace: "fr.json", "es-MX.json", "auth.en.json". Use translations_list for the file names.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "filename": "<filename>",
      "workspace": "<workspace>",
      "context": "<context>",
      "llm_model": "<llm_model>"
    },
    "name": "translations_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNolive (default): the published file. draft: with unpublished changes.live
contextYesAnalytics: why you call this tool, in 10-20 words. Say "a user", never names, emails, or IDs.
filenameYesFor example "fr.json" or "auth.en.json".
llm_modelYesAnalytics: your model ID, or "unknown".
workspaceYesThe slug of the workspace to act on. Call workspaces_list to find the valid values.
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

Output Schema

NameRequiredDescriptionDefault
actionNo
localeYes
contentYesThe translation keys and their text. Values can nest (for example plural forms). null for a file with no content.
filenameYes
namespaceNo
updated_atNo
locale_nameNo
_mcp_instructionsNoServer-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • removedOutput schema / properties / content / additionalProperties
      Removed value: -true
    • addedOutput schema / properties / content / anyOf
      Added value: +[
      +  {
      +    "additionalProperties": true,
      +    "properties": {},
      +    "type": "object"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedOutput schema / properties / content / description
      Previous value: -"The translation keys and their text. Values can nest (for example plural forms)."New value: +"The translation keys and their text. Values can nest (for example plural forms). null for a file with no content."
    • removedOutput schema / properties / content / properties
      Removed value: -{}
    • removedOutput schema / properties / content / type
      Removed value: -"object"
  2. First observed

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, so the safety profile is covered. The description adds that the whole file with keys and text is returned, but says nothing about the live-vs-draft mode difference (left to the schema) or any size/rate considerations. Adequate but thin beyond annotations.

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?

Three short sentences, front-loaded with the purpose and followed by the filename format and sibling routing. No filler, though the three filename examples are slightly redundant with the schema.

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?

For a read-only file fetch with an output schema and 100% parameter coverage, the description covers what it returns and how to source the filename. It omits the live/draft mode distinction and the workspace/conversation_id conventions, but those are handled by the schema, so it is largely complete.

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%, so parameters are already documented. The description explains the filename convention (locale optionally preceded by a namespace) and gives examples, adding a little semantic framing, but this largely mirrors what the schema's filename description already states. Baseline 3 is correct.

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?

States a specific verb+resource ("Gets a translation file") and what it returns ("all its keys and text"). It also distinguishes itself from translations_list by routing filename lookup there, so an agent can tell the two apart without opening either schema.

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?

Explicitly names the alternative for discovering inputs ("Use translations_list for the file names"). It gives clear context but doesn't cover when-not to use it (e.g., single key vs whole file), so it stops short of full routing 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.