Skip to main content
Glama
EduBase

EduBase MCP Server

Official
by EduBase
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

edubase_get_exam_autologin

Read-onlyIdempotent

Retrieve an exam's automatic login settings, including enabled status, PIN, login and results links, and whether accounts are generated or registered users can join automatically.

Instructions

Get the automatic login configuration of an exam: whether it is enabled, the PIN code, the login and results links, and whether exam accounts are generated or registered users can join automatically.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
examYesexam identification string

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pinNo
urlNo
examYes
autoaddNo
autojoinNo
autologinYes
results_urlNo
autojoin_limitedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.0.3
    • addedOutput schema / properties / pin / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedOutput schema / properties / pin / type
      Removed value: -"string"
  2. Changed8 schema fields changedv2.0.0
    • removedOutput schema / properties / autoadd / description
      Removed value: -"new exam accounts are generated automatically on demand (only present if autologin is true)"
    • removedOutput schema / properties / autojoin / description
      Removed value: -"already registered users can join the exam automatically (only present if autologin is true)"
    • removedOutput schema / properties / autojoin_limited / description
      Removed value: -"automatic joining is limited to the assigned users (only present if autojoin is true)"
    • removedOutput schema / properties / autologin / description
      Removed value: -"automatic login is enabled"
    • removedOutput schema / properties / exam / description
      Removed value: -"exam identification string"
    • removedOutput schema / properties / pin / description
      Removed value: -"PIN code of the exam (only present if autologin is true)"
    • removedOutput schema / properties / results_url / description
      Removed value: -"URL where examinees can look up their own results (only present if autologin is true and results can be viewed with an identifier)"
    • removedOutput schema / properties / url / description
      Removed value: -"login URL of the exam, the shortlink or the Safe Exam Browser launch URL if configured (only present if autologin is true)"
  3. Addedv1.2.15

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds the nature of the returned configuration (PIN, links, generated accounts), but does not disclose anything else behavioral such as auth requirements or whether the config can be absent.

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?

One front-loaded sentence with no preamble or filler. It is somewhat list-heavy in the second half, but every clause maps to a real aspect of the configuration being retrieved.

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 explain return structure, and for a single-parameter read-only tool the definition is nearly sufficient. The only gap is the absence of routing guidance against the sibling autologin and exam-settings tools.

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?

Only one parameter (exam) with 100% schema description coverage, so the schema carries the semantics. The description adds no detail about the exam identifier format or lookup behavior; baseline 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 (Get) and a precise resource (automatic login configuration of an exam), and the enumeration of returned fields (enabled flag, PIN, login/results links, account generation mode) sharply distinguishes it from siblings like edubase_get_exam_settings and edubase_post_exam_autologin.

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?

Usage is only implied: an agent can infer this is the read side of the autologin resource, but the description never says when to call it versus edubase_get_exam_settings or that edubase_post_exam_autologin/edubase_delete_exam_autologin are the write counterparts. No prerequisites or exclusions are given.

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