EduBase MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

edubase_post_organization_webhook

Create an organization webhook to send notifications on exam results, quiz practice results, or manual API triggers, with configurable authentication and retry options.

Instructions

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

Input Schema

TableJSON 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 - 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

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

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.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the agent knows this is a non-idempotent write operation. The description adds meaningful behavioral context: it states the return value (webhook identification string), the trigger conditions, and that authentication and retries are optional. It does not detail side effects or failure modes, but the annotations plus description cover the key behavioral traits.

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, information-dense sentence that front-loads the core purpose, then adds the return value and a pointer to the test tool. Every clause earns its place; no filler or repetition of schema details.

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 a full schema and an output schema, the description is complete enough: it states the purpose, return value, and a testing path. It does not explain the authentication/retry configuration details, but those are fully documented in the schema, and the output schema covers return values. The only minor gap is not mentioning that updates are handled by edubase_patch_organization_webhook, but that is not essential for invoking this tool correctly.

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 the schema already documents all 13 parameters. The description adds a little context by naming the trigger events and mentioning optional authentication/retries, but it does not add meaning beyond the schema's per-parameter descriptions. Baseline 3 is appropriate when the schema carries the full parameter documentation.

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 verb ('Create'), a resource ('webhook for an organization'), and the triggering conditions ('exam results, Quiz practice results or manual API triggers'). It also mentions optional authentication and retries, and notes the return value ('webhook identification string'). This clearly distinguishes it from sibling tools like edubase_delete_organization_webhook and edubase_post_organization_webhook_trigger.

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?

The description gives clear context on when to use this tool: to create a webhook for an organization, and explicitly suggests testing with edubase_post_organization_webhook_trigger. It does not explicitly state when not to use it or name alternatives like edubase_patch_organization_webhook for updates, but the trigger event enum and the mention of manual API triggers provide useful usage context.

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

Deploy Server