Riddle Quiz Maker

riddle_list

Read-onlyIdempotent

Returns a paginated list of Riddles from a single project. Use projectId to specify the project, or omit it to list from the personal project. For Riddles across all projects, use riddle_account_list instead.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number, 1-indexed, 12 Riddles per page (default: 1). Zero or negative is rejected with a VALIDATION_ERROR, not clamped to page 1 - the same contract as project_list/questionBank_list.
`tags`	No	Filter by tag IDs (array of integers). Omit to ignore tags.
`type`	No	Filter by Riddle type (array of strings). Valid values: "Quiz", "Poll", "Form", "Personality", "Predictor", "Minigame", "Leaderboard", "Placeholder", "Story". Omit to include all types.
`origin`	No	Filter by how the Riddle was created: "api" (built via the Riddle Builder API or generated by the Riddle AI, so riddle_delete/riddle_builder_update/palette_customize work on it) or "manual" (created by hand in the Creator, where those three are rejected). Omit to include both. Filter value only: the "origin" field returned per Riddle is an object {builder, aiGenerated, apiManageable}, not one of these strings.
`search`	No	Search term to filter Riddles by title
`sortBy`	No	Sort field: "created", "published", or "modified"
`status`	No	Filter by status: "published", "modified", or "draft". Omit to include all statuses.
`notType`	No	Exclude specific Riddle types (array of strings, same valid values as type). Omit to exclude nothing.
`projectId`	No	Filter by project ID; omit or null for the authenticated user's personal project
`sortOrder`	No	Sort direction: "ASC" or "DESC"

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the useful 'single project vs personal project' scope distinction, but does not add further behavioral context such as auth requirements or response-shape caveats beyond what the schema already supplies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no filler. The core function is front-loaded, the projectId behavior is stated concisely, and the sibling alternative is routed cleanly. Every sentence earns its place.

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?

All 10 parameters are fully described in the schema, and the annotations cover safety, so the description doesn't need to restate those. It gives the essential project-scoping and alternative routing. A small gap is that it doesn't give a hint about the contents of the returned Riddle objects, but with no output schema that is a minor omission for a list endpoint.

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%, with detailed descriptions for every parameter (page 1-indexed, type valid values, origin semantics, sort options). The description only rephrases the projectId behavior already present in the schema, so it adds no additional parameter-level semantics.

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?

'Returns a paginated list of Riddles from a single project' is a specific verb-resource-scope statement. It also immediately differentiates itself from riddle_account_list, making the primary purpose unmistakable.

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 names exactly when to use this tool (project-specific lists) and when to choose an alternative (across all projects → riddle_account_list). It also clarifies the omit-projectId behavior for personal projects, giving an agent direct decision guidance.

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.

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

Need Help?