RooQuiz

update_form

Update a form of the current team: title / description / isActive / flagImg / landingImage / theme / report / openGraph / language / systemText. flagImg is the quiz cover, landingImage the landing-page cover (sets the image only, does not toggle the landing page); both take a media id from finalize_image_upload, a media URL, or "" to clear. report and openGraph (the social share card on the answer link) merge by sub-key — only what you pass is replaced, "" clears an openGraph sub-key; in the outcome_quiz scene outcomes are matched by code so existing images survive, and removing an outcome still referenced by question votes is rejected. systemText is replaced wholesale ({} clears it). language is changeable only while the form has no language versions; scene never. Questions go through add_question / update_question / delete_question / move_question, dimensionAnalysis alone through set_dimension_analysis.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	The form ID to update
`theme`	No	New visual theme for the answer page. Only this sub-key of personalized is changed; settings are kept. Optional visual theme matching the quiz topic/mood. Default light. Pick the one that best fits the quiz: light (clean neutral bright; default — formal/general quizzes); corporate (professional blue+gray; B2B, career, business assessments); dark (modern sleek dark; tech, night, cool personality quizzes); cupcake (soft pink cute rounded; fun, food, kids, lighthearted); pastel (gentle pastel artsy; lifestyle, aesthetics, soft mood); valentine (pink romantic hearts; love, relationships, holidays); synthwave (neon purple/pink retro; gaming, trends, bold personality); luxury (dark + gold premium; finance, luxury brands, high-end); forest (deep green nature; environment, health, outdoors); coffee (warm brown cozy; food & drink, cafe, lifestyle); autumn (warm orange/brown seasonal; autumn, cozy, harvest); halloween (purple+orange spooky; Halloween, horror, festive fun); night (deep calm blue; astronomy, mindfulness, calm tech); cyberpunk (high-contrast neon yellow; tech, esports, gaming).
`title`	No	New title
`report`	No	Report configuration, merged by sub-key into form.report: passing overallAnalysis fields (title/formula/levels/summaryTemplate/suggestionsTemplate/hideOverallScore) replaces overallAnalysis; passing dimensionAnalysis replaces it (an empty dimensions array clears it); in the outcome_quiz scene passing outcomes replaces the outcome list (matched by code, existing images kept; cannot be emptied, and removing an outcome still referenced by question votes is rejected); unspecified parts are kept. Common usage: either set custom question codes in create_form and pass report.formula / dimensionAnalysis in the same call, or call create_form first to get the auto-generated field codes, then update_form to fill in report.formula and/or dimensionAnalysis (which reference question codes).
`flagImg`	No	Quiz cover image: a media ID returned by finalize_image_upload, or a media URL. Pass an empty string to clear the cover.
`isActive`	No	Whether to enable response collection
`language`	No	Change the form's language. Only allowed while the form has no translation links and is not referenced by other language versions; otherwise rejected.
`openGraph`	No	Social share card (Open Graph) settings: the title / description / image shown when the answer link is shared to social media or chat apps. In update_form each sub-key is merged independently (only the keys you pass change; pass an empty string to clear one). SEO keywords are generated automatically and cannot be set here.
`systemText`	No	Answer-page system text overrides as a key→text map. Replaces the whole map (pass {} to clear); empty values are dropped and fall back to the language default.
`description`	No	New description; pass an empty string to clear. Allows description-scope rich text (including <img src>). This field also accepts an inline image: put an <img src="..."> in it, where src is a direct image URL that renders in <img src> (a page URL that merely contains an image does not work). Use finalize_image_upload to host an image yourself, or a direct URL the user supplied. Never invent an image URL — omit the image instead of risking a broken one.
`landingImage`	No	Landing page cover image: a media ID returned by finalize_image_upload, or a media URL. Pass an empty string to clear it. Note: this only sets the image and does NOT toggle the landing page on/off; the landing image is shown only when the landing page is enabled.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No	Form id
`scene`	No	knowledge_quiz / scored_quiz / outcome_quiz
`theme`	No	Answer-page theme name
`title`	No	Form title after the update
`flagImg`	No	Media id of the quiz cover
`isActive`	No	Whether the form is open for submissions
`language`	No	Primary language
`hasReport`	No	Whether this call replaced the report configuration
`openGraph`	No	Social share card
`updatedAt`	No	ISO datetime
`systemText`	No	Overridden system copy
`description`	No	Form description
`landingImage`	No	Media id of the landing-page cover

