Riddle Quiz Maker

question_bank_manage

Everything that acts on a question bank as a whole, by "action" - the items themselves are question_bank_item, and the two calls that only destroy are question_bank_delete and question_bank_discard_changes. A public template id is accepted for "duplicate" only and rejected by every other action. "rename" sets the title and "updateNotes" replaces the plain-text maintainer notes (never shown to participants): both are metadata rather than DRAFT content, so they take effect immediately AND permanently, are unaffected by publishing or discarding and never count as an unpublished change. "publish" makes every item's draft content its published content - what a QuestionBank block actually draws at view time - and is when a pending item delete is finally purged; a bank with unpublished changes still works in a block, it just draws its last published state. "duplicate" copies the bank and all of its items into a new independent bank (editing one never affects the other) in projectId or the key's project, and is the way to change a public template.

Input Schema

TableJSON Schema

Name	Required	Description
`notes`	No	Plain-text notes for this bank, e.g. sourcing/curation instructions - replaces any existing notes. Required for "updateNotes", rejected for every other action.
`title`	No	The new title for "rename", or the title of the copy for "duplicate". Required for both, rejected for every other action.
`action`	Yes	What to do with the bank: "rename" (takes title), "updateNotes" (takes notes), "duplicate" (takes title and optionally projectId) or "publish" (no further parameters).
`projectId`	No	The project (team) ID the copy should land in, as returned by project_list. Only for "duplicate", where omitting it uses the project the API key is scoped to.
`questionBankId`	Yes	The ID of the question bank to act on.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

AddedSep 2, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the spartan annotations, the description discloses crucial behavioral traits: rename/updateNotes are permanent metadata changes unaffected by publish/discard; publish promotes all draft content and purges pending deletions; unpublished changes do not break block rendering; and duplicate creates a fully independent bank. This is exactly the kind of context an agent needs to predict side effects.

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 dense, and nearly every sentence carries load-bearing behavioral information. It is front-loaded with scope and sibling differentiation. The density is justified by the tool's complexity, though a slightly more structured layout would improve scannability.

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 five parameters, four distinct actions, no output schema, and nuanced side effects, the description covers all invocation-critical aspects: parameter-conditional requirements, persistence semantics, publish/discard interaction, and how to change a public template. Nothing needed for correct use appears missing.

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?

Although the schema documents all parameters, the description adds cross-parameter semantics: title is required for both rename and duplicate, notes is required only for updateNotes and rejected elsewhere, projectId applies only to duplicate, and public template IDs are accepted only for duplicate. This materially improves an agent's ability to construct valid calls.

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 defines the tool as the action-dispatching entry point for whole question-bank operations, enumerating the four actions (rename, updateNotes, duplicate, publish). It also differentiates it from sibling tools by explicitly stating items are handled by question_bank_item and destruction by question_bank_delete/question_bank_discard_changes.

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 explicit usage boundaries: item-level changes belong to question_bank_item, destructive operations belong to the two delete/discard siblings, and public template IDs are only valid for duplicate. It also maps each action to its required parameters and effects, so an agent can select the correct action without ambiguity.

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.

Resources

Need Help?