RooQuiz

List templates

list_templates

Read-only

List active templates in the public template library (id, title, scene, use cases, description, category, recommended flag, usage count), most-used first. Filter by useCase to find templates for a goal across scenes (e.g. "personality" also returns scored_quiz personality tests). Use this to find a template, then call create_form_from_template with its id to create a form from it — the fastest way to build a quiz when a suitable template exists.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_templates"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Items per page, default 20, max 100
`scene`	No	Filter by scene, optional
`useCase`	No	Filter by use case (what the quiz is for), across scenes, optional: personality / recommendation (product or course finder) / assessment / level_test / trivia / ai_report
`categoryId`	No	Filter by category id, optional
`isRecommended`	No	When true, only return recommended templates
`titleContains`	No	Fuzzy match by title, optional

Output Schema

Name	Required	Description
`page`	No	Current page, 1-based (ops endpoint)
`items`	No	The page of templates
`totalDocs`	No	Total templates matching the filter
`totalPages`	No	Total pages at this limit (ops endpoint)
`hasNextPage`	No	Whether another page follows (ops endpoint)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

addedInput schema / properties / useCase

Added value: +{
+  "description": "Filter by use case (what the quiz is for), across scenes, optional: personality / recommendation (product or course finder) / assessment / level_test / trivia / ai_report",
+  "enum": [
+    "personality",
+    "recommendation",
+    "assessment",
+    "level_test",
+    "trivia",
+    "ai_report"
+  ],
+  "type": "string"
+}

Changed2 schema fields changedOct 31, 2026

addedOutput schema / properties / items / items / properties / actualUsageCount

Added value: +{
+  "description": "Real usage count, never overridden by update_template_stats (ops endpoint)",
+  "type": "number"
+}

addedOutput schema / properties / items / items / properties / actualViewCount

Added value: +{
+  "description": "Real view count, never overridden by update_template_stats (ops endpoint)",
+  "type": "number"
+}

Changed3 schema fields changedOct 31, 2026

addedOutput schema / properties / hasNextPage

Added value: +{
+  "description": "Whether another page follows (ops endpoint)",
+  "type": "boolean"
+}

addedOutput schema / properties / page

Added value: +{
+  "description": "Current page, 1-based (ops endpoint)",
+  "type": "number"
+}

addedOutput schema / properties / totalPages

Added value: +{
+  "description": "Total pages at this limit (ops endpoint)",
+  "type": "number"
+}

Changed2 schema fields changedOct 31, 2026

changedInput schema / properties / scene / enum

Previous value: -[
-  "knowledge_quiz",
-  "scored_quiz",
-  "outcome_quiz"
-]New value: +[
+  "knowledge_quiz",
+  "scored_quiz",
+  "outcome_quiz",
+  "ai_quiz"
+]

changedOutput schema / properties / items / items / properties / scene / description

Previous value: -"knowledge_quiz / scored_quiz / outcome_quiz"New value: +"knowledge_quiz / scored_quiz / outcome_quiz / ai_quiz"

First observedAug 24, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: results are limited to *active* templates in a *public* library and are ordered most-used first, neither of which appears in the schema or 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?

Three front-loaded sentences that each carry useful information: scope and fields, filtering guidance, and the recommended next step. The parenthetical field enumeration is long but earns its place by summarizing the result shape.

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?

An output schema exists, so return values need no explanation, yet the description still orients the agent well for a six-parameter list tool. Minor gap: it does not say where categoryId values come from, which an agent would need for that filter.

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?

Schema coverage is 100%, so the baseline is 3. The description goes beyond it by explaining the cross-scene semantics of useCase with a concrete example ("personality" also returns scored_quiz personality tests), which is not derivable from the enum list alone.

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?

States a specific verb and resource (list active templates in the public template library) plus the returned fields and the ordering (most-used first). This is clearly distinct from siblings like list_forms or list_records, which operate on tenant-owned data rather than a public library.

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

Usage Guidelines4/5

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

Explicitly says to use useCase filtering to find templates for a goal across scenes, and names the follow-on call (create_form_from_template with the returned id) as the fastest way to build a quiz when a suitable template exists. The exclusion case — what to do when no suitable template exists — is only implied.

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?