Riddle

riddle_get

Read-onlyIdempotent

Reads one Riddle - or several, with UUIDs - as the compact build-configuration envelope {uuid, type, modifiedAt, build, nextBlockId, warnings, published, context}. "build" is the DRAFT and is exactly what the riddle_builder_* tools accept back; "published" is the live version visitors see (null = never published, {"status": "identical"} = the live version matches the draft, {"status": "differs", "build": ...} = unpublished edits, and "isLive" on either says whether it is on the web right now). Content the build config cannot express never fails the call - it is reported in "warnings" instead. A property still at its block type's default is left out rather than returned: riddle://reference/block-defaults/ and riddle://reference/riddle-defaults/ state what it is, and it must NOT be resent as a property, since many build properties enable a feature by being present at all. "context" holds what sits around the config: title, image, tags, notes, viewUrl, features, origin (whether riddle_delete/riddle_builder_update/palette_customize work on this Riddle), publish/unpublish/modify state, project and preset identity. Make the response smaller with "omit"; bigger with omittedDefaults or includeRiddleData, both off by default and both large. Field by field: riddle://reference/concepts/response-envelope, plus /warnings, /publish and /bulk.

Input Schema

TableJSON Schema

Name	Required	Description
`UUID`	No	The UUID of the single Riddle you want to read. Pass either this or UUIDs.
`omit`	No	Leaves whole sections out: "build", "warnings", "nextBlockId", "published", "context" (identity fields always stay). The one omission that materially shrinks a response is "published" on a Riddle with unpublished changes - a second full build configuration. Whatever you leave out is echoed in "omittedFields", so a missing key never reads as "this Riddle has none of that". Details: riddle://reference/concepts/warnings.
`UUIDs`	No	Several Riddles to read at once, as Riddle UUID strings, e.g. ["6FA740EW", "OllsevHa"] (max 20 - lower than the other bulk tools, since every entry is a full envelope rather than compact state). Either this or UUID; rejected together with includeRiddleData. Entries are read in the order given and, once the response would exceed the inline size budget, the remaining ones come back as compact state with "truncated": true instead - so put the Riddles you need in full first. See riddle://reference/concepts/bulk.
`omittedDefaults`	No	Whether every block should additionally carry its "omittedDefaults" map: the properties it left at that block type's default, with the value each is at. Off by default - measured, those maps are 85-90% of a read-back, and riddle://reference/block-defaults/<block type> states the same defaults without a Riddle in hand. Ask for them only to learn what THIS Riddle left at its default, and read them, never resend them.
`includeRiddleData`	No	Additionally returns the full stored Riddle payload (content, settings, preset merge/diff, ...) under "riddle" - tens of KB, only for inspecting raw stored data. Not allowed together with UUIDs.

Schema Changelog

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

Changed10 schema fields changedSep 2, 2026

addedInput schema / oneOf

Added value: +[
+  {
+    "properties": {
+      "UUID": {
+        "not": {
+          "type": "null"
+        }
+      },
+      "UUIDs": {
+        "const": null
+      }
+    },
+    "required": [
+      "UUID"
+    ]
+  },
+  {
+    "properties": {
+      "UUID": {
+        "const": null
+      },
+      "UUIDs": {
+        "not": {
+          "type": "null"
+        }
+      }
+    },
+    "required": [
+      "UUIDs"
+    ]
+  }
+]

removedInput schema / properties / UUIDs / definition

Removed value: -{
-  "items": {
-    "pattern": "^[A-Za-z0-9]{4,32}$",
-    "type": "string"
-  },
-  "maxItems": 20,
-  "minItems": 1,
-  "type": "array",
-  "uniqueItems": true
-}

changedInput schema / properties / UUIDs / description

Previous value: -"Several Riddles to read at once, as Riddle UUID strings, e.g. [\"6FA740EW\", \"OllsevHa\"]\n(max 20 - lower than the other bulk tools, since every entry here is a full\nbuild-configuration envelope, not compact state). Pass either this or UUID; rejected\ntogether with includeRiddleData: true, which would overflow the inline response size.\nThe response is the {bulk, operation: \"read\", summary, results} envelope the other bulk\ntools answer with, but with the full riddle_get envelope per entry. Size is therefore\nthe thing to manage: entries are read in the order you listed them, and once the\nresponse would exceed the inline size budget, the remaining ones are reported as\n{uuid, success: true, truncated: true, ...compact state} instead of their full envelope\n- never silently dropped - with a top-level \"truncated\" block naming those UUIDs. Put\nthe Riddles you most need in full first, and use \"omit\" to fit more of them in: an\nunfiltered bulk read of several non-trivial Riddles will truncate.\nomit: [\"build.omittedDefaults\"] is by far the most effective (~85-90% off every entry);\nleaving out whole sections saves much less, a build configuration being almost the\nentire envelope."New value: +"Several Riddles to read at once, as Riddle UUID strings, e.g. [\"6FA740EW\", \"OllsevHa\"]\n(max 20 - lower than the other bulk tools, since every entry is a full envelope rather\nthan compact state). Either this or UUID; rejected together with includeRiddleData.\nEntries are read in the order given and, once the response would exceed the inline size\nbudget, the remaining ones come back as compact state with \"truncated\": true instead -\nso put the Riddles you need in full first. See riddle://reference/concepts/bulk."

