@briefgate/mcp

Manage webhook endpoints

manage_webhook

Destructive

Create, list, or delete HTTPS webhook endpoints for BriefGate intake events, enabling push delivery instead of polling get_intake_status.

Instructions

Register, list, or remove a webhook endpoint: a public HTTPS URL on the user's own service that BriefGate POSTs intake events to, as an alternative to polling get_intake_status. Webhook reference: https://briefgate.dev/docs/webhooks

The endpoint must be reachable from the internet over HTTPS. A URL that cannot receive (for example a process that runs only in a local terminal) produces failing deliveries while the intake looks watched, so without such a service polling get_intake_status is the working option.

action="create" returns a signing "secret" exactly once. The receiving service needs it to verify the signature on every delivery (verifyWebhookSignature from @briefgate/mcp/webhook), and it cannot be shown again. If it is ever exposed, there is no rotation in place — delete the endpoint and create a new one, which issues a fresh secret.

Events: intake.completed (all required items in — the one to act on), item.submitted (a single item arrived), client.viewed (the client opened the portal), chase.bounced (a reminder failed to deliver), intake.overdue (the due date passed with required items outstanding — the one to act on when work is blocked), intake.stalled (fires only when the intake sets max_reminders; without it this event never arrives).

Input Schema

TableJSON Schema

Name	Required	Description
`url`	No	HTTPS endpoint to deliver to. Required for action="create".
`action`	Yes	What to do. "list" needs no other argument.
`events`	No	Events to receive. Required for action="create". For "tell me when the client is done", this is ["intake.completed"].
`format`	No	Payload shape. "raw" (default) is the signed BriefGate envelope; "slack" and "discord" post a message those services render directly.
`webhook_id`	No	Endpoint to remove. Required for action="delete".

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.10.5Sep 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "active": {
+          "type": "boolean"
+        },
+        "created_at": {
+          "type": "string"
+        },
+        "events": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "format": {
+          "type": "string"
+        },
+        "id": {
+          "type": "string"
+        },
+        "note": {
+          "type": "string"
+        },
+        "secret": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    {
+      "properties": {
+        "webhooks": {
+          "items": {
+            "properties": {
+              "active": {
+                "type": "boolean"
+              },
+              "created_at": {
+                "type": "string"
+              },
+              "events": {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              "format": {
+                "type": "string"
+              },
+              "id": {
+                "type": "string"
+              },
+              "url": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    {
+      "properties": {
+        "deleted": {
+          "enum": [
+            true
+          ],
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}

Addedv0.9.0Sep 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructive/openWorld/non-idempotent, and the description adds critical behavior beyond them: the signing secret is returned exactly once, cannot be re-shown, has no rotation, and recovery means delete+recreate. It also warns that an unreachable URL yields failing deliveries while 'the intake looks watched' — a real operational trap.

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?

Dense but well-structured: definition, prerequisite, secret lifecycle, then event semantics, each section earning its place. Slightly long with the docs URL, but no filler sentences and key warnings are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, return-format explanation is unnecessary; the description instead covers the things structured fields cannot — reachability prerequisite, one-time secret handling, no-rotation recovery path, and event meaning — leaving no operational gap for a mutation tool.

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?

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning: per-action requirements are reinforced and each event enum value is explained (what it fires on and which to act on), which the schema's bare enum list does not convey.

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 specific verbs (register, list, remove) and the exact resource (webhook endpoint), then defines it as a public HTTPS URL BriefGate POSTs intake events to. Explicitly positions it against the sibling/alternative get_intake_status polling, so an agent can distinguish it without reading the schema.

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

Usage Guidelines5/5

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

Names the alternative (polling get_intake_status) and the condition that selects it: if the endpoint cannot be reached over the internet, polling is the working option. Also tells the agent which events to act on (intake.completed, intake.overdue) versus informational ones.

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

Deploy Server