TDQS

A4.6/5.0

Behavior5/5

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

The annotations only declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, so the description carries behavioral disclosure. It adds substantial non-obvious detail: report/openGraph merge sub-keys (only what you pass is replaced), systemText is replaced wholesale, '' clears image/openGraph sub-keys, image-only setting does not toggle the landing page, outcomes are matched by code so existing images survive, and removal of an outcome still referenced by question votes is rejected.

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?

The description is a single dense paragraph, but every clause earns its place and the field list is front-loaded before the semantic details. There is no filler and no repetition of the larger nested-schema type definitions. The only structural downside is that the semantic mix (media, merge, wholesale, language restriction) would be slightly scannable in a short list form.

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 an 11-parameter tool with nested objects and an output schema, the description covers the call-critical ground: merge vs wholesale replacement, the image execution details, exclusion/route cases, rejection behavior, and immutability constraints. The one potential gap is that report.dimensionAnalysis still appears in the schema despite the note routing it to set_dimension_analysis, but the explicit sentence resolves that confusion for the agent.

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 schema carries the detailed parameter meaning; baseline is 3. The description adds a compact cross-parameter frame that is genuinely useful for correct calls: uniform media-id-or-URL-or-empty semantics for flagImg/landingImage/openGraph.image, the full-map replacement of systemText versus sub-key merges for report/openGraph, and the language restriction. This is largely a condensation of schema text plus the language/scene exclusion, which most agents would otherwise have to extract from the embedded blocks.

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 opening line names a precise verb+resource ('Update a form of the current team') and enumerates the exact fields in scope (title / description / isActive / flagImg / landingImage / theme / report / openGraph / language / systemText). The final sentence explicitly routes questions and dimensionAnalysis to sibling tools, which separates this tool from add_question / update_question / set_dimension_analysis without needing to inspect them.

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 closing sentence gives explicit when-not guidance with named alternatives: 'Questions go through add_question / update_question / delete_question / move_question, dimensionAnalysis alone through set_dimension_analysis.' It also states what this tool cannot do ('language... only while the form has no language versions; scene never'). It does not explicitly contrast when to prefer create_form over update_form, though the 'updated' framing makes that implicit.

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 pair a distinct resource with a distinct verb, and the descriptions do a good job of separating related concepts like leads, records, examinees, and bookings. The only real ambiguity is between list_records (submission records, also called leads) and list_leads (CRM leads), plus a mild overlap between update_form and update_form_settings, but careful reading resolves both.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern, using standard verbs like get_, list_, create_, update_, delete_, add_, insert_, move_, and set_. Minor stylistic variation such as add_question vs. insert_question is still predictable and does not hurt usability.

Tool Count2/5

48 tools is a very heavy surface for an MCP server. While each tool appears purposeful, the server spans forms, questions, translations, analytics, leads, bookings, examinees, media, and team administration, making it feel like a full platform API rather than a focused server. Most agents will only ever need a subset of these tools.

Completeness4/5

The core quiz lifecycle is well covered: form creation/editing/deletion/restore/duplicate/translation, question CRUD/move, delivery settings, statistics/funnels, lead CRM, bookings, examinees, media upload, and tenant basics. The main gaps are minor — no member list/remove/role management beyond invite, no media library listing/deletion, and no bulk export of records — but these do not create dead ends in the primary quiz/lead/booking workflows.

Resources

Need Help?