addedInput schema / properties / UUIDs / items

Added value: +{
+  "pattern": "^\\s*[A-Za-z0-9]{4,32}\\s*$",
+  "type": "string"
+}

addedInput schema / properties / UUIDs / maxItems
```
Added value: +20
```
addedInput schema / properties / UUIDs / minItems
```
Added value: +1
```

changedInput schema / properties / includeRiddleData / description

Previous value: -"Additionally returns the full stored Riddle payload (content, settings, preset\nmerge/diff, ...) under \"riddle\". A large payload (tens of KB) - only for\ninspecting raw stored data, leave it false for normal use. Not allowed\ntogether with UUIDs."New value: +"Additionally returns the full stored Riddle payload (content, settings, preset\nmerge/diff, ...) under \"riddle\" - tens of KB, only for inspecting raw stored\ndata. Not allowed together with UUIDs."

changedInput schema / properties / omit / description

Previous value: -"Leaves parts of the response out - the one way to make this call smaller. Valid values:\n\"build\", \"warnings\", \"nextBlockId\", \"published\", \"context\" (whole envelope sections) and\n\"build.omittedDefaults\" (the per-block \"omittedDefaults\" maps inside every build\nconfiguration in the response, including \"published.build\" - not a section, but by far\nthe largest part of one). Omit the parameter, or pass [], for everything;\n\"uuid\"/\"type\"/\"modifiedAt\" are always present and cannot be left out.\nWhich value to reach for: \"build.omittedDefaults\" shrinks a read-back by ~85-90% and\nloses no information, since riddle://reference/block-defaults/<block type> and\nriddle://reference/riddle-defaults/<riddle type> state the very same defaults - the right\ndefault for any call that does not specifically need to know which properties sit at\ntheir default. Whole sections\nare worth naming when you truly do not need them: \"published\" is a second full build\nconfiguration whenever the draft has unpublished changes (about half the response),\nwhile \"warnings\"/\"nextBlockId\"/\"context\" together are only a few percent of it - though\nleaving out \"published\" also skips re-serializing the live version entirely, and\n\"context\" skips that section's extra lookups (features/origin, cover image, preset\ndiff), so the saving is in work as well as bytes.\nWhatever you leave out is echoed back in \"omittedFields\", so a key missing from the\nresponse never has to be read as \"this Riddle has none of that\", only as \"I asked for it\nto be left out\"; a call that omitted nothing carries no such key. With UUIDs, the same\nomissions apply to every entry."New value: +"Leaves whole sections out: \"build\", \"warnings\", \"nextBlockId\", \"published\", \"context\"\n(identity fields always stay). The one omission that materially shrinks a response is\n\"published\" on a Riddle with unpublished changes - a second full build configuration.\nWhatever you leave out is echoed in \"omittedFields\", so a missing key never reads as\n\"this Riddle has none of that\". Details: riddle://reference/concepts/warnings."

changedInput schema / properties / omit / items / enum

Previous value: -[
-  "build",
-  "warnings",
-  "nextBlockId",
-  "published",
-  "context",
-  "build.omittedDefaults"
-]New value: +[
+  "build",
+  "warnings",
+  "nextBlockId",
+  "published",
+  "context"
+]

addedInput schema / properties / omittedDefaults

Added value: +{
+  "default": null,
+  "description": "Whether every block should additionally carry its \"omittedDefaults\" map: the properties it left at that block type's default, with the value each is at. Off by default - measured, those maps are 85-90% of a read-back, and riddle://reference/block-defaults/<block type> states the same defaults without a Riddle in hand. Ask for them only to learn what THIS Riddle left at its default, and read them, never resend them.",
+  "type": "boolean"
+}

Changed1 schema field changedAug 24, 2026

changedInput schema / properties / omit / description

