riddle_get
Gets one Riddle - or several, with UUIDs - as a compact build-configuration envelope: {uuid, type, modifiedAt, build, nextBlockId, warnings, published, context}. "build" is the same build config POST /riddle-builder accepts (see the riddle_builder_* tools) - everything the Riddle contains which cannot be expressed there is left out of "build" and reported in "warnings" instead; this never fails on content it cannot express. A property that is simply still at its block type's default is left out too, but never silently: each block carries an "omittedDefaults" map of those properties with the value each one is at - so "not in the config" does not mean "unknown". Read those values, do not resend them: many build properties enable a feature by being present at all, whatever their value. Pass omit: ["build.omittedDefaults"] to leave those maps out for a much smaller response - riddle://reference/block-defaults/ states the same defaults without a Riddle in hand. "id" and "type" are always present on every block and never omitted, and a property the block cannot accept in its current configuration is not listed either. "build" always describes the DRAFT - the version you edit; "published" describes the live version visitors see: null if never published, {"status": "identical"} if the live version is exactly what "build" shows, or {"status": "differs", "build": ..., "warnings": ...} with the live version in full when the draft has unpublished changes; unpublished changes the build config cannot express show up as {"status": "identical", "hasUnpublishedChanges": true, ...}. Every non-null "published" carries "isLive" - whether that version is online right now; it is false after riddle_unpublish, which leaves the last published version stored. Either way, call riddle_publish to make "build" live. "context" adds the extra fields an MCP client typically needs next to the build config: title, image (the Riddle's thumbnail), tags, notes, viewUrl (the public URL the Riddle is reachable under - null when it is not published or its landing page is turned off, with "viewUrlUnavailable": {reason, message} saying which of the two), features (incl. hasIntegration, consistent with riddle_list/riddle_account_list), origin (builder/aiGenerated/apiManageable - whether riddle_delete, riddle_builder_update and palette_customize will work on this Riddle, consistent with riddle_list/riddle_account_list), published/unpublished/modified state (both timestamps set = the Riddle was published and then taken offline again), duplicated (the Riddle this one was copied from, if any), project/team identity, and the preset relationship (id/parentId, whether it is merged from a parent preset and whether it has since drifted from it). Pass includeRiddleData=true to additionally receive the full stored Riddle under "riddle" - a large payload, rarely needed. Use "omit" to leave parts of all this out when you do not need them (see that parameter - it is the only way to make this call smaller), and UUIDs to read several Riddles in one call (see that parameter for its own, lower size budget).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| UUID | No | The UUID of the single Riddle you want to read. Pass either this or UUIDs. | |
| omit | No | Leaves parts of the response out - the one way to make this call smaller. Valid values: "build", "warnings", "nextBlockId", "published", "context" (whole envelope sections) and "build.omittedDefaults" (the per-block "omittedDefaults" maps inside every build configuration in the response, including "published.build" - not a section, but by far the largest part of one). Omit the parameter, or pass [], for everything; "uuid"/"type"/"modifiedAt" are always present and cannot be left out. Which value to reach for: "build.omittedDefaults" shrinks a read-back by ~85-90% and loses no information, since riddle://reference/block-defaults/<block type> and riddle://reference/riddle-defaults/<riddle type> state the very same defaults - the right default for any call that does not specifically need to know which properties sit at their default. Whole sections are worth naming when you truly do not need them: "published" is a second full build configuration whenever the draft has unpublished changes (about half the response), while "warnings"/"nextBlockId"/"context" together are only a few percent of it - though leaving out "published" also skips re-serializing the live version entirely, and "context" skips that section's extra lookups (features/origin, cover image, preset diff), so the saving is in work as well as bytes. Whatever you leave out is echoed back in "omittedFields", so a key missing from the response never has to be read as "this Riddle has none of that", only as "I asked for it to be left out"; a call that omitted nothing carries no such key. With UUIDs, the same omissions apply to every entry. | |
| 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 here is a full build-configuration envelope, not compact state). Pass either this or UUID; rejected together with includeRiddleData: true, which would overflow the inline response size. The response is the {bulk, operation: "read", summary, results} envelope the other bulk tools answer with, but with the full riddle_get envelope per entry. Size is therefore the thing to manage: entries are read in the order you listed them, and once the response would exceed the inline size budget, the remaining ones are reported as {uuid, success: true, truncated: true, ...compact state} instead of their full envelope - never silently dropped - with a top-level "truncated" block naming those UUIDs. Put the Riddles you most need in full first, and use "omit" to fit more of them in: an unfiltered bulk read of several non-trivial Riddles will truncate. omit: ["build.omittedDefaults"] is by far the most effective (~85-90% off every entry); leaving out whole sections saves much less, a build configuration being almost the entire envelope. | |
| includeRiddleData | No | Additionally returns the full stored Riddle payload (content, settings, preset merge/diff, ...) under "riddle". A large payload (tens of KB) - only for inspecting raw stored data, leave it false for normal use. Not allowed together with UUIDs. |