EduBase MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

edubase_post_organization_webhook

Create a webhook for an organization, called on exam results, Quiz practice results, finished exam journeys or manual API triggers, with optional authentication and retries. Returns the webhook identification string.

Instructions

Input Schema

Name	Required	Description
`retry`	No	How to retry webhook notifications on failure (default: error): - none: no retry - error: delayed retry on any error
`title`	Yes	title of the webhook
`method`	No	HTTP method to use for webhook notifications (default: POST) - POST - GET
`endpoint`	Yes	URL to send webhook notifications to
`extra_data`	No	additional data (as JSON encoded string) to send with the webhook notification
`organization`	Yes	organization identification string
`trigger_event`	Yes	Type of event to trigger webhook: - exam-play-result: triggers when a user (must be member of the organization) completes an exam in the organization - quiz-play-result: triggers when a user (must be member of the organization) completes a quiz in practice mode in the organization - journey-completed: triggers when a user (must be member of the organization) finishes an exam journey started by an exam of the organization (see edubase_get_exam_journey) - api: triggers when a manual API call is made (useful for testing and debugging)
`authentication`	No	Type of authentication (default: none): - none: no authentication - key: use a secret key (or password) for authentication
`authentication_key`	No	secret key (or password) to use for authentication, required if authentication is set to key
`authentication_send`	No	How to send authentication data (default: data): - header: as header field - bearer: as Bearer token in Authorization header - data: as data field (in body or query string)
`authentication_send_data`	No	name of data field to send authentication data in, required if authentication is set to key and authentication_send is set to data
`authentication_key_custom`	No	custom field name to use as the authentication key, required if authentication is set to key, mutually exclusive with authentication_key
`authentication_send_header`	No	name of header field to send authentication data in, required if authentication is set to key and authentication_send is set to header

Output Schema

Name	Required	Description	Default
`webhook`	Yes
`organization`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.0.6Oct 14, 2026

changedInput schema / properties / trigger_event / description

Previous value: -"Type of event to trigger webhook: - exam-play-result: triggers when a user (must be member of the organization) completes an exam in the organization - quiz-play-result: triggers when a user (must be member of the organization) completes a quiz in practice mode in the organization - api: triggers when a manual API call is made (useful for testing and debugging)"New value: +"Type of event to trigger webhook: - exam-play-result: triggers when a user (must be member of the organization) completes an exam in the organization - quiz-play-result: triggers when a user (must be member of the organization) completes a quiz in practice mode in the organization - journey-completed: triggers when a user (must be member of the organization) finishes an exam journey started by an exam of the organization (see edubase_get_exam_journey) - api: triggers when a manual API call is made (useful for testing and debugging)"

changedInput schema / properties / trigger_event / enum

Previous value: -[
-  "exam-play-result",
-  "quiz-play-result",
-  "api"
-]New value: +[
+  "exam-play-result",
+  "quiz-play-result",
+  "journey-completed",
+  "api"
+]

Changed2 schema fields changedv2.0.0Sep 15, 2026
- removedOutput schema / properties / organization / description
```
Removed value: -"organization identification string"
```
- removedOutput schema / properties / webhook / description
```
Removed value: -"webhook identification string"
```

Changed3 schema fields changedv1.2.15Sep 2, 2026

removedInput schema / properties / name

Removed value: -{
-  "description": "title of the webhook",
-  "type": "string"
-}

addedInput schema / properties / title

Added value: +{
+  "description": "title of the webhook",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "organization",
-  "name",
-  "trigger_event",
-  "endpoint"
-]New value: +[
+  "organization",
+  "title",
+  "trigger_event",
+  "endpoint"
+]

Changed13 schema fields changedv1.1.2Mar 13, 2026

addedInput schema / $schema

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

changedInput schema / properties / authentication / description

Previous value: -"Type of authentication (default: none):\n- none: no authentication\n- key: use a secret key (or password) for authentication"New value: +"Type of authentication (default: none): - none: no authentication - key: use a secret key (or password) for authentication"

addedInput schema / properties / authentication / enum
```
Added value: +[
+  "none",
+  "key"
+]
```

changedInput schema / properties / authentication_send / description

Previous value: -"How to send authentication data (default: data):\n- header: as header field\n- bearer: as Bearer token in Authorization header\n- data: as data field (in body or query string)"New value: +"How to send authentication data (default: data): - header: as header field - bearer: as Bearer token in Authorization header - data: as data field (in body or query string)"

addedInput schema / properties / authentication_send / enum
```
Added value: +[
+  "header",
+  "bearer",
+  "data"
+]
```
addedInput schema / properties / endpoint / format
```
Added value: +"uri"
```

changedInput schema / properties / method / description

Previous value: -"HTTP method to use for webhook notifications (default: POST)\n- POST\n- GET"New value: +"HTTP method to use for webhook notifications (default: POST) - POST - GET"

addedInput schema / properties / method / enum
```
Added value: +[
+  "POST",
+  "GET"
+]
```

changedInput schema / properties / retry / description

Previous value: -"How to retry webhook notifications on failure (default: error):\n- none: no retry\n- error: delayed retry on any error"New value: +"How to retry webhook notifications on failure (default: error): - none: no retry - error: delayed retry on any error"

addedInput schema / properties / retry / enum
```
Added value: +[
+  "none",
+  "error"
+]
```

changedInput schema / properties / trigger_event / description

Previous value: -"Type of event to trigger webhook:\n- exam-play-result: triggers when a user (must be member of the organization) completes an exam in the organization\n- quiz-play-result: triggers when a user (must be member of the organization) completes a quiz in practice mode in the organization\n- api: triggers when a manual API call is made (useful for testing and debugging)"New value: +"Type of event to trigger webhook: - exam-play-result: triggers when a user (must be member of the organization) completes an exam in the organization - quiz-play-result: triggers when a user (must be member of the organization) completes a quiz in practice mode in the organization - api: triggers when a manual API call is made (useful for testing and debugging)"

addedInput schema / properties / trigger_event / enum

Added value: +[
+  "exam-play-result",
+  "quiz-play-result",
+  "api"
+]

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"
+    },
+    "webhook": {
+      "description": "webhook identification string",
+      "type": "string"
+    }
+  },
+  "required": [
+    "organization",
+    "webhook"
+  ],
+  "type": "object"
+}

First observedv1.0.22Feb 21, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true), so the safety burden is partially lifted. The description adds real behavioral context: that notifications are fired externally on specific events, that auth and retries are optional, and that an identification string is returned.

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?

Three tight sentences, front-loaded with the purpose, followed by the event list, return value, and testing pointer. No filler, though the 'Returns the webhook identification string' clause is mildly redundant given an output schema exists.

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 13-parameter creation tool with full schema coverage, an output schema, and annotations covering the safety profile, the description covers purpose, trigger scope, return, and the testing sibling. It is complete enough to call correctly, with only prerequisites/auth-permission details left unstated.

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% with 5 enums, so the schema already documents all 13 parameters thoroughly. The description's mention of trigger events, authentication, and retries merely paraphrases enum values already in the schema, adding little syntax or format detail beyond it.

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 and resource ('Create a webhook for an organization') and immediately scopes what the webhook is invoked for. An agent can distinguish this from the get/patch/delete_organization_webhook siblings, which handle existing webhooks rather than creation.

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

Usage Guidelines4/5

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

Gives clear context by enumerating the trigger events and explicitly routes the agent to edubase_post_organization_webhook_trigger for testing. It does not state exclusions or prerequisites (e.g. auth/permission requirements) but the usage context is clear.

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

Deploy Server