Skip to main content
Glama

Riddle

by com.riddle

riddle_delete

Destructive

Deletes one or many Riddles. Only Riddles created through the riddle_builder_* tools or generated by the Riddle AI can be deleted - the ones a user built by hand in the Creator cannot, so check "origin.apiManageable" (riddle_get's context.origin, or riddle_list's "origin") beforehand rather than learning it from the error. Pass UUID for one, or UUIDs (max 100) to clean up several at once - e.g. everything riddle_list returned with origin: "api". A bulk delete is not atomic and never gives up early: a Riddle that cannot be deleted is that entry's "error" and every other Riddle is still deleted (riddle://reference/concepts/bulk). A Riddle another item of the same batch still references (a Leaderboard's connected Quiz/Predictor/Minigame, a FormSelect's Form) is retried once after the rest of the batch, so the order of the list does not matter; only a failure that survives the retry is reported. DRY RUN: pass dryRun: true and NOTHING is deleted - the call runs the same validation a real delete runs and answers {dryRun, deletable, summary, items, addUUIDs} per Riddle. Do this first whenever the set was not created by you; then act on "addUUIDs" to delete the referencing Riddles along with their targets. Every field, the batch effect and which blockers no addition to the call can lift: riddle://reference/concepts/bulk.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
UUIDNoThe UUID of the single Riddle you want to delete. Pass either this or UUIDs. Only Riddles created via the Riddle Builder tools or generated by the Riddle AI can be deleted.
UUIDsNoSeveral Riddles to delete at once, as Riddle UUID strings, e.g. ["6FA740EW", "OllsevHa"] (max 100). Pass either this or UUID. Same restriction as UUID: each one must have been created via the Riddle Builder or generated by the Riddle AI.
dryRunNotrue reports whether each Riddle could be deleted and deletes nothing. Works for one UUID and for UUIDs.

Schema Changelog

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

  1. Changed6 schema fields changed
    • addedInput schema / oneOf
      Added value: +[
+  {
+    "properties": {
+      "UUID": {
+        "not": {
+          "type": "null"
+        }
+      },
+      "UUIDs": {
+        "const": null
+      }
+    },
+    "required": [
+      "UUID"
+    ]
+  },
+  {
+    "properties": {
+      "UUID": {
+        "const": null
+      },
+      "UUIDs": {
+        "not": {
+          "type": "null"
+        }
+      }
+    },
+    "required": [
+      "UUIDs"
+    ]
+  }
+]
    • removedInput schema / properties / UUIDs / definition
      Removed value: -{
-  "items": {
-    "pattern": "^[A-Za-z0-9]{4,32}$",
-    "type": "string"
-  },
-  "maxItems": 100,
-  "minItems": 1,
-  "type": "array",
-  "uniqueItems": true
-}
    • addedInput schema / properties / UUIDs / items
      Added value: +{
+  "pattern": "^\\s*[A-Za-z0-9]{4,32}\\s*$",
+  "type": "string"
+}
    • addedInput schema / properties / UUIDs / maxItems
      Added value: +100
    • addedInput schema / properties / UUIDs / minItems
      Added value: +1
    • addedInput schema / properties / dryRun
      Added value: +{
+  "default": false,
+  "description": "true reports whether each Riddle could be deleted and deletes nothing. Works for one UUID and for UUIDs.",
+  "type": "boolean"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses that bulk deletion is non-atomic, never gives up early, reports per-entry errors, and retries referenced Riddles once. This is exactly the kind of behavioral context that helps an agent predict side effects and partial-failure outcomes.

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 front-loaded with the core action and then layers in necessary eligibility and bulk-behavior details. It is fairly long, and some per-entry error behavior is repeated across sentences, but the length is largely justified for a destructive tool with non-atomic semantics.

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 covers eligibility, single versus bulk usage, non-atomic partial failure, and retry behavior, which is strong for a destructive operation. However, with no output schema present, it does not fully spell out the response shape beyond mentioning per-entry 'error' entries, and dryRun behavior is left entirely to the schema.

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 schema already documents all three parameters with descriptions (100% coverage), so the baseline is 3. The description adds practical guidance by showing how to batch-delete results from riddle_list and by emphasizing the origin-apiManageable precondition, which is not in the schema. It does not re-explain dryRun, but the schema covers that clearly.

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 opens with 'Deletes one or many Riddles,' a specific verb and resource that clearly distinguishes this tool from siblings like riddle_rename or riddle_publish. It also immediately scopes what kinds of Riddles are eligible, so there is no ambiguity about what the tool does.

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 tells the agent when deletion is allowed (builder-created or AI-generated Riddles), how to verify eligibility via origin.apiManageable before calling, and how to pass UUID versus UUIDs with a max of 100. It also explains bulk behavior and retry semantics, leaving little room for guessing.

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

All Riddle toolsInspect
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.4/5.0
Disambiguation5/5

Each tool is scoped to a distinct resource/action area: media, palettes, projects, question banks, Riddles, templates, tags, stats, and support. Potentially close pairs like riddle_tag/riddle_tag_delete and question_bank_delete/question_bank_manage are cleanly separated by their descriptions, so an agent can reliably select the right one.

Naming Consistency4/5

The naming is mostly consistent snake_case with strong resource prefixes like riddle_, question_bank_, and template_, followed by clear verbs. Minor deviations such as question_bank_item, riddle_tag, and stats_fetch break the strict verb-noun pattern but remain predictable once the convention is understood.

Tool Count3/5

At 38 tools this is a heavy surface, though the breadth is justified by the many subdomains the server covers: media, palettes, projects, question banks, Riddles, templates, tags, and stats. Most tools earn their place, but the count sits above the range where an agent can quickly survey all options.

Completeness4/5

The set covers the full lifecycle for Riddles, question banks, templates, and tags, including publish/unpublish, move, stats, and media upload/delete. Minor gaps like no media library listing and read-only project settings are workable because media IDs come from upload responses and project permissions are exposed.

Resources