Previous value: -"Leaves parts of the response out - the one way to make this call smaller. Valid values:\n\"build\", \"warnings\", \"nextBlockId\", \"published\", \"context\" (whole envelope sections) and\n\"build.omittedDefaults\" (the per-block \"omittedDefaults\" maps inside every build\nconfiguration in the response, including \"published.build\" - not a section, but by far\nthe largest part of one). Omit the parameter, or pass [], for everything;\n\"uuid\"/\"type\"/\"modifiedAt\" are always present and cannot be left out.\nWhich value to reach for: \"build.omittedDefaults\" shrinks a read-back by ~85-90% and\nloses no information, since riddle://reference/riddle-builder/block-defaults states the\nvery same defaults per Riddle type and block type - the right default for any call that\ndoes not specifically need to know which properties sit at their default. Whole sections\nare worth naming when you truly do not need them: \"published\" is a second full build\nconfiguration whenever the draft has unpublished changes (about half the response),\nwhile \"warnings\"/\"nextBlockId\"/\"context\" together are only a few percent of it - though\nleaving out \"published\" also skips re-serializing the live version entirely, and\n\"context\" skips that section's extra lookups (features/origin, cover image, preset\ndiff), so the saving is in work as well as bytes.\nWhatever you leave out is echoed back in \"omittedFields\", so a key missing from the\nresponse never has to be read as \"this Riddle has none of that\", only as \"I asked for it\nto be left out\"; a call that omitted nothing carries no such key. With UUIDs, the same\nomissions apply to every entry."New value: +"Leaves parts of the response out - the one way to make this call smaller. Valid values:\n\"build\", \"warnings\", \"nextBlockId\", \"published\", \"context\" (whole envelope sections) and\n\"build.omittedDefaults\" (the per-block \"omittedDefaults\" maps inside every build\nconfiguration in the response, including \"published.build\" - not a section, but by far\nthe largest part of one). Omit the parameter, or pass [], for everything;\n\"uuid\"/\"type\"/\"modifiedAt\" are always present and cannot be left out.\nWhich value to reach for: \"build.omittedDefaults\" shrinks a read-back by ~85-90% and\nloses no information, since riddle://reference/block-defaults/<block type> and\nriddle://reference/riddle-defaults/<riddle type> state the very same defaults - the right\ndefault for any call that does not specifically need to know which properties sit at\ntheir default. Whole sections\nare worth naming when you truly do not need them: \"published\" is a second full build\nconfiguration whenever the draft has unpublished changes (about half the response),\nwhile \"warnings\"/\"nextBlockId\"/\"context\" together are only a few percent of it - though\nleaving out \"published\" also skips re-serializing the live version entirely, and\n\"context\" skips that section's extra lookups (features/origin, cover image, preset\ndiff), so the saving is in work as well as bytes.\nWhatever you leave out is echoed back in \"omittedFields\", so a key missing from the\nresponse never has to be read as \"this Riddle has none of that\", only as \"I asked for it\nto be left out\"; a call that omitted nothing carries no such key. With UUIDs, the same\nomissions apply to every entry."

First observedAug 20, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses rich behavior: draft vs. published variants, null/identical/differs semantics, warnings for content the build config cannot express, omission of default-valued properties, and the instruction not to resend omitted defaults. This is exactly the contextual behavior annotations cannot convey.

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?

The description is dense but front-loaded: the first sentence states the core action, and each subsequent sentence adds non-obvious field, published-state, default, or context semantics without redundancy. Its length is justified by the tool's complexity and the absence of an output schema.

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 complex read tool with no output schema, the description covers the response envelope, published-state model, warning behavior, default-property omission, context contents, and response-size controls. It also references field-by-field documentation, leaving no significant gap for an agent to invoke the tool correctly.

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 detailed parameter descriptions already carry most of the weight. The description adds cross-cutting meaning beyond the schema by tying UUIDs, omit, omittedDefaults, and includeRiddleData to envelope size and read-only inspection purpose, and by warning that omittedDefaults must be read but never resent.

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: it reads one or several Riddles by UUID and returns a compact build-configuration envelope, naming the main fields ({uuid, type, modifiedAt, build, ...}). This clearly distinguishes riddle_get from the many list/search siblings and states exactly what it produces.

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 establishes a clear use case: retrieve known Riddles by UUID as the envelope that riddle_builder_* tools accept, and explains when to use omit, omittedDefaults, and includeRiddleData. It does not explicitly name when-not-to-use siblings such as riddle_list, so it falls just short of a full exclusions/alternatives statement.

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?