Riddle

stats_riddle_breakdown

Read-onlyIdempotent

Returns a detailed stats breakdown for a specific Riddle, including titles, choices, views, time spent, and submissions. Every "id" in this breakdown (blocks, choices, results, form fields) is the same stored block id that riddle_get's "build" configuration exposes as its "id", so entries can be cross-referenced directly - e.g. to look up a block's full definition or to write back to it. These ids are stable identifiers, not a display order: they are assigned once per block and are not renumbered when other blocks are added or removed, so it is normal for them to be non-contiguous (e.g. starting above 1, or with gaps) on a Riddle that has been edited over time.

Input Schema

TableJSON Schema

Name	Required	Description
`dateTo`	No	End date (inclusive), format: YYYY-MM-DD, e.g. "2026-01-31". Optional.
`dateFrom`	No	Start date (inclusive), format: YYYY-MM-DD, e.g. "2026-01-01". Optional.
`riddleUUID`	Yes	UUID of the Riddle you want the stats breakdown for

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description need not repeat that. However, it adds important behavioral context about IDs being stable, non-contiguous, and cross-referencable with riddle_get, which is valuable beyond the annotations.

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 two sentences, front-loaded with the core purpose and followed by a detailed but relevant explanation of ID behavior. It is moderately concise and every sentence adds value, though the ID explanation could be slightly tighter.

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?

With no output schema provided, the description carries the burden of explaining return content—it lists what is included (titles, choices, views, time spent, submissions) and clarifies ID semantics. This is sufficient for a read-only stats tool, though a bit more detail on the response structure could elevate it.

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% for all three parameters (riddleUUID, dateFrom, dateTo), so the schema fully documents them. The description does not add any additional parameter semantics beyond what the schema already provides, meeting the baseline for high coverage.

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 'Returns a detailed stats breakdown for a specific Riddle' with a list of included metrics (titles, choices, views, time spent, submissions). It unambiguously distinguishes from siblings like stats_overview_fetch or stats_project_breakdown by focusing on a single Riddle.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for per-Riddle stats but does not explicitly state when to use it over alternatives like stats_overview_fetch or stats_project_breakdown. It provides context for cross-referencing with riddle_get but no direct guidance on tool selection.

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

All Riddle 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

A4.1/5.0

Disambiguation5/5

Each tool has a clear, unique purpose. The riddle_builder_* variants are distinct by Riddle type, questionBank_* and riddleTemplate_* cover separate objects, and stats_* differ by scope. No two tools appear to perform the same function.

Naming Consistency4/5

Naming is largely consistent with domain prefixes (riddle_, questionBank_, riddleTemplate_, stats_, project_, palette_, reference_). Minor deviations like riddle_account_list vs. riddle_list and whoami (no prefix) and riddle_get_embed_code vs. riddle_qr_code slightly break the pattern, but overall it is predictable.

Tool Count2/5

With 62 tools, the server is far beyond the typical 3-15 well-scoped range. While each tool is functional and the breadth reflects the platform's complexity, the sheer number makes it heavy and increases the cognitive load for an agent, suggesting over-granularity.

Completeness5/5

The tool set covers the full lifecycle: create (builder variants), read (get/list), update (builder_update, rename), delete, publish/unpublish, tagging, templates, question banks, stats, projects, palettes, and reference documentation. No obvious domain operation is missing.

Resources

Need Help?