Skip to main content
Glama
Sign In

mailbox.bot

by bot.mailbox
OverviewDiscussionsAdmin

list_webhook_endpoints

Read-onlyIdempotent

List the member's webhooks (name, URL, events, keyword rules, status), without secrets. Legacy agent callback settings are separate. Requires webhook.manage. Uses the same bounded control plane and tenant/agent/Live-Sandbox authorization as /api/v1/webhooks/endpoints. Reuse the exact idempotency_key and input after an uncertain mutation. Webhook docs: https://mailbox.bot/docs/webhooks.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / result / properties / endpoints / items / properties / event_types / items / enum
      Previous value: -[
-  "inbound.received",
-  "inbound.action.requested",
-  "inbound.action.completed",
-  "inbound.pages_ready",
-  "inbound.keywords_matched",
-  "mail.pending_approval",
-  "mail.submitted",
-  "mail.ready",
-  "mail.mailed",
-  "mail.delivered",
-  "mail.failed",
-  "mail.cancelled",
-  "batch.submitted",
-  "batch.completed",
-  "batch.partially_completed",
-  "batch.failed",
-  "batch.cancelled"
-]New value: +[
+  "inbound.received",
+  "inbound.action.requested",
+  "inbound.action.completed",
+  "inbound.pages_ready",
+  "inbound.keywords_matched",
+  "mail.pending_approval",
+  "mail.submitted",
+  "mail.ready",
+  "mail.mailed",
+  "mail.delivered",
+  "mail.failed",
+  "mail.cancelled",
+  "batch.submitted",
+  "batch.completed",
+  "batch.partially_completed",
+  "batch.failed",
+  "batch.cancelled",
+  "batch.piece.scanned",
+  "batch.piece.confirmed"
+]
  2. Changed2 schema fields changed
    • changedOutput schema / properties / result / properties / endpoints / items / properties / event_types / items / enum
      Previous value: -[
-  "inbound.received",
-  "inbound.action.requested",
-  "inbound.action.completed",
-  "inbound.pages_ready",
-  "inbound.keywords_matched"
-]New value: +[
+  "inbound.received",
+  "inbound.action.requested",
+  "inbound.action.completed",
+  "inbound.pages_ready",
+  "inbound.keywords_matched",
+  "mail.pending_approval",
+  "mail.submitted",
+  "mail.ready",
+  "mail.mailed",
+  "mail.delivered",
+  "mail.failed",
+  "mail.cancelled",
+  "batch.submitted",
+  "batch.completed",
+  "batch.partially_completed",
+  "batch.failed",
+  "batch.cancelled"
+]
    • changedOutput schema / properties / result / properties / endpoints / items / properties / event_types / maxItems
      Previous value: -16New value: +32
  3. Changed6 schema fields changed
    • changedOutput schema / properties / result / properties / endpoints / items / properties / event_types / items / enum
      Previous value: -[
-  "inbound.received",
-  "inbound.scan_available",
-  "inbound.context_ready",
-  "inbound.rule_matched",
-  "inbound.action_completed",
-  "inbound.action_failed",
-  "mail.submitted",
-  "mail.ready",
-  "mail.mailed",
-  "mail.delivered",
-  "mail.failed",
-  "mail.cancelled",
-  "mail.pending_approval"
-]New value: +[
+  "inbound.received",
+  "inbound.action.requested",
+  "inbound.action.completed",
+  "inbound.pages_ready",
+  "inbound.keywords_matched"
+]
    • changedOutput schema / properties / result / properties / endpoints / items / properties / status / enum
      Previous value: -[
-  "pending_verification",
-  "active",
-  "paused"
-]New value: +[
+  "active",
+  "paused"
+]
    • removedOutput schema / properties / result / properties / endpoints / items / properties / verified_at
      Removed value: -{
-  "anyOf": [
-    {
-      "format": "date-time",
-      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ]
-}
    • changedOutput schema / properties / result / properties / endpoints / items / required
      Previous value: -[
-  "name",
-  "url",
-  "agent_id",
-  "environment",
-  "event_types",
-  "rules",
-  "id",
-  "member_id",
-  "status",
-  "revision",
-  "verified_at",
-  "created_at",
-  "updated_at",
-  "last_delivery_at",
-  "last_http_status",
-  "failure_count",
-  "signing_key_prefix",
-  "previous_key_expires_at"
-]New value: +[
+  "name",
+  "url",
+  "agent_id",
+  "environment",
+  "event_types",
+  "rules",
+  "id",
+  "member_id",
+  "status",
+  "revision",
+  "created_at",
+  "updated_at",
+  "last_delivery_at",
+  "last_http_status",
+  "failure_count",
+  "signing_key_prefix",
+  "previous_key_expires_at"
+]
    • addedOutput schema / properties / result / properties / sample_item_id
      Added value: +{
+  "anyOf": [
+    {
+      "format": "uuid",
+      "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
    • changedOutput schema / properties / result / required
      Previous value: -[
-  "enabled",
-  "endpoints",
-  "source_delivery",
-  "agents",
-  "limits"
-]New value: +[
+  "enabled",
+  "endpoints",
+  "source_delivery",
+  "agents",
+  "sample_item_id",
+  "limits"
+]
  4. Added

TDQS

A3.8/5.0
Behavior3/5

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

Valuable additions sit on top of the annotations: the webhook.manage scope requirement, the no-secrets redaction, and the tenant/agent/Live-Sandbox authorization model. However, the sentence "Reuse the exact idempotency_key and input after an uncertain mutation" is nonsense for a zero-parameter read tool and risks making the agent think it is a mutation. That boilerplate weakens an otherwise useful disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded well: field list first, then scope and auth, then docs. But the idempotency retry sentence earns no place for a read-only zero-param call, and the API-path and docs-link sentences crowd out more useful information about when to use this.

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 return values need not be explained; the description still names a few. Auth scope, redaction, and the legacy-callback boundary fill the main gaps for a simple list tool. Only the relationship to the webhook deliveries and mutation siblings is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so the baseline of 4 applies. The description instead spends its effort on what is returned, which is the right place for a zero-arg list tool.

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 ("List the member's webhooks") and enumerates the returned fields (name, URL, events, keyword rules, status), so the agent knows exactly what it gets. It also draws a boundary against a nearby concept: "Legacy agent callback settings are separate." That is enough to distinguish it from create/update/rotate/deliveries siblings.

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?

The exclusion of legacy agent callback settings and the "without secrets" scope are real usage signals, but when to choose this over list_webhook_deliveries or the get/update siblings is never stated, and no alternatives are named. The context is implied rather than prescribed.

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

All mailbox.bot toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources