Riddle Quiz Maker

reference_get

Read-only

Read the documentation of this MCP server: the block types, form field types, result blocks, palette values and response shapes the other tools expect. Every "riddle://reference/..." URI mentioned in another tool's description, in a tool response or in an error message is a topic of this tool - pass it here to read that document. These documents are the authoritative parameter reference for the riddle_builder_* and palette_* tools: read the relevant one BEFORE the first call instead of guessing property names, and re-read it when a call fails with a VALIDATION_ERROR. Available topics:

riddle://reference/index: every document this server has, including the two families below, with exact sizes in bytes. Read this one first when you do not know which of the others you need - it is by far the smallest.
riddle://reference/getting-started: what this server is for, the authentication model, the guided prompts it offers, and the addresses of the concept documents (tools by category, workflows, bulk, move restrictions, editing, publish) that hold the rules themselves. Start here when unsure which tool to use.
riddle://reference/response-format: the {uuid, type, modifiedAt, build, nextBlockId, warnings, published, context} envelope every tool returning a Riddle answers with, plus the bulk envelope.
riddle://reference/riddle-builder/riddle-types: all 9 Riddle types with their required/optional build fields and result structure.
riddle://reference/riddle-builder/block-types: every question and content block type per Riddle type - the reference for the "blocks" of a riddle_builder_* call.
riddle://reference/concepts/defaults: how the per-entity defaults documents below work - what a read-back leaves out for still being at its default, and how to read a property name. Read this once; the documents themselves each state their own defaults completely.
riddle://reference/block-defaults/{blockType} (a family, one address per block type, e.g. riddle://reference/block-defaults/SingleChoice): the default of every property a riddle_get read-back omits from a block of that type for still being at it. Read the one block type you are configuring; see riddle://reference/index for the exact member names.
riddle://reference/form-field-defaults: what every form field type of the FormBuilder block accepts and defaults to, keyed by field type - one document, since a Form is built with several field types at once; pass "fieldTypes" to get only the ones you need.
riddle://reference/publish-defaults: the resolved default of every publish setting ("publish.") a read-back leaves out - one address, since they are the same for every Riddle type that has them.
riddle://reference/riddle-defaults/{riddleType} (a family, one address per Riddle type, e.g. riddle://reference/riddle-defaults/Quiz): the Riddle-level, preset and publish defaults of a Riddle of that type.
riddle://reference/riddle-builder/form-field-types: all 18 form field types of the FormBuilder block.
riddle://reference/riddle-builder/result-blocks: all 12 result page block types with their format and styling options.
riddle://reference/palette/fields: every palette value palette_customize accepts, and where it is used in a published Riddle.
riddle://reference/palette/built-in-palettes: the built-in palettes usable as a starting point for a custom one.
riddle://reference/palette/fonts: the font families available as the palette font.
riddle://reference/question-bank/overview: what a question bank is, its draft/publish model, and how its items relate to a QuestionBank block - read before the first questionBank_create.

Request only the documents you actually need - most are long. Up to 8 at a time, which is the size of the full Riddle Builder set (riddle-types + block-types + form-field-types + result-blocks) plus a handful of the entity addresses above.

"riddleType" and "blockTypes" narrow riddle-types and block-types down to one Riddle type's (or one block type's) own material - e.g. {"topics": ["riddle://reference/riddle-builder/block-types"], "riddleType": ["Quiz"]} drops every other type's question blocks. "fieldTypes" does the same for form-field-types, e.g. {"topics": ["riddle://reference/riddle-builder/form-field-types"], "fieldTypes": ["Dropdown"]} returns that one field type plus the property sets it refers to. All three are ignored (whole document returned) on a topic without that split, which every response says explicitly rather than silently returning everything. The block-defaults and riddle-defaults documents have nothing left to filter this way - they are already one address per entity, so reading riddle://reference/block-defaults/SingleChoice IS the filtered result, with no parameter needed. "fieldTypes" narrows form-field-defaults the same way it narrows form-field-types, so {"topics": ["riddle://reference/riddle-builder/form-field-types", "riddle://reference/form-field-defaults"], "fieldTypes": ["Dropdown"]} is the complete reference for one field type - what it is for, what it accepts, what it defaults to - and nothing else.

Input Schema

TableJSON Schema

