EduBase MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

edubase_post_exam_users_generate

Generate exam accounts from patterns and assign them to an exam, using placeholders for names, usernames, passwords, and indexes. Solves bulk account creation for scheduled exams.

Instructions

Generate exam accounts from patterns and assign them to an exam. The following placeholders can be used in the patterns: {index} (the index of the generated account), {random:N} (a random alphanumeric string of N characters, unambiguous characters only in passwords), {number:N} (a random numeric string of N characters), {name} and {Name} (the name of the account, only when names is specified, as given and capitalized) and {username} (the generated username, in the name pattern only). Patterns are stored with the exam and reused as defaults for the next call.

Input Schema

TableJSON Schema

Name	Required	Description
`exam`	Yes	exam identification string
`name`	No	full name pattern, defaults to the pattern used previously for this exam, mandatory if the exam has no previously used pattern
`count`	No	number of accounts to generate, between 1 and 500, ignored when names is specified (default: 1)
`names`	No	list of names to generate the accounts for, either a list or a comma or newline separated string, the number of accounts generated is the number of names specified and count is ignored
`start`	No	index to start the generation at (default: the index after the previously generated accounts, 1 for the first call)
`emails`	No	list of email addresses for the generated accounts, either a list or a comma or newline separated string, only used together with names and the number of items must match the number of names, invalid addresses are replaced with a generated one
`password`	No	password pattern, defaults to the pattern used previously for this exam, mandatory if the exam has no previously used pattern
`username`	No	username pattern, defaults to the pattern used previously for this exam, mandatory if the exam has no previously used pattern

Output Schema

TableJSON Schema

Name	Required	Description	Default
`exam`	Yes
`users`	Yes
`failed`	No
`duplicate`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv2.0.0Sep 15, 2026
- removedOutput schema / properties / duplicate / description
```
Removed value: -"usernames that were skipped because the same account was being generated by a parallel request at the same time (only present if there are any)"
```
- removedOutput schema / properties / exam / description
```
Removed value: -"exam identification string"
```
- removedOutput schema / properties / failed / description
```
Removed value: -"usernames of the accounts that could not be created (only present if there are any)"
```
- removedOutput schema / properties / users / items / properties / name / description
```
Removed value: -"full name of the generated account"
```
- removedOutput schema / properties / users / items / properties / password / description
```
Removed value: -"password of the generated account (if available)"
```
- removedOutput schema / properties / users / items / properties / user / description
```
Removed value: -"user identification string"
```
- removedOutput schema / properties / users / items / properties / username / description
```
Removed value: -"username of the generated account"
```

Changed2 schema fields changedv1.2.17Sep 15, 2026

addedOutput schema / properties / duplicate

Added value: +{
+  "description": "usernames that were skipped because the same account was being generated by a parallel request at the same time (only present if there are any)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / failed

Added value: +{
+  "description": "usernames of the accounts that could not be created (only present if there are any)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Addedv1.2.15Sep 2, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the annotations, the description reveals important behavioral details: patterns are stored with the exam and reused as defaults, invalid email addresses are replaced, and count is ignored when names are specified. It adds meaningful side-effect context, though it does not cover authentication, rate limits, or all possible failure modes.

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 dense but efficient: it front-loads the core purpose and then packs the placeholder rules and cross-parameter behavior into a single paragraph. It could be improved with bullet points for readability, but every clause contributes real information.

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?

Given the output schema exists and all parameters have schema descriptions, the tool description covers the essential generation semantics, placeholder grammar, and stateful pattern reuse. It does not explicitly guide the agent toward this tool versus the sibling creation tool, but for the tool's own mechanics it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already documents every parameter, the description adds substantial meaning by defining the placeholder vocabulary and the rules linking parameters: {index}, {random:N}, {name}, {username}, count being ignored with names, emails requiring matching names, and defaults carried from previous calls. This goes well beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence clearly states the action ('Generate'), the resource ('exam accounts'), and the outcome ('assign them to an exam'). It is unambiguous, but it does not explicitly contrast with the sibling edubase_post_exam_users, so it stops short of full sibling differentiation.

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 implies when to use the tool—when exam accounts need to be generated from patterns—and explains pattern persistence and defaults. However, it provides no explicit guidance on when to prefer this over edubase_post_exam_users or when not to use it, leaving usage mostly implicit.

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

Deploy Server