Skip to main content
Glama

Update a webhook

update_webhook

Change a webhook's URL, events, headers, description, or enabled state, or rotate its signing secret. Use it to fix delivery targets, update filters, or revoke a leaked secret immediately.

Instructions

Change a webhook's URL, events, description or headers, turn it off or back on, or replace its signing secret (rotate_secret: the old one stops working at once and the new one is in the answer). Turning it off drops what it still had waiting.

Input Schema

NameRequiredDescriptionDefault
urlNoThe new URL, whole. A public https URL (not a private, local or internal address). A key in it is fine (?token=…, or one in the path): the URL is kept sealed and shown back with its keys masked. user:password@ before the host is sent as an Authorization: Basic header instead.
eventsNo
enabledNo
headersNoReplaces all of the webhook's own headers ({} removes them). Headers of your own to send on every request, as { name: value }, for a receiver that checks who's calling: e.g. { "Authorization": "Bearer <key>" } or { "X-Api-Key": "<key>" }, exactly as the receiver's setup gives them. Sent alongside Parley's own headers and signature; kept sealed, and only each name and the value's last 4 characters are ever shown back. At most 10; Parley's own (Parley-*, Webhook-*, Content-Type, User-Agent, Host…) can't be set.
webhook_idYes
descriptionNo
rotate_secretNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that rotate_secret invalidates the old secret immediately and returns the new one 'in the answer', and that disabling 'drops what it still had waiting' — real destructive side effects an agent must know before calling. Gaps remain on permissions required, error/failure behavior, and confirmation that omitted fields are left unchanged.

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?

Two sentences, no filler; the capability list is front-loaded and the two consequences (secret rotation, dropped queue on disable) are attached directly to the parameters they affect via parentheticals.

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 7-parameter mutation tool with nested headers, no annotations, no output schema and low schema coverage, the definition covers the risky paths (secret rotation, disabling, header replacement) well enough to call safely. It stops short of describing validation/error outcomes or the events field's replace semantics, which would be needed for a full picture.

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 description coverage is only 29%, so the description has to compensate, and it does add meaning the schema lacks: rotate_secret's immediate invalidation plus return of the new secret, and the delivery-dropping consequence of enabled=false. It adds nothing about events or description, leaving those thin, so it falls short of full compensation.

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?

Names a specific verb and resource and enumerates the exact mutable surface (URL, events, description, headers, on/off, rotate_secret), which cleanly separates it from create_webhook and delete_webhook in the sibling list. An agent can decide immediately that this is the in-place modification tool.

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?

Usage is implied by the field enumeration — if you want to change or toggle an existing webhook, this is the tool — but it never names alternatives or excludes cases (e.g. 'to fire a test delivery use test_webhook', 'to change delivery history use resend_webhook_delivery'). Context is clear, but no explicit when-not guidance.

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