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, against a scratch/deep-copied Riddle that is discarded before this returns - never persisted, never published, no event dispatched. Any media URL in the build IS still checked for reachability with a live HEAD request (no file content is fetched or stored) exactly as a real call would, so an unreachable URL is rejected here too (INVALID_MEDIA) - this is not deferred to flush/publish time. Each entry is {type, build} for a creation or {UUID, build} for an edit; the answer is {valid, summary, items: [{index, type, UUID?, valid, build|errors, warnings?, internalError?}]} - one entry per item, in the order they were sent, so a single config means one entry and items[0]. "internalError" is only present, and only true, when checking that one item ran into an error on OUR side rather than a rejection: that item's outcome is unknown and has been reported to us, and it does not affect the other items in the same call (a real call with that config would answer a 500). Use this to check a build config, or to see why one would be rejected, before spending a real create/edit on it - and to pre-flight a set of similar Riddles in one call. Needed subscription plan: Business or Enterprise. Does NOT catch anything that only happens once a Riddle is actually flushed or published: a database constraint violation or queue-worker behaviour. See riddle://reference/riddle-builder/riddle-types for per-type build shapes and riddle://reference/response-format for the "build"/"warnings" shape this echoes back.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`omit`	No	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.
`builds`	No	The build configs to dry-run, one entry each: {type, build} for a would-be creation or {UUID, build} for a would-be edit - exactly one of "type"/"UUID" per entry, creates and edits mixable in one call, 1 to 20 entries. "type" is one of Quiz / Poll / Personality / Form / Predictor / Leaderboard / Minigame / Story / Placeholder. "build" is exactly the build configuration the matching riddle_builder_<type> tool (creation) or riddle_builder_update (edit) takes, so a config can be moved between them unchanged. An edit entry is subject to the same origin gate as riddle_builder_update: rejected if the Riddle is not apiManageable (check context.origin.apiManageable on riddle_get first).

TDQS

A4.8/5.0

Behavior5/5

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

The description goes well beyond the readOnlyHint and idempotentHint annotations: it discloses that media URLs are still live HEAD-checked, that no event is dispatched, that the scratch Riddle is discarded, and that internalError means an unknown server-side failure. These are important behavioral nuances not captured anywhere else.

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 description is dense but every sentence earns its place, covering return shape, side effects, limitations, subscription plan, and references. It is somewhat long and could be visually broken up, but its front-loading of the core dry-run behavior in the first sentence is strong and appropriate for 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?

With no output schema, the description fully explains what each response item contains, including valid, summary, items, warnings, and internalError. It also covers ordering, error semantics, and references for build shapes. An agent has enough to call this tool correctly and interpret its results even without structured output metadata.

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 baseline is 3, but the description adds meaningful extra semantics: entries must contain exactly one of type/UUID, creates and edits are mixable, 1 to 20 entries are allowed, and the build config moves unchanged from the real builder tools. The 'omit' parameter is also clarified as differing from riddle_get's omit.

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 precise verb ('dry-runs') and a specific resource ('Riddle Builder creates and/or edits'), and immediately clarifies that no creation or change happens. This clearly differentiates it from the actual riddle_builder_<type> tools and riddle_builder_update, which perform real persistence.

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 says to 'use this to check a build config... before spending a real create/edit on it' and to pre-flight a set of Riddles. It also provides the when-not boundary: it does not catch flush/publish-time issues, so a validation success does not guarantee a real call will fully succeed.

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

A3.8/5.0

Disambiguation4/5

Tools are largely distinct by name and detailed descriptions, with clear prefixes (riddle_builder_*, questionBank_*, stats_*). Some potential confusion exists among the stats tools (stats_fetch vs stats_overview_fetch vs breakdowns) but descriptions clarify their different scopes. Overall, an agent can usually pick the right tool.

Naming Consistency4/5

Naming follows a predictable prefix+verb pattern within each domain (e.g., riddle_builder_quiz, riddle_builder_poll; riddle_get, riddle_publish). Minor inconsistencies exist, like the camelCase 'questionBank' and 'riddleTemplate' prefixes vs snake_case elsewhere, and 'stats_overview_fetch' ordering, but these are not chaotic and remain readable.

Tool Count1/5

With 62 tools, this far exceeds the recommended 3-15 range and even the 25+ threshold. While the server covers a broad domain, the extreme number overwhelms and makes tool selection harder, fitting the 'extreme mismatch' criterion for 50+ tools.

Completeness5/5

The tool surface is exceptionally comprehensive, covering creation, reading, updating, deleting, publishing, unpublishing, moving, tagging, template management, question banks, palettes, and various stats breakdowns. There are no obvious gaps in the lifecycle of managing interactive content, and all apparent operations are supported.

Resources

Need Help?