Riddle Quiz Maker

questionBank_templateList

Read-onlyIdempotent

Lists the built-in template question banks - pre-filled starter banks anyone can duplicate with questionBank_duplicate to get a bank with real content immediately, instead of starting empty. An overview only: each template is listed with its id, title, its PUBLISHED item count ("itemCount") and DRAFT item count ("draftItemCount"), which blockTypes those items are (null if that cannot be told yet) and a few example categories out of "categoryCount" - read the chosen id with questionBank_get (every category) and questionBank_getItems (the questions themselves) before duplicating it. A template that was never published shows "itemCount": 0 no matter how many questions it actually holds - "draftItemCount" is the number a questionBank_duplicate of it would give you, and the one to judge a template's real size by. Every other tool here rejects a template id, since a template belongs to nobody and is only ever changed through a copy of it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`riddleType`	No	Filter by Riddle type ("Quiz" or "Poll"). Omit to list templates of every type.

TDQS

A4.3/5.0

Behavior5/5

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

The description discloses that the output includes id, title, itemCount, draftItemCount, blockTypes, and categories, with a note that blockTypes may be null. It also explains the discrepancy between published and draft counts for unpublished templates, making the behavior clear beyond the readOnlyHint annotation.

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

Conciseness2/5

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

The description is overly verbose and repetitive, with phrases like 'pre-filled starter banks' and 'instead of starting empty' repeated. It could be condensed to a few sentences without losing essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides comprehensive context including the tool's purpose, the meaning of output fields, and guidance on using related tools. It also mentions edge cases like unpublished templates, making it complete for users to understand how to use the tool effectively.

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?

The only parameter, riddleType, is fully described in the input schema with its default behavior. The tool description does not add any additional meaning or context to this parameter, so it relies on the schema's clarity, which is high (100% coverage).

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 clearly states that the tool lists built-in template question banks, and explains that they are pre-filled starter banks that can be duplicated. It distinguishes the tool from others by mentioning the duplicate action and the use case of getting real content immediately.

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 explicitly advises that this is an overview and recommends using questionBank_get and questionBank_getItems for more details before duplicating. It also explains the meaning of itemCount and draftItemCount, and how to interpret them for unpublished templates, providing clear guidance on usage.

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?