Skip to main content
Glama

Riddle Quiz Maker

by com.riddle

palette_customize

Changes the palette (colors, fonts, button styles, background) of a single Riddle. Values are given as a path => value map, e.g. {"bgColor": "#ffffff", "font.name": "Roboto"} - call palette_get or read riddle://reference/palette/fields for all available paths. Only ever affects the given Riddle: a palette inherited from the account / project default preset is not changed for other Riddles, the new values are stored as an override on this Riddle. Built-in palettes ("default:") are not stored anywhere, so they are duplicated into a Riddle-owned copy automatically; pass newPaletteName to always work on a copy. Two things to know: the new design is only visible on the embedded (live) Riddle after publishing it again with riddle_publish, and only Riddles that were created via the Riddle Builder tools (riddle_builder_) or generated by the Riddle AI can be restyled - Riddles the user created manually in the Creator are rejected. Check context.origin.apiManageable on riddle_get (or "origin" on riddle_list/riddle_account_list) beforehand to know whether a given Riddle qualifies, instead of finding out from the error. A palette write does NOT change the Riddle's modifiedAt/modifiedBy - the Creator itself does not stamp them for a design change either, so a client polling modifiedAt for changes will not notice this. What DOES move is riddle_get's context.preset.drifted (turns true once the Riddle preset diverges from its parent) and context.modified.hasChanges (also true from the preset side) - check those, not modifiedAt, to detect an unpublished design change.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
selectNoSelect the palette afterwards so the Riddle actually renders with it. Newly created palettes are always selected.
valuesYesMap of palette path => new value, e.g. {"bgColor": "#ffffff", "buttonColor": "rgba(0,0,0,0.8)", "font.name": "Roboto", "riddleBorderRadius": 12, "isImageInBgDisplayed": true}. Every path must be one of the paths listed in riddle://reference/palette/fields.
riddleUUIDYesThe UUID of the Riddle you want to restyle. Only Riddles created via the Riddle Builder tools or generated by the Riddle AI can be restyled.
paletteUUIDNoThe palette to change. Omit to change the currently selected palette. Pass a built-in id ("default:timeless") to start from that palette.
newPaletteNameNoCreate a new palette with this name (copied from paletteUUID / the selected palette) and apply the values to the copy, leaving the original untouched.

TDQS

A5/5.0
Behavior5/5

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

The description discloses numerous behavioral traits beyond the idempotentHint:false annotation: it only affects the given Riddle, stores an override, duplicates built-in palettes, requires re-publishing for visibility, rejects manually created Riddles, and does NOT change modifiedAt/modifiedBy but does set context.preset.drifted and context.modified.hasChanges. This is far more than typical.

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?

Though long, the description is tightly structured and front-loaded: main action first, then value format, scope, built-ins, publishing requirement, eligibility, and side effects. Every sentence adds necessary operational insight; no filler or redundancy.

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?

Given the tool's complexity (5 params, nested values, no output schema), the description fully covers prerequisites, side effects, how to discover valid paths, and how to detect unpublished changes. It leaves no practical gaps for correct invocation.

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?

Schema coverage is 100%, so baseline is 3, but the description adds significant meaning: it explains the path=>value map format with examples, clarifies that newPaletteName always works on a copy, and notes that built-in palettes are duplicated automatically. These enrich the bare schema definitions.

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+resource: 'Changes the palette (colors, fonts, button styles, background) of a single Riddle.' It clearly distinguishes this from palette_get (read) and other riddle_builder_* tools by scoping the action to a single Riddle's palette.

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?

Provides explicit guidance: call palette_get or read riddle://reference/palette/fields for valid paths, and check context.origin.apiManageable on riddle_get before calling to avoid errors. It also clarifies when not to use (Riddles created manually in Creator are rejected), making usage conditions unambiguous.

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

All Riddle Quiz Maker toolsInspect
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

A3.8/5.0
Disambiguation4/5

Tools are largely distinct by name and detailed descriptions, with clear prefixes (riddle_builder_*, questionBank_*, stats_*). Some potential confusion exists among the stats tools (stats_fetch vs stats_overview_fetch vs breakdowns) but descriptions clarify their different scopes. Overall, an agent can usually pick the right tool.

Naming Consistency4/5

Naming follows a predictable prefix+verb pattern within each domain (e.g., riddle_builder_quiz, riddle_builder_poll; riddle_get, riddle_publish). Minor inconsistencies exist, like the camelCase 'questionBank' and 'riddleTemplate' prefixes vs snake_case elsewhere, and 'stats_overview_fetch' ordering, but these are not chaotic and remain readable.

Tool Count1/5

With 62 tools, this far exceeds the recommended 3-15 range and even the 25+ threshold. While the server covers a broad domain, the extreme number overwhelms and makes tool selection harder, fitting the 'extreme mismatch' criterion for 50+ tools.

Completeness5/5

The tool surface is exceptionally comprehensive, covering creation, reading, updating, deleting, publishing, unpublishing, moving, tagging, template management, question banks, palettes, and various stats breakdowns. There are no obvious gaps in the lifecycle of managing interactive content, and all apparent operations are supported.

Resources