Riddle

riddle_builder_validate

Read-onlyIdempotent

Dry-runs one or many Riddle Builder creates and/or edits without creating or changing anything: per entry of "builds", the same validation the real call would apply, run against a scratch/deep-copied Riddle that is discarded before this returns - never persisted, never published, no event dispatched. A media URL in the build IS still checked for reachability with a live HEAD request (no content fetched or stored), so an unreachable one is rejected here too (INVALID_MEDIA) instead of at flush/publish time. An entry is {type, build} for a would-be creation or {UUID, build} for an edit; the answer is the {validate, valid, summary, items} envelope of riddle://reference/concepts/bulk, one item per entry in the order sent - a single config is items[0]. Use it to see why a config would be rejected before spending a real create/edit on it, and to pre-flight a set of similar Riddles in one call. PASS "project" whenever a build references anything project-scoped (a Form behind FormSelect, a tag, a project ad slot), set to the project you will actually create in: creating entries are dry-run inside it, and without it they run in the personal project, where such a reference is invisible and comes back as "You are not authorized to access ..." for a build a real create would accept. Catches nothing that only happens once a Riddle is really flushed or published - a database constraint violation, queue-worker behaviour. Per-type build shapes: riddle://reference/riddle-builder/riddle-types.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`builds`	No	The build configs to dry-run, 1 to 20 entries, creates and edits mixable: {type, build} for a would-be creation or {UUID, build} for an edit, exactly one of "type"/"UUID" per entry. "type" is one of Quiz / Poll / Personality / Form / Predictor / Leaderboard / Minigame / Story / Placeholder, and "build" is exactly what riddle_builder_create or riddle_builder_update takes, so a config moves between them unchanged. An edit entry hits the same origin gate as riddle_builder_update - rejected unless the Riddle is apiManageable (context.origin.apiManageable on riddle_get).
`project`	No	The project to dry-run the CREATING entries in - riddle_builder_create's own parameter, and it must be the project you intend to create in: the scratch Riddle is built inside it, and anything project-scoped the build REFERENCES (a Form behind FormSelect, a tag, a project ad slot) is only resolvable from there. Without it such a build is evaluated in the personal project and rejected with "You are not authorized to access Form <UUID>" - a scope problem wearing a permissions error, and a false negative for a build a real create would accept. NULL means the personal project, omitted the currently selected one. Ignored by editing entries ({UUID, build}), always evaluated in their own Riddle's project.

Schema Changelog

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

Changed3 schema fields changedSep 2, 2026

changedInput schema / properties / builds / description

Previous value: -"The build configs to dry-run, one entry each: {type, build} for a would-be creation or\n{UUID, build} for a would-be edit - exactly one of \"type\"/\"UUID\" per entry, creates and\nedits mixable in one call, 1 to 20 entries. \"type\" is one of Quiz / Poll / Personality /\nForm / Predictor / Leaderboard / Minigame / Story / Placeholder. \"build\" is exactly the\nbuild configuration the matching riddle_builder_<type> tool (creation) or\nriddle_builder_update (edit) takes, so a config can be moved between them unchanged. An\nedit entry is subject to the same origin gate as riddle_builder_update: rejected if the\nRiddle is not apiManageable (check context.origin.apiManageable on riddle_get first)."New value: +"The build configs to dry-run, 1 to 20 entries, creates and edits mixable: {type, build}\nfor a would-be creation or {UUID, build} for an edit, exactly one of \"type\"/\"UUID\" per\nentry. \"type\" is one of Quiz / Poll / Personality / Form / Predictor / Leaderboard /\nMinigame / Story / Placeholder, and \"build\" is exactly what riddle_builder_create or\nriddle_builder_update takes, so a config moves between them unchanged. An edit entry hits\nthe same origin gate as riddle_builder_update - rejected unless the Riddle is\napiManageable (context.origin.apiManageable on riddle_get)."

removedInput schema / properties / omit

