moodle-um

moodle_quiz_solve

Saves answers for one Moodle quiz page using question numbers or choice labels, letting you prepare responses without submitting the attempt.

Instructions

Save answers for one quiz page, using question numbers or choice labels.

answers maps a question number (for example "1") to a choice label/value ("b", "4", "True") or a list for multiple-response questions, and/or a raw Moodle input name to its value. It saves the page; it does not submit the attempt. Show the questions and proposed answers to the user first.

Args: attemptid: quiz attempt id. answers: question-number/label map, or raw input-name map. page: optional zero-based page number.

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": {
      "attemptid": "<attemptid>",
      "answers": "<answers>"
    },
    "name": "moodle_quiz_solve"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No
`answers`	Yes
`attemptid`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.1Nov 12, 2026

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so the description carries the full burden. It discloses the important save-vs-submit distinction and the confirmation-before-write expectation, but says nothing about whether re-saving a page overwrites prior answers, what happens on an invalid label, or what a successful save returns.

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?

Front-loaded with the core action and format rules, then the safety caution. The Args block partly duplicates the schema but adds format meaning; no sentence is gratuitous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a 3-parameter mutation tool with no annotations and no output schema, since the save/submit boundary and answer encoding are covered. It still leaves overwrite semantics, error behavior, and the return value unaddressed, which matters more than usual given the absence of annotations.

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 0%, so the description must compensate, and it does well for `answers` (two accepted key styles, scalar vs list for multiple-response, concrete examples). `attemptid` is only restated as "quiz attempt id" and `page` gains only "zero-based", leaving origin and default behavior partly unexplained.

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 ("Save answers for one quiz page") with the accepted key/value formats spelled out (question number to choice label, or raw Moodle input name). The closing clause "It saves the page; it does not submit the attempt" separates it from the submit sibling without ambiguity.

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 carves out the boundary against submitting and adds a workflow prerequisite ("Show the questions and proposed answers to the user first"). It stops short of naming the sibling tool to use for finalizing the attempt, so routing is implied rather than fully prescribed.

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