Skip to main content
Glama
canopy-labs

Featureflip

Official
by canopy-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Send a test event or redeliver

deliver_webhook

Test a webhook subscription with a synthetic flag.toggled event, or re-send a finished delivery to restart its retry schedule. Delivery is asynchronous; check delivery listings for the outcome.

Instructions

action=test queues one synthetic flag.toggled event to this subscription alone; action=redeliver (deliveryId from list_webhook_deliveries) re-sends a finished delivery, restarting its retry schedule. Delivery is asynchronous: read list_webhook_deliveries for the outcome. Both are refused for a disabled subscription, and redeliver for a delivery that is still Pending. Requires an Admin token. A 404 on every webhook call means webhooks are not enabled for the organization.

Input Schema

NameRequiredDescriptionDefault
idYesSubscription id (from list_webhooks)
actionYestest sends a synthetic event; redeliver re-sends deliveryId
deliveryIdNoRequired for redeliver

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.0
    • addedInput schema / properties / action / description
      Added value: +"test sends a synthetic event; redeliver re-sends deliveryId"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$defs": {
+    "PublicTestWebhookSubscriptionResponse": {
+      "description": "The queued test event and its delivery. Poll the delivery log for the outcome.",
+      "properties": {
+        "webhookDeliveryId": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "webhookEventId": {
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    }
+  },
+  "anyOf": [
+    {
+      "$ref": "#/$defs/PublicTestWebhookSubscriptionResponse"
+    },
+    {
+      "properties": {
+        "id": {
+          "type": "string"
+        },
+        "redelivered": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "redelivered"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}
  2. Addedv0.1.8

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only cover openWorldHint and destructiveHint=false, but the description adds substantial operational context: asynchronous delivery, need to read list_webhook_deliveries for the result, Admin-token requirement, refusal conditions, and the 404-means-webhooks-disabled signal.

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?

Front-loads the action semantics, then layers async behavior, failure conditions, and auth. Every clause carries information; no filler despite the density.

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?

An output schema exists so return format needn't be explained, and the description covers auth, refusal states, async outcome polling, and the org-level 404 case. Nothing an agent needs to invoke it correctly 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?

Schema coverage is 100% so the baseline is 3, but the description adds real value by identifying the source of deliveryId (list_webhook_deliveries) and clarifying that test targets this subscription alone. It reinforces rather than merely repeats the schema.

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+resource and disambiguates the two action modes ('test queues one synthetic flag.toggled event to this subscription alone'; 'redeliver ... re-sends a finished delivery'). An agent can tell exactly what each call does and how it differs from siblings like list_webhook_deliveries.

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?

Explicitly maps each action value to its use case and prerequisite (deliveryId from list_webhook_deliveries for redeliver), names the sibling to poll for outcomes, and gives when-not conditions (refused for disabled subscriptions; redeliver refused while delivery is Pending).

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

Deploy Server

Other Tools