Riddle Quiz Maker

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.9/5.0

Behavior5/5

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

Annotations already mark it read-only and idempotent, but the description goes well beyond that: it explains the scratch/deep-copied Riddle is discarded, no event is dispatched, and a media URL is still checked via a live HEAD request. This gives the agent an accurate mental model of side effects and exceptions without contradicting 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.

Conciseness5/5

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

The description is dense but every sentence adds necessary information: core behavior, side-effect caveats, entry format, return envelope, project-scoping gotcha, and limitations. The main purpose is front-loaded, and the length is justified by the tool's complexity.

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?

Despite having no output schema, the description explains the return envelope and ordering, the entry shape, the project behavior, and the false-negative failure mode. Combined with the rich parameter schema, this is complete enough for an agent to select and invoke the tool correctly without guessing.

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?

The schema already covers both parameters thoroughly, so the baseline is 3, but the description adds meaningful extra guidance: it clarifies that project-scoped references fail with a misleading authorization error when 'project' is omitted, and it points to per-type build shapes via a reference link. This is useful beyond the schema alone, though the schema carries most of the load.

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,' clearly identifying it as a validation/pre-flight tool. It also distinguishes itself from the real create/update siblings by stating it never persists, never publishes, and dispatches no event.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly tells the agent when to use it: 'Use it to see why a config would be rejected before spending a real create/edit on it,' and to pre-flight multiple Riddles in one call. It also gives an important exclusion—'Catches nothing that only happens once a Riddle is really flushed or published'—and provides concrete guidance on when to pass 'project'.

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

All Riddle Quiz Maker 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.1/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: media, palettes, projects, question banks, Riddle builds, publish lifecycle, tags, and templates are cleanly separated. Even near-neighbors like question_bank_get versus question_bank_get_items or riddle_tag versus question_bank_tag are disambiguated by explicit scope descriptions.

Naming Consistency4/5

Names follow a consistent lowercase snake_case domain-prefix plus action pattern, such as riddle_get, riddle_publish, question_bank_create, and media_delete. Minor deviations like question_bank_item, question_bank_manage, and the standalone ping/whoami break the pattern slightly.

Tool Count2/5

At 38 tools, the set is well above the 25+ threshold and is heavy for an agent to navigate in a single context. Most tools are individually justified, but the surface could be consolidated, particularly around tag operations, template listing variants, and question bank actions.

Completeness4/5

The Riddle lifecycle is well covered: build, validate, update, publish, unpublish, move, rename, delete, embed, tag, and fetch stats. Minor gaps remain, such as no template delete/update, no media library listing, and no project create/update/delete, but these are workable around or arguably outside the core domain.

Resources

Need Help?