Riddle

questionBank_publish

Publishes a question bank: every item's draft content becomes its published content, which is what a QuestionBank block actually draws from at view time - exactly like publishing a Riddle makes its draft live. A bank with unpublished changes (see questionBank_get) still works in a QuestionBank block, it just draws from the last published state, not the newer draft. This is also when a questionBank_deleteItem of an already-published item finally takes effect: it is purged for good only now, having stayed live under its last published content until this call. Rejected for a public template id, see questionBank_templateList - a template has no draft/publish split to act on.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`questionBankId`	Yes	The ID of the question bank to publish.

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the minimal idempotentHint annotations, the description reveals significant behavioral details: what happens to drafts, how unpublished changes behave, and that deleteItem takes effect only at publish time. This is exactly the extra context an agent needs.

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 a single dense paragraph but every sentence provides valuable edge-case information (unpublished changes, deleteItem timing, template rejection). It could be broken up for readability, but it is front-loaded and not wasteful.

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 the moderate complexity and sparse annotations, the description covers all critical aspects: the publish action, effects on drafts and deletes, and a rejection case. It is fully self-contained for an agent to decide when to invoke it.

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?

Schema coverage is 100% for the single parameter (questionBankId) with a clear description. The description adds no new parameter-specific info, so the baseline of 3 applies.

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 tool publishes a question bank, transforming draft content into published content. It distinguishes itself from siblings by explaining the publish mechanism and explicitly contrasting with templates.

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

Usage Guidelines4/5

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

The description provides clear context on when the tool applies (publishing drafts, finalizing deletes) and notes an exclusion (rejected for template IDs, see questionBank_templateList). It doesn't fully contrast with all alternatives but gives enough guidance.

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?