RooQuiz

Get form translation

get_form_translation

Read-only

Read the full content of one language version (translation) of a form, including the mirrored fields[] and report. Use this to fetch the current draft before translating: edit the human-readable text in place, keep every code identical to the source form, then save with update_form_translation. Returns an error if that language version does not exist yet (create it first with create_form_translation).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`formId`	Yes	The source form UUID
`language`	Yes	Which language version to read

Output Schema

TableJSON Schema

Name	Required	Description
`title`	No	Translated title
`fields`	No	Translated questions, mirroring the source codes
`formId`	No	The source form
`report`	No	Translated report copy
`booking`	No	Translated booking block copy { title, description, buttonText }
`feedback`	No	Translated feedback block copy { question, title, description, buttonText, choices[{ code, label }] }; null values / a null block = not translated yet (falls back to the source)
`isActive`	No	Whether this language version is live
`language`	No	Language of this version
`shareUrl`	No	Public link for this language
`updatedAt`	No	ISO datetime
`systemText`	No	Translated system copy
`description`	No	Translated description
`feedbackSource`	No	Source feedback block copy with its choice codes; null when the form has none

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 12, 2026

addedOutput schema / properties / booking

Added value: +{
+  "description": "Translated booking block copy { title, description, buttonText }",
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / feedback

Added value: +{
+  "description": "Translated feedback block copy { question, title, description, buttonText, choices[{ code, label }] }; null values / a null block = not translated yet (falls back to the source)",
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / feedbackSource

Added value: +{
+  "description": "Source feedback block copy with its choice codes; null when the form has none",
+  "type": [
+    "object",
+    "null"
+  ]
+}

First observedAug 24, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description goes further by disclosing the error behavior when the language version is absent and by conveying the read-then-mutate workflow with its constraints (edit text, keep codes identical). It does not cover rate limits or pagination, which for a single-record read is minor.

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?

Three sentences, each earning its place: what it returns, how to use it in the translate workflow, and the failure condition with the remedy. The purpose statement is front-loaded and nothing is padded.

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?

With an output schema present, return values need no explanation, yet the description still summarizes the payload shape and flags the error case plus the follow-up tool. An agent has everything needed to call it correctly and act on the result.

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% and the enum is documented, so baseline is 3. The description adds genuine meaning tied to the language parameter: it must already exist, otherwise the call errors and you must create it first. No syntax details beyond the schema are added, but the precondition is a real semantic gain.

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 and resource ('Read the full content of one language version (translation) of a form') and even names what the payload contains (mirrored fields[] and report). This is clearly distinguishable from get_form and list_form_translations.

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?

Gives an explicit workflow: use this to fetch the current draft before translating, edit text in place, keep codes identical, then save with update_form_translation. It also states the precondition for failure and names the sibling that fixes it (create_form_translation). Alternatives and when-not conditions are both covered.

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

All RooQuiz tools Inspect

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

Need Help?