EduBase MCP Server

Official

Overview Schema Related Servers Score Discussions

edubase_post_user

Create new EduBase user accounts with required username, name, and email, and configure optional settings for groups, notifications, language, and custom fields.

Instructions

Create new EduBase user account.

Input Schema

TableJSON Schema

Name	Required	Description
`exam`	No	user is only allowed to login when accessing exams (default: false)
`color`	No	desired favorite color (default/branding/red/blue/yellow/green/purple/gray) (default: default)
`email`	Yes	valid email address
`group`	No	name of the user group
`phone`	No	valid phone number in format "+prefix number" without special characters
`custom`	No	custom field data, keyed by field name (sent as `custom_{field}`), only if the specified field is configured for the target EduBase instance
`gender`	No	gender ("male", "female", or "other")
`notify`	No	notify user via email (or SMS) (default: false)
`language`	No	desired account language (default: API application owner's language)
`password`	No	password (4-64 characters) (default: initial random password is automatically generated)
`template`	No	a template ID for the new account (default: none)
`timezone`	No	desired timezone (default: API application owner's timezone)
`username`	Yes	username (4-64 characters)
`birthdate`	No	date of birth
`full_name`	No	override automatic full name (1-255 characters)
`last_name`	Yes	last name (1-64 characters)
`first_name`	Yes	first name (1-64 characters)
`display_name`	No	override automatic display name (1-255 characters)
`must_change_password`	No	user is forced to change password on first login (default: false)

Output Schema

TableJSON Schema

Name	Required	Description
`user`	Yes	user identification string
`password`	No	password, only if exam=false
`username`	No	username, only if exam=false

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedv1.2.15Sep 2, 2026

addedInput schema / properties / custom

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "custom field data, keyed by field name (sent as `custom_{field}`), only if the specified field is configured for the target EduBase instance",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

Changed19 schema fields changedv1.1.2Mar 13, 2026

addedInput schema / $schema

Added value: +"http://json-schema.org/draft-07/schema#"

changedInput schema / properties / color / description

Previous value: -"desired favorite color (default/branding/red/blue/yellow/green/purple) (default: default)"New value: +"desired favorite color (default/branding/red/blue/yellow/green/purple/gray) (default: default)"

addedInput schema / properties / color / enum

Added value: +[
+  "default",
+  "branding",
+  "red",
+  "blue",
+  "yellow",
+  "green",
+  "purple",
+  "gray"
+]

addedInput schema / properties / display_name / maxLength
```
Added value: +255
```
addedInput schema / properties / display_name / minLength
```
Added value: +1
```
addedInput schema / properties / email / format
```
Added value: +"email"
```

addedInput schema / properties / email / pattern

Added value: +"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

addedInput schema / properties / first_name / maxLength
```
Added value: +64
```
addedInput schema / properties / first_name / minLength
```
Added value: +1
```
addedInput schema / properties / full_name / maxLength
```
Added value: +255
```
addedInput schema / properties / full_name / minLength
```
Added value: +1
```

addedInput schema / properties / gender / enum

Added value: +[
+  "male",
+  "female",
+  "other"
+]

addedInput schema / properties / last_name / maxLength
```
Added value: +64
```
addedInput schema / properties / last_name / minLength
```
Added value: +1
```
addedInput schema / properties / password / maxLength
```
Added value: +64
```
addedInput schema / properties / password / minLength
```
Added value: +4
```
addedInput schema / properties / username / maxLength
```
Added value: +64
```
addedInput schema / properties / username / minLength
```
Added value: +4
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "password": {
+      "description": "password, only if exam=false",
+      "type": "string"
+    },
+    "user": {
+      "description": "user identification string",
+      "type": "string"
+    },
+    "username": {
+      "description": "username, only if exam=false",
+      "type": "string"
+    }
+  },
+  "required": [
+    "user"
+  ],
+  "type": "object"
+}

First observedv1.0.22Feb 21, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already establish that this is not read-only, not idempotent, and not destructive. The description adds that it creates a distinct new account, but it does not surface side effects such as automatic password generation, email/SMS notification when notify is set, or behavior when a username/email already exists. No contradiction 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 a single front-loaded sentence with no filler. Every word carries the operation and resource, which is ideal for a tool whose parameter details are fully captured in its schema.

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?

For a 19-parameter write operation, the one-line description is lean, but completeness comes from the accompanying schema: required fields, default password, notification, and valid values are all defined, and an output schema is present so return value details do not need to be in the description. It could be strengthened by naming sibling endpoints for lifecycle handling, but the core decision context is sufficient.

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?

Because schema_description_coverage is 100%, the schema already documents all 19 parameters including defaults, enums, lengths, formats, and the custom object behavior. The description itself adds no parameter-level details, so the standard 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 states a specific action ('Create') and a specific resource ('new EduBase user account'). This clearly distinguishes from sibling user operations like edubase_get_user, edubase_patch_user, and edubase_delete_user, so an agent can infer this is the provisioning endpoint.

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

Usage Guidelines2/5

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

There is no guidance on when to choose this over related user endpoints, no prerequisites such as required permissions or uniqueness constraints, and no mention that existing accounts should be handled with edubase_patch_user or edubase_delete_user. The only usage signal is the verb 'Create', which restates the tool's purpose rather than offering routing context.

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

Install Server

Other Tools

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EduBase/MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server