Riddle

questionBank_get

Read-onlyIdempotent

Retrieves a single question bank by id: its title, riddleType, tags, notes, its categories/blockTypes and whether it has unpublished changes. Use questionBank_getItems for the items themselves, which are not included here. Works on a built-in template id from questionBank_templateList too, to see what a template holds before duplicating it - a template is read back without its owner and tags/notes, since it belongs to nobody. "categories" and "blockTypeCategoryMap" are NOT the same slice of data and can disagree: "categories" is drawn from every DRAFT item (published or not), while "blockTypeCategoryMap" (categories grouped by blockType) only counts items that are actually PUBLISHED - a category used only by unpublished draft items shows up in "categories" but is missing for that blockType in "blockTypeCategoryMap" until questionBank_publish catches it up.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`questionBankId`	Yes	The ID of the question bank to retrieve, as returned by questionBank_create/questionBank_list - or of a built-in template from questionBank_templateList.

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly and idempotent hints, the description discloses important behavioral details: templates are read back without owner and tags/notes 'since it belongs to nobody,' and it explains the nuanced difference between 'categories' and 'blockTypeCategoryMap' and how they can disagree. This transparently sets expectations about the response data.

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 longer than average but every sentence adds value: it covers purpose, sibling differentiation, template behavior, and a subtle data discrepancy. It could be slightly more structured (e.g., bullet points), but the front-loaded main action and sequential layout make it easy to follow.

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 thoroughly explains the return fields and the critical difference between 'categories' and 'blockTypeCategoryMap', which is essential for correctly interpreting results. It also addresses template edge cases, making the tool's behavior fully documented for a seemingly simple get operation.

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 single parameter questionBankId is already well-documented in the schema, including sources from questionBank_create/list and templateList. The description adds context about template-specific behavior (missing owner/tags/notes) that goes beyond the schema, but the parameter's core meaning is fully covered by the schema.

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 the action ('Retrieves a single question bank by id') and lists the specific data returned (title, riddleType, tags, notes, categories/blockTypes, unpublished changes). It also explicitly distinguishes itself from questionBank_getItems, which is a sibling with a similar name.

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 provides explicit guidance on when to use this tool vs. alternatives: 'Use questionBank_getItems for the items themselves, which are not included here.' It also describes a specific use case for templates from questionBank_templateList, clarifying when this tool is appropriate.

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

Disambiguation5/5

Each tool has a clear, unique purpose. The riddle_builder_* variants are distinct by Riddle type, questionBank_* and riddleTemplate_* cover separate objects, and stats_* differ by scope. No two tools appear to perform the same function.

Naming Consistency4/5

Naming is largely consistent with domain prefixes (riddle_, questionBank_, riddleTemplate_, stats_, project_, palette_, reference_). Minor deviations like riddle_account_list vs. riddle_list and whoami (no prefix) and riddle_get_embed_code vs. riddle_qr_code slightly break the pattern, but overall it is predictable.

Tool Count2/5

With 62 tools, the server is far beyond the typical 3-15 well-scoped range. While each tool is functional and the breadth reflects the platform's complexity, the sheer number makes it heavy and increases the cognitive load for an agent, suggesting over-granularity.

Completeness5/5

The tool set covers the full lifecycle: create (builder variants), read (get/list), update (builder_update, rename), delete, publish/unpublish, tagging, templates, question banks, stats, projects, palettes, and reference documentation. No obvious domain operation is missing.

Resources

Need Help?