Skip to main content
Glama

Riddle

by com.riddle

palette_get

Read-onlyIdempotent

Reads the palettes - colors, fonts, button styles, background settings - of a Riddle: every palette it can use (the ones inherited from the account/project default preset included) with all of their values, which one is selected, which values this Riddle overrides, and the built-in palettes to start from. What each value does is riddle://reference/palette/fields. Mind the size: ~30 values per palette and an account preset can contribute palettes that have nothing to do with this Riddle, so the full response runs into thousands of tokens. Cut it with "omit" - omit: ["paletteValues"] lists the palettes by uuid and name only, which is how you find WHICH one you want (paletteUUID then returns that one in full), and "builtInPalettes"/"customizedValues"/"hints" drop those keys. To read just the design in effect, pass the selectedPaletteUuid from such a listing as paletteUUID.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
omitNoLeaves parts of the response out - the way to keep this call small. "paletteValues" lists every palette as {uuid, name} instead of with its ~30 values (then read the one you want with paletteUUID); "builtInPalettes", "customizedValues" and "hints" drop those keys entirely. Omit the parameter for the full response. Whatever you leave out is echoed back under "omittedFields", so a missing key never means the Riddle has none of it.
riddleUUIDYesThe UUID of the Riddle whose palettes you want
paletteUUIDNoReturn only this palette instead of all of them. Accepts a palette UUID or a built-in palette id like "default:timeless".
includeBuiltInPalettesNoInclude the full values of all built-in palettes. Defaults to false, in which case only their ids and names are listed.

Schema Changelog

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

  1. Changed1 schema field changed
    • addedInput schema / properties / omit
      Added value: +{
+  "default": null,
+  "description": "Leaves parts of the response out - the way to keep this call small. \"paletteValues\" lists every palette as {uuid, name} instead of with its ~30 values (then read the one you want with paletteUUID); \"builtInPalettes\", \"customizedValues\" and \"hints\" drop those keys entirely. Omit the parameter for the full response. Whatever you leave out is echoed back under \"omittedFields\", so a missing key never means the Riddle has none of it.",
+  "items": {
+    "enum": [
+      "paletteValues",
+      "builtInPalettes",
+      "customizedValues",
+      "hints"
+    ],
+    "type": "string"
+  },
+  "type": "array",
+  "uniqueItems": true
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already carry readOnlyHint=true, idempotentHint=true, and openWorldHint=false; the description adds substantial context beyond them: a concrete size warning (~30 values per palette, responses running into thousands of tokens), the omittedFields echo behavior so a missing key is never interpreted as 'none', and inheritance/override semantics. No contradiction with the annotations.

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 core purpose is front-loaded in the first sentence, and the size warning is placed before its mitigation. The paragraph is dense but each sentence carries actionable information; the only minor waste is partial redundancy with the schema's omit parameter description.

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 no output schema present, the description fully carries return-value disclosure: it explains which keys exist, what they mean (selected, overridden, built-ins), how to trim them, and the omittedFields echo behavior. Given the tool's complexity (4 parameters, potentially huge response), nothing an agent needs to invoke it correctly is missing.

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 description coverage is 100%, so the baseline is 3. The description adds cross-parameter meaning the schema lacks: how omit interacts with paletteUUID as a two-step listing-then-fetch workflow, and that selectedPaletteUuid values can be fed directly back into paletteUUID. This goes beyond mere restatement of the schema.

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 states a specific verb and resource: 'Reads the palettes - colors, fonts, button styles, background settings - of a Riddle.' It then enumerates exactly what the response contains (inherited palettes, selected palette, overridden values, built-ins), which clearly distinguishes this read operation from the sibling palette_customize without needing to open either schema.

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 a concrete workflow: use the omit parameter to list palettes compactly by uuid/name, then pass a paletteUUID to fetch one in full, and pass the selectedPaletteUuid to read just the design in effect. It provides clear context and sequencing but never explicitly names when-not-to-use or alternatives (e.g., palette_customize for modification), so it falls just short of the top rung.

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

All Riddle 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

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