Removed value: -{
-  "default": null,
-  "description": "Leaves the per-block \"omittedDefaults\" maps out of every echoed-back build config, for a much smaller answer: omit: [\"build.omittedDefaults\"]. The same defaults are stated in riddle://reference/riddle-defaults/<riddle type> and riddle://reference/block-defaults/<block type>, so nothing is lost - what you must not do either way is resend those values. Omit the parameter to keep them. The other values of riddle_get's \"omit\" do not apply here: this envelope has no sections to drop.",
-  "items": {
-    "enum": [
-      "build.omittedDefaults"
-    ],
-    "type": "string"
-  },
-  "type": "array",
-  "uniqueItems": true
-}

addedInput schema / properties / project

Added value: +{
+  "default": null,
+  "description": "The project to dry-run the CREATING entries in - riddle_builder_create's own parameter, and it must be the project you intend to create in: the scratch Riddle is built inside it, and anything project-scoped the build REFERENCES (a Form behind FormSelect, a tag, a project ad slot) is only resolvable from there. Without it such a build is evaluated in the personal project and rejected with \"You are not authorized to access Form <UUID>\" - a scope problem wearing a permissions error, and a false negative for a build a real create would accept. NULL means the personal project, omitted the currently selected one. Ignored by editing entries ({UUID, build}), always evaluated in their own Riddle's project.",
+  "type": [
+    "null",
+    "integer"
+  ]
+}

Changed1 schema field changedAug 24, 2026

changedInput schema / properties / omit / description

Previous value: -"Leaves the per-block \"omittedDefaults\" maps out of every echoed-back build config, for a much smaller answer: omit: [\"build.omittedDefaults\"]. The same defaults are stated per Riddle type and block type in riddle://reference/riddle-builder/block-defaults, so nothing is lost - what you must not do either way is resend those values. Omit the parameter to keep them. The other values of riddle_get's \"omit\" do not apply here: this envelope has no sections to drop."New value: +"Leaves the per-block \"omittedDefaults\" maps out of every echoed-back build config, for a much smaller answer: omit: [\"build.omittedDefaults\"]. The same defaults are stated in riddle://reference/riddle-defaults/<riddle type> and riddle://reference/block-defaults/<block type>, so nothing is lost - what you must not do either way is resend those values. Omit the parameter to keep them. The other values of riddle_get's \"omit\" do not apply here: this envelope has no sections to drop."

First observedAug 20, 2026

TDQS

A4.3/5.0

Behavior5/5

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

The description is exceptionally transparent: it states the Riddle is scratch/deep-copied and discarded, never persisted, never published, no event dispatched, that media URLs are still checked via a live HEAD request with no content fetched or stored, and that the personal-project fallback can produce a false negative. This goes well beyond the readOnlyHint and idempotentHint annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description front-loads its core purpose and safety guarantees well, but it becomes verbose in the project section, repeating nearly verbatim what the input schema already says about project-scoped references and the personal-project fallback. Fine structure, but not every sentence earns its place given the 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?

With no output schema, the description still explains the {validate, valid, summary, items} envelope, per-entry ordering, items[0] for a single config, the INVALID_MEDIA reachability check, and the project-scope edge case. Combined with the exhaustive schema and annotations, an agent has everything needed to invoke this tool correctly.

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 schema already thoroughly documents both builds and project. The description adds the output envelope shape and batch ordering, but that is return-value semantics rather than parameter meaning. The project-related explanation is largely duplicated from the schema's own parameter description.

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: 'Dry-runs one or many Riddle Builder creates and/or edits without creating or changing anything.' It clearly distinguishes this validation-only tool from the actual riddle_builder_create/ruddle_builder_update siblings, and states the practical purpose: see why a config would be rejected before spending a real create/edit.

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?

It gives explicit context for when to use: 'Use it to see why a config would be rejected before spending a real create/edit on it, and to pre-flight a set of similar Riddles in one call.' It also explains how the project parameter affects dry-run resolution. It does not explicitly name the create/update alternatives or list a when-not case, so it falls just short of a 5.

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?