Skip to main content
Glama

question_bank_delete

Destructive

Deletes a question bank and every item it holds (its tags cleaned up exactly as question_bank_tag_remove does) - one item alone is question_bank_item_delete. Rejected with QUESTION_BANK_INTERDEPENDENCY while a Riddle of the bank's own project still references it - counting the DRAFT and, on a published Riddle, the live version too, so a block removed from a draft does not release the bank until that Riddle is republished; read "deletingABank" in riddle://reference/question-bank/overview before deleting one. Permanent: there is no trash and no restore. Rejected for a public template id - a template is copied with question_bank_duplicate, never deleted. Needs full access: riddle://reference/concepts/access.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "questionBankId": "<questionBankId>"
    },
    "name": "question_bank_delete"
  }
}

Input Schema

NameRequiredDescriptionDefault
questionBankIdYesThe ID of the question bank to delete.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / questionBankId / description
      Previous value: -"The ID of the question bank to delete, or of the bank the item belongs to."New value: +"The ID of the question bank to delete."
    • removedInput schema / properties / questionBankItemId
      Removed value: -{
      -  "default": null,
      -  "description": "The ID of the item to delete, as returned by question_bank_get_items or question_bank_item(action: \"add\"). Required for target \"item\", rejected for \"bank\".",
      -  "type": [
      -    "null",
      -    "integer"
      -  ]
      -}
    • removedInput schema / properties / target
      Removed value: -{
      -  "description": "What to delete: \"bank\" (the bank itself and every item in it) or \"item\" (one question of it).",
      -  "enum": [
      -    "bank",
      -    "item"
      -  ],
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "questionBankId",
      -  "target"
      -]New value: +[
      +  "questionBankId"
      +]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety bar is partly covered — but the description goes well beyond: tag cleanup semantics matching question_bank_tag_remove, the counterintuitive DRAFT-vs-published-version reference counting (a block removed from a draft still holds the bank until republish), irreversibility ("no trash and no restore"), and the access requirement. These are non-obvious behaviors an agent cannot infer from structured fields.

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?

Front-loaded with the verb and blast radius, then layered with constraints; nearly every clause carries operational weight (error code, permanence, template rule, doc pointer). It is dense in a way that suits a destructive tool, though the DRAFT/republish parenthetical is long enough to slightly slow scanning.

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?

No output schema exists, so the description must carry the full burden — and it does: what is destroyed, what is cleaned up, what blocks it, what is permanent, what requires elevated access, and where to read more. Nothing material for a correct, safe invocation is missing.

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?

Only one parameter (questionBankId) with 100% schema description coverage, so the schema fully documents it. The description adds no format, ID-source, or validation detail beyond it. Baseline 3 is appropriate when the schema does the work and nothing extra is offered.

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?

States a specific verb and resource ("Deletes a question bank") plus the cascade scope ("every item it holds"), and explicitly contrasts with the nearest sibling: "one item alone is question_bank_item_delete". An agent can distinguish this from question_bank_discard_changes, question_bank_item_delete, and riddle_delete without opening a schema.

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?

Gives concrete when-not conditions with the exact rejection code (QUESTION_BANK_INTERDEPENDENCY) and an alternative path for templates ("a template is copied with question_bank_duplicate, never deleted"). It also points to a specific reference doc section to read before deleting, which is exactly the routing guidance an agent needs for a destructive operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources