Tjaz

Make a quiz with Tjaz

make_quiz

Tjaz writes a multiple-choice quiz with its own AI from a description of what it's about, for the people who will play it, and gives back a link to play it alone, in a 3D game or together on a big screen, and to share it. Use this when the user asks for a quiz about a subject and hasn't written the questions. Usually ready within a minute; if not, it gives the link where the quiz is being written, and get_quiz tells when it's ready. Tjaz writes it in the language of the description, unless language is given.

Input Schema

TableJSON Schema

Name	Required	Description
`tone`	No	fun: playful; serious: plain; educational: teaches, with three facts between the questions. Default educational
`public`	No	Also show it on tjaz.com/quizzes, where anyone can find it. Default false: only those who get the link can play it
`players`	No	Who will play the quiz. An age group: children (6–12), teens (13–17), adults (18–64), seniors (65+); or, for school, a level: grade0 is the first year of school at about 6 (kindergarten, Danish 0. klasse), grade1 to grade12 the school years after it (grade4 is US Grade 4, Danish 4. klasse, German 4. Klasse, UK Year 5; grade10–grade12 are the last three years of upper secondary school, e.g. Danish 1.g–3.g), then bachelor, master, phd, or nobel for experts. Leave it out when the user didn't say who will play: Tjaz then reads it from the description, as tjaz.com does
`language`	No	Optional: the language to write the quiz in, if not the description's: the language's code as Tjaz has it, ISO 639-1, e.g. da, en, ar, uk, and nb for Norwegian
`questions`	No	How many questions. Default 10
`difficulty`	No	How hard for those who play it. Default medium
`description`	Yes	What the quiz is about, in the user's words, e.g. "Vulkaner til 4.b, vi har læst om Island"
`explanations`	No	Tjaz always explains after each answer why it's right or wrong, so this can be left out

Output Schema

TableJSON Schema

Name	Required	Description
`quiz`	No
`status`	Yes
`message`	No	Why it was refused, or what to tell the user

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the annotations (non-read-only, non-destructive, non-idempotent), the description discloses that generation is AI-driven, usually completes within a minute, and may return an in-progress link that requires polling via get_quiz. That async fallback is genuinely important invocation context. It does not mention rate limits, quota, or what happens on failure.

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

Conciseness3/5

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

Purpose is front-loaded, but the first sentence is bloated with marketing-style clauses ('play it alone, in a 3D game or together on a big screen'), which are output-format details the output schema already covers. The later sentences about timing and language are tighter and earn their 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?

For an 8-parameter generation tool with a rich schema and an output schema, the description supplies the missing pieces an agent needs: call condition, timing expectation, and the get_quiz polling fallback. Nothing critical is absent, though the async failure path is left unspecified.

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 description coverage is 100% and every parameter is well documented in the schema itself, including defaults and enums. The description only restates the language default ('in the language of the description, unless language is given'), which the schema already conveys, so no value is added beyond baseline.

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 names a specific verb and resource ('Tjaz writes a multiple-choice quiz ... from a description'), so an agent knows it generates a new quiz rather than finding, saving, or translating one. The core purpose is clear, though it is wrapped in a long sentence that mixes in output modes and sharing.

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?

'Use this when the user asks for a quiz about a subject and hasn't written the questions' gives an explicit trigger plus an implicit exclusion (if the user already wrote questions, this is not the tool). It also routes the agent to get_quiz for checking readiness, naming the sibling explicitly.

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

All Tjaz 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?