Skip to main content
Glama

riddle_move

Moves one or many Riddles into another project, or into the personal project when projectId is omitted. Pass UUID for a single Riddle or UUIDs (array of Riddle UUID strings, max 100) for several at once; use project_list to find the target projectId, and riddle_list/riddle_account_list to find the Riddles. Unlike the other bulk tools this validates the whole set BEFORE moving anything and moves nothing at all if any Riddle is rejected, because Riddles that reference each other (a Quiz and the Leaderboard it reports to, a Form embedded in another Riddle) can only move together: not every Riddle can be moved on its own, and the error names both the rejected Riddles and the exact connected Riddles to add to UUIDs, which is all it takes to make the same call work. Call riddle_move_check first (same UUIDs, changes nothing) to see which Riddles are blocked, which connected Riddles are missing from the set, and which projects the whole set can go to at all. Moving also requires the transfer permission in both the source and the target project; it does not adopt the new project's design - the Riddle keeps its current preset/look as-is - but it does drop project-specific ad blocks tied to the old project, and the published version is updated along with the draft. Returns {bulk, operation, summary, results} with the new project per Riddle.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
UUIDNoThe UUID of the single Riddle you want to move. Pass either this or UUIDs.
UUIDsNoSeveral Riddles to move at once, as Riddle UUID strings, e.g. ["6FA740EW", "OllsevHa"] (max 100). Pass either this or UUID.
projectIdNoThe project (team) ID to move the Riddles into, as returned by project_list. Omit or pass null to move them to your personal project instead.

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the minimal annotation (idempotentHint: false), the description discloses extensive behavioral details: it validates the entire set before moving, moves nothing if any Riddle is rejected, explains why (dependency chains), mentions that it requires transfer permission in both source and target, notes that it does not adopt the new project's design, drops old ad blocks, and updates the published version. It also details the error response and return format, giving a complete picture of side effects and behavior.

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 dense but well-structured. It contains multiple sentences, each adding critical information: purpose, usage, validation behavior, permissions, side effects, and return format. While it is long, it avoids redundancy and every sentence earns its place. A slight restructure into bullet points could improve scannability, but the logical flow is clear and efficient for the complexity.

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?

The description is remarkably complete for a tool with no output schema. It covers prerequisites (permissions, finding project and Riddle IDs), error handling (validation failure, dependency resolution), side effects (ad blocks dropped, published version updated), and the return structure. It also explains how to use the related check tool (riddle_move_check) to avoid failed moves. There are no evident gaps for an agent to use this tool correctly without additional information.

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 provides 100% coverage for all three parameters (UUID, UUIDs, projectId) with clear definitions. The description adds value by clarifying the relationship between them (pass either UUID or UUIDs), the max limit of 100, and how to obtain projectId via project_list. It also explains the personal-project behavior when projectId is omitted. This exceeds the baseline of 3 given high schema coverage, earning a 4.

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 moves Riddles into a project, including the personal project when projectId is omitted. It specifies the verb (Moves), the resource (Riddles), and the destination, distinguishing it from sibling tools like riddle_move_check, which only checks. The purpose is fully explicit and actionable.

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 when-to-use guidance, including how to pass single vs. multiple Riddles, how to find projectId via project_list, and to obtain Riddles via riddle_list. It explicitly recommends calling riddle_move_check first to preview blocked Riddles, and explains that this tool validates all before moving. It also covers prerequisites like transfer permissions, making it clear 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Tools are largely distinct by name and detailed descriptions, with clear prefixes (riddle_builder_*, questionBank_*, stats_*). Some potential confusion exists among the stats tools (stats_fetch vs stats_overview_fetch vs breakdowns) but descriptions clarify their different scopes. Overall, an agent can usually pick the right tool.

Naming Consistency4/5

Naming follows a predictable prefix+verb pattern within each domain (e.g., riddle_builder_quiz, riddle_builder_poll; riddle_get, riddle_publish). Minor inconsistencies exist, like the camelCase 'questionBank' and 'riddleTemplate' prefixes vs snake_case elsewhere, and 'stats_overview_fetch' ordering, but these are not chaotic and remain readable.

Tool Count1/5

With 62 tools, this far exceeds the recommended 3-15 range and even the 25+ threshold. While the server covers a broad domain, the extreme number overwhelms and makes tool selection harder, fitting the 'extreme mismatch' criterion for 50+ tools.

Completeness5/5

The tool surface is exceptionally comprehensive, covering creation, reading, updating, deleting, publishing, unpublishing, moving, tagging, template management, question banks, palettes, and various stats breakdowns. There are no obvious gaps in the lifecycle of managing interactive content, and all apparent operations are supported.

Resources