moodle-um

moodle_quiz_start

Starts or resumes a Moodle quiz attempt and returns its questions, choices, timer, and answer input names; use only when the user explicitly asks to take the quiz.

Instructions

Start or resume a quiz attempt and return its questions and choices.

Creates a real attempt on Moodle (it does not submit it). Starting a quiz can consume one of your allowed attempts, so only call this when the user explicitly asks to start or take the quiz. The result contains the attempt id, page, timer, question text, choices and the exact input names to answer with. If Moodle requires a password, an honour statement or Safe Exam Browser, the result says so instead of starting.

Args: cmid: course-module id of the quiz.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "cmid": "<cmid>"
    },
    "name": "moodle_quiz_start"
  }
}

Input Schema

Name	Required	Description	Default
`cmid`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.1Nov 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description fully carries the burden: it states a real attempt is created on the server, that it is not submitted, that it consumes an allowed attempt, and what the response contains (attempt id, page, timer, question text, choices, exact input names). It also discloses blocked cases — password, honour statement, or Safe Exam Browser required — where the result reports the requirement instead of starting.

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?

The summary sentence and return-value list are front-loaded, followed by the side-effect warning and the exception cases, with no filler. Each sentence adds a distinct fact: what it does, what it does not do, its cost, its return shape, and its failure modes.

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?

For a one-parameter, non-annotated tool with no output schema, the description covers purpose, side effects, return contents, and blocked-precondition behavior — everything an agent needs to decide whether and how to call it. Nothing material is left to inference except cmid sourcing.

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 0% and the only parameter is a bare integer named 'Cmid', so the description's 'cmid: course-module id of the quiz' supplies the essential meaning. It stops short of explaining where an agent obtains a cmid or its format, which limits it to a 4 rather than a 5.

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 opens with a specific verb and resource: 'Start or resume a quiz attempt and return its questions and choices.' It also implicitly distinguishes itself from moodle_quiz_submit by noting it does not submit the attempt, so an agent can tell what this tool does and does not do without opening the schema.

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?

It gives an explicit trigger condition ('only call this when the user explicitly asks to start or take the quiz') and a concrete cost-based reason to avoid speculative calls ('can consume one of your allowed attempts'). While it does not name sibling tools as alternatives, the when-to-use and when-not-to-use guidance is unambiguous.

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