Name	Required	Description
`topics`	Yes	The reference documents to read, as their "riddle://reference/..." URIs.
`blockTypes`	No	Narrow block-types further, to these block type name(s) (e.g. "SingleChoice", "WheelSpinner"), on top of whatever "riddleType" already kept. Names are NOT enumerated here - there are dozens across 9 Riddle types, and this schema is read by every agent on every turn regardless of whether it filters. An unknown name, or one that exists but is not part of the Riddle type(s) you filtered to, is rejected and the error names the valid names for your situation. Omit for every block type.
`fieldTypes`	No	Narrow form-field-types down to these form field type name(s) (e.g. "Dropdown", "Privacy"). The property sets a kept field type refers to (propertySets/commonProperties) and the "fields" usage notes are always returned with it. Names are NOT enumerated here for the same reason "blockTypes" does not enumerate its own - an unknown one is rejected with the full list of the 18 valid names. Ignored on every other topic. Omit for every field type.
`riddleType`	No	Narrow riddle-types/block-types down to these Riddle type(s) - e.g. ["Quiz"] on block-types drops every other type's question blocks while keeping the shared conventions (commonBlockProperties, the general Content/Ad/Quote blocks, ...). Ignored, with the whole document returned, on a topic that has no per-type split (form-field-types, result-blocks, concepts/defaults, the palette/question-bank documents). Not applicable to the block-defaults/riddle-defaults families - read the entity's own address instead. Omit for every type.
`includeAvailableTopics`	No	Whether the response should carry the full "availableTopics" catalogue. Omit it: the first reference_get of a session gets the catalogue, every call after it gets a one-line pointer back to it instead of repeating ~2.5 KB you already have - which on a small document is several times the document itself. Pass true to get it again (a fresh conversation on an existing session, or after losing it), false to never pay for it.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`references`	Yes	One entry per requested topic, in the order requested.
`availableTopics`	Yes	Every topic this tool can return - sent in full on the FIRST reference_get of a session only, so a client that reached this tool without reading its schema still learns what else is documented and what reading it would cost. Later calls carry a short {omitted, namesAndSizesIn, resend} pointer instead of repeating ~2.5 KB the caller already has; "includeAvailableTopics" overrides both directions. In the full form the static documents are listed as uri => {sizeBytes, summary}, same as riddle://reference/index and what resources/list advertises as "size". The two generated families (block-defaults, riddle-defaults - one address per entity) are compacted under "families": the address template, how many addresses it has and what they cost in total, without the individual names - those, with their exact sizes, are in riddle://reference/index. An address is built by replacing the {variable} of a "uriTemplate" with the entity you are working on, e.g. riddle://reference/block-defaults/Flashcard.

TDQS

A4.9/5.0

Behavior5/5

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

The annotation only declares readOnlyHint: true, so the description carries the burden of behavioral detail. It goes well beyond the annotation: up to 8 topics at a time, the automatic availableTopics catalogue on the first call, the one-line pointer instead of repetition afterward, explicit rather than silent filtering behavior, and rejection behavior for unknown names. This is rich and useful behavioral disclosure.

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 long, but it is well structured: the role is front-loaded, then the topic list, then the filter semantics, then the availableTopics behavior. There is some repetition of the enum values and several verbose clarifications that could be tightened, but the length is largely justified because the tool's job is precisely to let the agent navigate a large documentation space.

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?

Given this tool's complexity, the description covers everything needed: the full catalogue of topics, families, sizes, the max request size, filter behavior per topic, error handling for unknown names, the first-call catalogue behavior, and the authentication/getting-started pointer. An output schema exists, so not describing every possible return shape is acceptable; the description leaves no practical gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds substantial meaning: it explains how riddleType, blockTypes, and fieldTypes interact, gives concrete examples like {"topics": [...], "riddleType": ["Quiz"]}, describes when filters are ignored, and clarifies why names are not enumerated. It turns the parameter schema into a comprehensible filter model, far beyond what the schema alone provides.

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 names a specific verb and object: it reads the server's own documentation addressed by 'riddle://reference/...' URIs. It distinguishes itself from all siblings by explicitly stating it is the authoritative reference for the riddle_builder_* and palette_* tools, so an agent can tell it apart from every operational tool.

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?

The description gives concrete when-to-use guidance: read the relevant document BEFORE the first riddle_builder_*/palette_* call, re-read it on VALIDATION_ERROR, start with the index when unsure, and use getting-started when unsure which tool to use. It also advises requesting only needed documents, with a max count, which is explicit usage context rather than leaving the agent to infer.

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?