EduBase MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

edubase_get_quiz_results_play

Read-onlyIdempotent

Retrieve detailed results for a single quiz attempt using its play ID, including score, validity, pass status, and per-question points and answer times.

Instructions

Get the detailed results of a single Quiz play (attempt): times, points, validity, whether it passed the grading, and the points and answer time of every question. Play identification strings are returned by edubase_get_quiz_results_user and edubase_get_exam_results_user.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`play`	Yes	Quiz play identification string

Output Schema

TableJSON Schema

Name	Required	Description	Default
`play`	Yes
`user`	Yes
`valid`	Yes
`time_end`	Yes
`questions`	Yes
`successful`	Yes
`time_start`	Yes
`points_total`	Yes
`points_correct`	Yes
`questions_total`	Yes
`questions_correct`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedv2.0.0Sep 15, 2026
- removedOutput schema / properties / play / description
```
Removed value: -"Quiz play identification string"
```
- removedOutput schema / properties / points_correct / description
```
Removed value: -"total points scored"
```
- removedOutput schema / properties / points_total / description
```
Removed value: -"total points"
```
- removedOutput schema / properties / questions / items / properties / id / description
```
Removed value: -"external unique question identifier (if present)"
```
- removedOutput schema / properties / questions / items / properties / index / description
```
Removed value: -"question index"
```
- removedOutput schema / properties / questions / items / properties / points / description
```
Removed value: -"points scored"
```
- removedOutput schema / properties / questions / items / properties / points_maximum / description
```
Removed value: -"maximum points"
```
- removedOutput schema / properties / questions / items / properties / question / description
```
Removed value: -"question identification string"
```
- removedOutput schema / properties / questions / items / properties / time_answer / description
```
Removed value: -"number of seconds spent on question (if available)"
```
- removedOutput schema / properties / questions_correct / description
```
Removed value: -"number of correctly answered questions"
```
- removedOutput schema / properties / questions_total / description
```
Removed value: -"total number of questions asked"
```
- removedOutput schema / properties / successful / description
```
Removed value: -"attempt passed grading threshold (if applicable)"
```
- removedOutput schema / properties / time_end / description
```
Removed value: -"end time"
```
- removedOutput schema / properties / time_start / description
```
Removed value: -"start time"
```
- removedOutput schema / properties / user / description
```
Removed value: -"user identification string"
```
- removedOutput schema / properties / valid / description
```
Removed value: -"result is valid"
```
Addedv1.1.2Mar 13, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds meaningful behavioral context by detailing the returned aspects like validity, grading pass/fail, and per-question timing, which is useful beyond the annotation data. No contradictions with annotations.

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 description is two well-organized sentences: the first front-loads the action and the detailed content, and the second provides essential identifier provenance. There is no redundant phrasing or unnecessary detail.

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 a single required parameter, full schema coverage, strong safety annotations, and an output schema, the description covers everything needed to invoke the tool correctly. It also supplies the necessary upstream context for obtaining the play ID, making it complete for this simple read operation.

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% and the single parameter 'play' is described as a 'Quiz play identification string'. The description enhances this by explaining where such identifiers come from, giving the agent concrete provenance for the required value. This goes beyond the bare schema definition.

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 states a specific verb ('Get') and a precise resource ('detailed results of a single Quiz play (attempt)'), and enumerates exactly what data is included: times, points, validity, pass/fail, and per-question points and answer time. It also implicitly differentiates from sibling result-listing tools by emphasizing 'single' play and referencing the user-level result functions.

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?

The description clearly indicates when to use this tool by noting that play identification strings come from edubase_get_quiz_results_user and edubase_get_exam_results_user, establishing a prerequisite flow. It does not explicitly state exclusions or when-not-to-use, but the context is clear enough for an agent to sequence calls correctly.

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

Deploy Server