Riddle

palette_customize

Changes the palette (colors, fonts, button styles, background) of ONE Riddle, as a path => value map, e.g. {"bgColor": "#ffffff", "font.name": "Roboto"} - the paths are palette_get's or riddle://reference/palette/fields. Never affects another Riddle: a palette inherited from the account/project default preset is not changed for the others, the values are stored as an override on this one. A built-in palette ("default:") is stored nowhere and is therefore duplicated into a Riddle-owned copy automatically; newPaletteName always works on a copy. Two things to know. The new design only reaches the embedded (live) Riddle after another riddle_publish. And only Riddles created by the riddle_builder_ tools or the Riddle AI can be restyled - one the user built by hand in the Creator is rejected, so check context.origin.apiManageable on riddle_get (or "origin" on riddle_list) rather than finding out from the error. A palette write does NOT move modifiedAt/modifiedBy (the Creator does not stamp them for a design change either), so polling those will not notice it: the detector is riddle_get's context.modified.hasChanges, true from the preset side. context.preset.drifted usually moves too but is not reliable alone - it means "diverged from the PARENT preset", so on a Riddle whose context.preset.parentId is null it stays false however much you change; read it only alongside parentId.

Input Schema

TableJSON Schema

Name	Required	Description
`select`	No	Select the palette afterwards so the Riddle actually renders with it. Newly created palettes are always selected.
`values`	Yes	Map 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.
`riddleUUID`	Yes	The 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.
`paletteUUID`	No	The palette to change. Omit to change the currently selected palette. Pass a built-in id ("default:timeless") to start from that palette.
`newPaletteName`	No	Create a new palette with this name (copied from paletteUUID / the selected palette) and apply the values to the copy, leaving the original untouched.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedAug 20, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With only sparse annotations (no readOnly hint, idempotent=false, destructive=false), the description carries the burden and delivers richly: it discloses the isolation guarantee (never affects another Riddle), override storage semantics, automatic duplication of built-in 'default:*' palettes, copy-on-write for newPaletteName, the publish-before-live delay, and the apiManageable eligibility check. This far exceeds annotation coverage and prevents real-world misuse.

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 long but information-dense, with the core purpose and scope isolation front-loaded and a clear 'Two things to know' signpost for the behavioral caveats. Minor redundancy exists (the override/copy concept is restated multiple times), which keeps it from a 5, but no sentence is wasted.

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 complex 5-parameter tool with nested objects and no output schema, the description covers scope, edge cases, prerequisites, and follow-up actions almost exhaustively. The main gap is that it never describes the return value or success/error shape, which matters more since there is no output schema to fill that void.

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 description coverage is 100%, so the baseline is 3 and the schema already documents all five parameters with examples and path validation. The description adds context around copy/override behavior and the path key source, but this complements rather than meaningfully extends the parameter-level documentation already present.

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 uses a specific verb ('Changes'), a precise resource ('the palette ... of ONE Riddle'), and a concrete mechanism ('path => value map'), with a worked example. It also distinguishes itself from sibling tools by scoping to palette styling only, which differentiates it from riddle_builder_update and palette_get without needing to open their schemas.

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 provides strong context: it names the field source (palette_get or riddle://reference/palette/fields), the precondition (Riddles must be builder/AI-created), and the required follow-up (riddle_publish before the design reaches the live embed). It fails to explicitly name alternatives or say 'use X instead when...', so there are no explicit exclusions, but the context is clear enough for routing.

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

All Riddle 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.4/5.0

Disambiguation5/5

Each tool is scoped to a distinct resource/action area: media, palettes, projects, question banks, Riddles, templates, tags, stats, and support. Potentially close pairs like riddle_tag/riddle_tag_delete and question_bank_delete/question_bank_manage are cleanly separated by their descriptions, so an agent can reliably select the right one.

Naming Consistency4/5

The naming is mostly consistent snake_case with strong resource prefixes like riddle_, question_bank_, and template_, followed by clear verbs. Minor deviations such as question_bank_item, riddle_tag, and stats_fetch break the strict verb-noun pattern but remain predictable once the convention is understood.

Tool Count3/5

At 38 tools this is a heavy surface, though the breadth is justified by the many subdomains the server covers: media, palettes, projects, question banks, Riddles, templates, tags, and stats. Most tools earn their place, but the count sits above the range where an agent can quickly survey all options.

Completeness4/5

The set covers the full lifecycle for Riddles, question banks, templates, and tags, including publish/unpublish, move, stats, and media upload/delete. Minor gaps like no media library listing and read-only project settings are workable because media IDs come from upload responses and project permissions are exposed.

Resources

Need Help?