Groundmail

Create webhook

create_webhook

Create a webhook endpoint. Returns the endpoint plus a signing secret (shown once).

Input Schema

Name	Required	Description
`url`	Yes	HTTPS URL that receives events
`events`	No	Optional event types (defaults apply when omitted)
`tenants`	No	Optional: only these tenants' email events (external ids or Groundmail ids). Omit for all
`mailboxes`	No	Optional: only these mailboxes' mailbox events (mbx_ ids, addresses or external ids). Omit for all

Output Schema

Name	Required	Description	Default
`secret`	Yes	Signing secret for verifying deliveries. Shown only once, so store it
`webhook`	Yes	The created webhook endpoint

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 5, 2026

addedInput schema / properties / mailboxes

Added value: +{
+  "description": "Optional: only these mailboxes' mailbox events (mbx_ ids, addresses or external ids). Omit for all",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / webhook / properties / mailboxes

Added value: +{
+  "description": "Present only when the endpoint receives mailbox events for some mailboxes only: their ids (mbx_…)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changed1 schema field changedNov 3, 2026

addedOutput schema / properties / webhook / properties / health

Added value: +{
+  "description": "Delivery health: last_24h (total, delivered, failed, median_latency_ms), last_delivery_at, last_status, last_response_status, and failing (a delivery failed all 5 attempts in the last 24 hours)",
+  "type": "object"
+}

Changed2 schema fields changedOct 18, 2026

addedInput schema / properties / tenants

Added value: +{
+  "description": "Optional: only these tenants' email events (external ids or Groundmail ids). Omit for all",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / webhook / properties / tenants

Added value: +{
+  "description": "Present only when the endpoint receives email events for some tenants only: their external ids",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

First observedOct 16, 2026

TDQS

A3.6/5.0

Behavior4/5

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

The annotations already declare that the tool is a non-idempotent write with open-world effects, so the description does not need to repeat that profile. It does add genuinely valuable behavior that the annotations do not cover: the response includes a signing secret that is shown only once, warning the agent that the value must be captured immediately. It stops short of explaining what happens on duplicate URL registration or whether events start flowing immediately.

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?

It has two short sentences with no wasted wording, and the core action is front-loaded ahead of the return-value note. Every sentence earns its place.

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?

An output schema exists, so the return-value details do not need to be spelled out, and the description still flags the one-time secret — the critical runtime caveat. Some useful context is missing for a mutation tool: permissions requirements, duplicate-URL behavior, and how to verify delivery after creation.

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 each parameter, including the HTTPS requirement for url, the default behavior for events, and the tenant and mailbox scoping filters. The description adds no additional parameter meaning beyond what the schema already conveys, so the baseline 3 applies.

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?

The description uses a specific verb and resource ('Create a webhook endpoint') that clearly identifies the operation among siblings such as delete_webhook and list_webhooks. It does not explicitly name or differentiate against those siblings, but the naming already separates creation from listing and deletion.

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?

The description gives no when-to-use guidance, no prerequisites (for example, whether a verified domain or tenant is required), and never points to alternatives such as send_test_webhook_event for validating the endpoint or list_webhooks for checking existing registrations. Usage is only implied by the tool name.

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

All Groundmail tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?