Riddle Quiz Maker

project_list

Read-onlyIdempotent

Returns a paginated list of projects this token has access to (25 per page by default, 100 max), with a sibling "pagination" object ({page, pageSize, total, hasMore}) to page through accounts with many projects. If it is a project API token, only the project linked to the token will be returned. Each project is a trimmed summary (id, name, image) - use project_get for a single project incl. your permissions on it, and project_get_settings for its default Riddle settings. An invalid page/pageSize (zero, negative, or a pageSize over 100) is rejected outright rather than silently clamped - the same contract as questionBank_list/questionBank_getItems.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`page`	No	Page number to fetch (1-indexed). Defaults to 1. Zero, negative or non-numeric is rejected, not clamped.
`pageSize`	No	How many projects to return per page (max 100). Defaults to 25. Same validation as page; over 100 is rejected, not clamped.

TDQS

A5/5.0

Behavior5/5

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

Annotations (readOnlyHint, idempotentHint) are enriched by description: pagination defaults (25 per page, max 100), trimmed summary fields (id, name, image), token-type behavior (project API token returns only linked project), and strict rejection rather than clamping of invalid page/pageSize. No contradiction with annotations.

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?

Four sentences, each packing essential information: result type, pagination object, token special case, summary + pointers to detailed endpoints, and validation contract. No filler or redundancy.

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?

With no output schema, the description compensates by describing the pagination object and summary fields. It covers pagination semantics, edge cases, token behavior, and related endpoints, making the tool fully actionable for an agent.

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 schema description coverage is 100%, the description adds behavioral semantics: null defaults to 25/page 1, max 100, and rejection behavior. It also clarifies the pagination response object structure (page, pageSize, total, hasMore), which the schema doesn't fully express.

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 states 'Returns a paginated list of projects this token has access to' with specific scope (token-based access) and pagination details. It clearly distinguishes itself from siblings by mentioning project_get (single project with permissions) and project_get_settings (default settings).

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?

Explicitly names alternatives: 'use project_get for a single project incl. your permissions on it, and project_get_settings for its default Riddle settings.' It also contextualizes pagination usage ('page through accounts with many projects') and cites the same validation contract as questionBank_list/questionBank_getItems.

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?