Skip to main content
Glama
EduBase

EduBase MCP Server

Official
by EduBase
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

edubase_post_organization

Create an organization with title and optional details like description, website, contact, and custom fields, returning the organization ID.

Instructions

Create an organization with a title and optional description, website, contact details and custom fields. Returns the organization identification string.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNocontact email address
phoneNocontact phone number
titleYestitle of the organization
customNocustom field data, keyed by field name (sent as `custom_{field}`), only if the specified field is configured for the target EduBase instance
domainNodomain name (FQDN) for the organization without www prefix, needs special privileges to set!
websiteNohomepage URL
descriptionNooptional short description

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
organizationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • removedOutput schema / properties / organization / description
      Removed value: -"organization identification string"
  2. Changed4 schema fields changedv1.2.15
    • 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"
+}
    • removedInput schema / properties / name
      Removed value: -{
-  "description": "title of the organization",
-  "type": "string"
-}
    • addedInput schema / properties / title
      Added value: +{
+  "description": "title of the organization",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "name"
-]New value: +[
+  "title"
+]
  3. Changed5 schema fields changedv1.1.2
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • 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 / website / format
      Added value: +"uri"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "organization": {
+      "description": "organization identification string",
+      "type": "string"
+    }
+  },
+  "required": [
+    "organization"
+  ],
+  "type": "object"
+}
  4. First observedv1.0.22

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already signal a mutating, non-read-only operation, and the description's 'Create' is consistent. The description adds the useful fact that the response is an organization identification string, but it doesn't discuss side effects, idempotency implications, or authorization beyond what annotations and schema imply.

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?

A single sentence that front-loads the action ('Create an organization'), lists the optional parameters at a high level, and closes with the return value. Every phrase carries useful information with no padding.

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 full schema coverage, annotations, and an output schema, the description covers the essential call contract: what is created, which optional fields exist, and what is returned. Minor details like the special privileges for 'domain' are left to the schema, which is acceptable.

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%, and each parameter already has a descriptive entry in the schema. The description only summarizes optional field categories without adding semantic detail beyond the schema, so it earns the baseline score for full schema coverage.

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 ('Create') and resource ('an organization'), and enumerates the optional fields and return value. The create verb clearly distinguishes it from sibling patch/delete/get organization tools, even without naming them.

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?

No explicit when-to-use or alternatives are provided. The 'Create' verb implies it should be used for new organizations rather than existing ones, but it doesn't mention patch_organization for updates or delete_organization, leaving usage guidance to inference.

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