EduBase MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

edubase_post_exam_results_export

Read-only

Generate a time-limited, single-use export link for exam results, including only visible examinees per configured settings. Requires reporting permission.

Instructions

Generate a download link for the results of an exam. The generated link is not authenticated, so it can be handed over to any service, but it can only be used once and it expires in an hour. Only those examinees are exported that are visible for the current user, and the exported columns are controlled by the export settings of the exam (see edubase_get_exam_settings). Exporting the results needs reporting permission for the exam.

Input Schema

TableJSON Schema

Name	Required	Description
`exam`	Yes	exam identification string
`sort`	No	ordering of the examinees in the exported file (default: the same order they are listed in on the users page of the exam, name: by the name of the examinees), default: the export_sort setting of the exam
`round`	No	export the results of a previous round instead of the current one, only available when the exam is configured to keep the results of its previous rounds, has to be the number of an already closed round (see edubase_get_exam_round)
`format`	No	format of the exported file (csv: semicolon separated values, xlsx: Excel 2007+ workbook), default: the export_format setting of the exam
`preset`	No	content of the exported file (default: the examinees with their results, answers: the answers only, without the examinees), the answers preset is only available for anonymous surveys (default: default)
`filters`	No	only export the examinees matching the given user data, keyed by the label of a custom user data field of the exam (see edubase_get_exam_fields), only those select custom fields can be used that have their filtering configured, the value is one of the filterable options of the field or a list of them, the examinees have to match any of the values given for the same field and all of the fields specified, cannot be combined with round as the results of a previous round cannot be filtered
`language`	No	language of the exported file (default: the language of the user)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`exam`	Yes
`valid`	Yes
`format`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv2.0.0Sep 15, 2026
- removedOutput schema / properties / exam / description
```
Removed value: -"exam identification string"
```
- removedOutput schema / properties / format / description
```
Removed value: -"format of the exported file"
```
- removedOutput schema / properties / url / description
```
Removed value: -"download link for the results"
```
- removedOutput schema / properties / valid / description
```
Removed value: -"date and time of link expiration"
```
Addedv1.2.15Sep 2, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Beyond annotations (readOnlyHint, destructiveHint), the description discloses key behaviors: the link is unauthenticated, single-use, expires in an hour, exports only visible examinees, and is controlled by exam settings. It also states the permission requirement. No contradiction with annotations; readOnlyHint is consistent since no data mutation occurs.

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?

The description is compact, starting with the main action, then elaborating on link properties, scope, and permissions. It avoids redundancy and effectively uses the available space, though it could benefit from clearer segmentation of distinct points.

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?

With a full output schema and complete parameter descriptions, the description covers all essential aspects: what the tool does, link characteristics, permission requirements, and scope limitations. It references related tools for further context, making it sufficient for an agent to invoke correctly.

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%, so all parameters are already documented in the schema. The tool description adds no parameter-specific information beyond what the schema provides, such as the round availability constraint or preset restrictions, which are already in the schema. Baseline of 3 is appropriate.

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 clearly states the tool generates a download link for exam results, specifying the verb and resource. It also differentiates from sibling result tools by focusing on the export link rather than direct data retrieval, making its purpose unambiguous.

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

Usage Guidelines3/5

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

The description mentions a precondition (reporting permission) and references related tools (edubase_get_exam_settings, edubase_get_exam_round) for context, but it does not explicitly explain when to use this tool versus alternatives like edubase_get_exam_results_user or edubase_get_exam_results_raw. The usage context is implied but not fully explicit.

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

Deploy Server