RooQuiz

Get form stats

get_form_stats

Read-only

Read submission statistics for a form in the current team: KPI overview (total / today / last 7 / last 30, unique examinees, anonymous, report status counts, average score, latest submission), daily submission trend, channels (by utm_source), UTM combos, login types (anonymous vs registered), device breakdown, and per-question answer distributions. days only sets the length of the daily trend; every other block counts all submissions ever made. Answer distributions cover only the first 10 SingleCheck / DropDown / Rate / TrueFalse questions in form order (other types, MultiCheck included, are not counted); each bucket carries the choice label next to its stored value. Use this to gauge how a quiz is performing and to suggest improvements.

Input Schema

Name	Required	Description	Default
`days`	No	Length of the daily trend in days, default 30, max 180. Does not filter the other blocks.
`formId`	Yes	The form UUID

Output Schema

Name	Required	Description
`days`	No	Length of the daily trend actually used (other blocks are all-time)
`trend`	No	One entry per day in the window, zero-filled
`formId`	No	The form these stats belong to
`devices`	No	Submissions by device type
`channels`	No	Submissions by utm_source
`overview`	No	KPI block: { totalSubmissions, todaySubmissions, yesterdaySubmissions, last7daysSubmissions, last30daysSubmissions, uniqueExaminees, anonymousSubmissions, reportCompleted, reportFailed, reportPending, avgScore, latestSubmittedAt }
`utmCombos`	No	Submissions by UTM combo
`loginTypes`	No	Anonymous vs registered submissions
`answerDistributions`	No	All-time answer distribution of the first 10 SingleCheck / DropDown / Rate / TrueFalse questions

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 3, 2026

changedInput schema / properties / days / description

Previous value: -"Look-back window in days, default 30, max 180"New value: +"Length of the daily trend in days, default 30, max 180. Does not filter the other blocks."

changedOutput schema / properties / answerDistributions / description

Previous value: -"Per-question answer distribution (choice-style questions only)"New value: +"All-time answer distribution of the first 10 SingleCheck / DropDown / Rate / TrueFalse questions"

addedOutput schema / properties / answerDistributions / items / properties / items / items / properties / label

Added value: +{
+  "description": "Choice text for that value; absent when the value is not a choice code (Rate / TrueFalse)",
+  "type": "string"
+}

changedOutput schema / properties / answerDistributions / items / properties / items / items / properties / value / description
```
Previous value: -"Answer value"New value: +"Stored answer value (a choice code for choice questions)"
```

changedOutput schema / properties / days / description

Previous value: -"Look-back window actually used"New value: +"Length of the daily trend actually used (other blocks are all-time)"

First observedAug 24, 2026

TDQS

A4/5.0

Behavior5/5

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

The annotations already cover the safety profile (readOnly, non-destructive, non-open-world), and the description adds substantive behavioral detail beyond them. It discloses two non-obvious caveats: that `days` affects only the daily trend while all other blocks count all-time submissions, and that answer distributions cover only the first 10 SingleCheck/DropDown/Rate/TrueFalse questions with MultiCheck excluded. That materially changes how an agent interprets the results.

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 output blocks are front-loaded and each clause carries real information, with the caveats grouped after the enumeration and the use case placed last. The middle becomes a dense comma-separated list, but no sentence is wasteful.

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?

Given an available output schema, the description need not spell out return values, yet it still summarizes them well enough for selection. All the behavioral surprises an agent needs to call and interpret this tool correctly are present.

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%, so both parameters are already documented, and the description's note that `days` does not filter other blocks largely echoes the schema's own text. It reinforces rather than adds new meaning, so the baseline holds.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a precise verb+resource ('Read submission statistics for a form in the current team') and then enumerates the exact blocks returned (KPI overview, daily trend, channels, UTM combos, login types, device breakdown, per-question distributions). That is far more specific than the title. It stops short of naming the related sibling such as get_form_funnel, so the agent gets no explicit differentiation among analytics tools.

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?

It supplies one clear usage context ('gauge how a quiz is performing and to suggest improvements'), which is implied guidance rather than explicit routing. It never says when not to use it or how it differs from get_form_funnel or get_form, leaving the agent to infer which analytics endpoint answers a given question.

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

All RooQuiz tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?