RooQuiz

update_form_translation

Save translated copy for one language version of a form. Pass the translated title / description / fields / report / systemText / booking, mirroring the shape returned by get_form_translation; fields you omit keep their current value and partial translation is allowed. Translation fields[] must not introduce codes that do not exist on the source form. Pass isActive=false to pause just this language version, independently of the form's overall isActive.

Input Schema

TableJSON Schema

Name	Required	Description
`title`	No	Translated form title
`fields`	No	Translated questions mirroring the source structure: same codes, translated text. The current draft comes from get_form_translation (or the clone create_form_translation returns) — edit the text in place and send it back. Merging is by code, not position, so a partial list is fine and omitted questions stay untranslated.
`formId`	Yes	The source form UUID
`report`	No	Translated report display text, mirroring the stored report that get_form_translation returns — the nested overallAnalysis / dimensionAnalysis / outcomeAnalysis shape, NOT the flattened `report` input of create_form / update_form. Scores, formulas, thresholds and codes always come from the source; only the text keys below are applied.
`booking`	No	Translated copy for the result-page booking block (the block that offers a call). Whether the block shows at all always comes from the source form — this only translates its wording. Omit a key or send it empty to keep falling back to the source text.
`isActive`	No	Enable/pause this language version (independent of the form's overall isActive).
`language`	Yes	Which language version to update
`systemText`	No	Translated answer-page system copy, as an open key→text map (e.g. { "submitButton": "Absenden", "nextPage": "Weiter" }). Keys are the answer-page copy keys — read the ones already set from get_form_translation, and note that keys the answer page does not know are stored but never rendered. Every key is optional; an empty value falls back to the built-in text for this language.
`description`	No	Translated form description

Output Schema

TableJSON Schema

Name	Required	Description
`formId`	No	The source form
`updated`	No	Which parts of the translation this call changed
`language`	No	Language that was saved

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only indicate non-read-only and non-destructive, so the description carries the behavioral burden, and it delivers. It discloses partial-update semantics, merge-by-code not position, rejection of non-existent codes, fallback behavior for omitted keys, and the fact that this language version's isActive is independent of the form's overall isActive. It also warns about the report shape differing from create_form/update_form and notes that stored-but-unknown keys are not rendered.

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?

Four sentences, front-loaded with the purpose, then the core update semantics, a key constraint, and the special isActive flag. There is no filler or repetition of schema content that isn't already doing work.

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 highly nested 9-parameter tool, the description plus schema fully covers the workflow: where to get the draft, how to send it back, how merging works, what constraints exist, and what the report shape should be. Output schema exists, so not explaining return values is appropriate.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds cross-cutting semantics beyond individual parameter docs: mirror the get_form_translation shape, omit fields to keep current values, partial translation is allowed, merge by code, and isActive is independent. This is exactly the kind of workflow-level meaning that makes parameter use correct, not just documentable.

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 opens with a specific verb and resource: 'Save translated copy for one language version of a form.' It clearly distinguishes this update operation from sibling tools like create_form_translation by emphasizing the one-language-version scope and the partial-update behavior. 'Pass the translated title / description / fields / report / systemText / booking' makes the tool's resource shape concrete.

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?

The description gives strong practical guidance: mirror get_form_translation's shape, omit fields to keep their values, and partial translation is allowed. It also gives a clear special-case instruction for isActive=false. However, it never explicitly names when to use this tool instead of create_form_translation or delete_form_translation, leaving the update-vs-create decision to inference.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation4/5

Most tools map to a distinct resource and action, and the descriptions actively disambiguate similar operations (e.g., get_form vs get_form_share_info vs get_form_stats). The main potential confusion is between list_records and list_leads and between get_record and get_lead, since both describe leads from slightly different angles.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun convention, with resources like form, question, lead, booking, examinee, translation, and tenant parallel across actions. The few non-CRUD verbs like prepare_/finalize_, duplicate_, and reschedule_ still fit the same uniform pattern.

Tool Count2/5

48 tools is well beyond the 3–15 ideal and even past the 25+ threshold, making the tool surface heavy for an agent to navigate. The broad platform scope explains some of the size, but the count still risks overwhelming context and increasing misselection.

Completeness4/5

The server covers form lifecycle, question editing, translations, CRM leads, examinees, records, bookings, team/tenant operations, image uploads, templates, and analytics extremely well. Minor gaps remain—such as no lead/record deletion, no member removal or role updates, and limited booking-settings management—but most workflows can be completed with the existing tools.

Resources

Need Help?