Skip to main content
Glama
Sign In
EduBase

EduBase MCP Server

Official
by EduBase
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

edubase_get_exam_journey

Read-onlyIdempotent

Retrieve the status of an exam-started learning journey, including user counts per step, current statuses, and outcomes of completed paths for visible organizational members.

Instructions

Get the status of the journey started by an exam: the number of users at the steps, their statuses, and the outcomes of the finished journeys. Exam journeys chain exams, classes and Quiz sets into a learning path with decisions, starting when the users start the exam. Only the visible organizational members are counted. Use edubase_get_exam_journey_user for a single user and edubase_get_exam_journey_graph for the structure.

Input Schema

NameRequiredDescriptionDefault
examYesexam identification string (the starting exam)

Output Schema

NameRequiredDescriptionDefault
examYes
stepsYes
usersYes
activeYes
statusYes
journeyYes
outcomesYes
publishedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.10
    • addedOutput schema / properties / steps / items / properties / contents
      Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "class": {
+        "type": "string"
+      },
+      "exam": {
+        "type": "string"
+      },
+      "id": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "quiz": {
+        "type": "string"
+      },
+      "title": {
+        "type": "string"
+      },
+      "type": {
+        "enum": [
+          "exam",
+          "class",
+          "quiz"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "type",
+      "title"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  2. Addedv2.0.6

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds real behavioral context beyond them: it explains what an exam journey is (a chained learning path of exams, classes and Quiz sets with decisions, triggered when users start the exam) and the important scoping rule that only visible organizational members are counted.

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 outcome, followed by the domain explanation, the counting caveat, and the sibling routing in a logical order. Four sentences with no filler, though the middle explanatory sentence is slightly longer than strictly needed for an agent that already knows the domain.

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 an output schema present, the description need not document the response shape, and it still summarizes it usefully. Combined with the member-visibility caveat and the explicit sibling routing, an agent has enough to call this correctly; only aggregation or time-window behavior is left unstated.

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?

There is a single required parameter with 100% schema description coverage, so the schema already documents it as the starting exam identifier. The description adds only the framing of "the journey started by an exam" and no format, ID-source, or error semantics beyond the schema, so the baseline of 3 applies.

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 ("Get the status of the journey started by an exam") and then enumerates exactly what is returned: user counts per step, statuses, and outcomes of finished journeys. It is immediately distinguishable from the sibling journey tools because the description names them and assigns them different scopes.

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?

Explicitly routes the agent: use edubase_get_exam_journey_user for a single user and edubase_get_exam_journey_graph for the structure, leaving this tool for aggregate status across users. The condition selecting each alternative is stated, not implied.

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

Deploy Server

Other Tools