EduBase MCP Server

Official

by EduBase

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

edubase_get_organization_department

Read-onlyIdempotent

Retrieve an organization department by name or external ID to view its parent, hierarchy level, and member permissions.

Instructions

Get a department of an organization, identified by its name or external identifier: its parent, level in the hierarchy and the permissions given to its members.

Input Schema

Name	Required	Description	Default
`department`	Yes	name of the department (or its external identifier if no department has this name)
`organization`	Yes	organization identification string

Output Schema

Name	Required	Description	Default
`id`	No
`level`	Yes
`parent`	No
`leaders`	Yes
`members`	Yes
`department`	Yes
`permission`	Yes
`organization`	Yes
`members_custom`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.0.9Oct 26, 2026

addedOutput schema / properties / members_custom

Added value: +{
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}

changedOutput schema / required

Previous value: -[
-  "organization",
-  "department",
-  "level",
-  "permission",
-  "members",
-  "leaders"
-]New value: +[
+  "organization",
+  "department",
+  "level",
+  "permission",
+  "members",
+  "members_custom",
+  "leaders"
+]

Changed13 schema fields changedv2.0.0Sep 15, 2026
- removedOutput schema / properties / department / description
```
Removed value: -"name of the department"
```
- removedOutput schema / properties / id / description
```
Removed value: -"external unique department identifier (if set for the department)"
```
- removedOutput schema / properties / leaders / description
```
Removed value: -"leaders of the department"
```
- removedOutput schema / properties / leaders / items / properties / name / description
```
Removed value: -"name of the leader"
```
- removedOutput schema / properties / leaders / items / properties / user / description
```
Removed value: -"user identification string"
```
- removedOutput schema / properties / level / description
```
Removed value: -"depth of the department within the hierarchy (0 for root level departments)"
```
- removedOutput schema / properties / members / description
```
Removed value: -"number of (visible) members in the department"
```
- removedOutput schema / properties / organization / description
```
Removed value: -"organization identification string"
```
- removedOutput schema / properties / parent / description
```
Removed value: -"name of the parent department (null for root level departments)"
```
- removedOutput schema / properties / permission / description
```
Removed value: -"permissions given to the members of the department"
```
- removedOutput schema / properties / permission / properties / content / description
```
Removed value: -"permission level to contents in organization"
```
- removedOutput schema / properties / permission / properties / members / description
```
Removed value: -"permission level to members in organization"
```
- removedOutput schema / properties / permission / properties / organization / description
```
Removed value: -"permission level to organization"
```
Addedv1.2.17Sep 15, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds the outline of returned content (parent, hierarchy level, member permissions), but because an output schema exists and is not referenced, this adds only modest value beyond structured data.

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?

A single well-formed sentence with the resource, the identification method, and the returned facets, all front-loaded. No filler or repetition, though the colon-list structure is slightly dense.

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 and annotations carrying the safety profile, the description covers what the tool fetches and how the department is keyed. Only the sibling routing and failure behavior (e.g., not found, ambiguous names) remain undeclared.

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%, so both parameters are already documented, including the name-vs-external-identifier nuance. The description restates that identification rule without adding format or lookup semantics beyond the schema, making baseline 3 appropriate.

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?

States a specific verb and resource ('Get a department of an organization') and enumerates the returned facets (parent, level, permissions). It implicitly contrasts with the plural listing sibling edubase_get_organization_departments, but never names it, so an agent must infer the distinction.

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 implied: use this to fetch a single department by name or external identifier. There is no explicit statement of when to prefer it over edubase_get_organization_departments, edubase_get_organization, or when to choose the patch/delete department siblings instead.

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

Deploy Server