Skip to main content
Glama

Create a webhook

create_webhook

Create a signed webhook so Parley POSTs real-time events—messages, reactions, deletions—to your URL instead of polling the inbox.

Instructions

Have Parley POST to a URL the moment something happens on one linked number, instead of polling read_inbox. Each webhook belongs to one number; add one per number to hear from several. Events: message.received (a message came in from someone else); message.sent (the account sent a message (from its phone, or through Parley)); reaction.added (someone (or the account) reacted to a message, or changed their reaction); reaction.removed (someone (or the account) took their reaction back); message.deleted (a message was deleted for everyone). Only real, live changes are sent: never history, backfills, or a message seen twice; chats the account holder ignored never send. Each request is a signed JSON POST: { id, type, created_at, sent_at, connection: { id, channel, account }, data }; for messages the text is at data.message.text (the answer's payload_format has every event's shape and an example: build the receiver from it). If the receiver checks who's calling with a key of its own (an Authorization header or API key its setup gave you), pass it in headers. The answer carries the signing secret: keep it, it isn't shown again (update_webhook with rotate_secret makes a new one). The account holder sees and can change every webhook on that number's page on the Parley dashboard. At most 10 per number.

Input Schema

NameRequiredDescriptionDefault
urlYesA 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.
eventsNoWhich events to send. Default: all of them.
headersNoHeaders 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.
descriptionNoWhat it's for, shown on the dashboard.
connection_idNoWhich of your accounts: a connection id from list_connections, or the account's number. Optional when only one account fits. The webhook hears only from this number.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/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 so: it enumerates every event type and its meaning, discloses delivery semantics ('Only real, live changes... never history, backfills, or a message seen twice; chats the account holder ignored never send'), specifies the signed POST body shape, and warns that the signing secret is returned once and not shown again. It also notes dashboard visibility and the per-number cap, which are behavior an agent cannot infer elsewhere.

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?

Front-loaded with the core purpose and the read_inbox contrast, and every sentence carries information. The main cost is density: a single paragraph with deep nested parentheses around the event list and payload shape, which is harder to scan than a short list would be. No filler, though.

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?

For a five-parameter, nested-object creation tool with no output schema, this covers what an agent needs: payload contract, event catalog, secret handling and rotation path, auth header caveats, delivery exclusions, and quotas. It also redirects to the response's `payload_format` for per-event shapes rather than duplicating them, which is the right division of labor.

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 would be 3, but the description adds real meaning: it names each event and what triggers it (message.received vs message.sent vs reaction.added), explains that events default to all, frames headers as the receiver's own auth that rides alongside Parley's signature, and clarifies the connection_id-to-number binding. The `url`/`headers` masking and Basic-auth behavior are left to the schema, which already covers them well.

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?

Opens with a concrete verb+resource+trigger: 'Have Parley POST to a URL the moment something happens on one linked number.' It also contrasts itself with a named alternative ('instead of polling read_inbox') and scopes the resource ('Each webhook belongs to one number'), so an agent can distinguish it from read_inbox, connect, and the sibling webhook tools without opening a schema.

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

Usage Guidelines4/5

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

Gives clear when-to-use guidance: prefer this over polling read_inbox, and add one webhook per number to hear from several numbers. It also states a hard operating limit ('At most 10 per number') and points at update_webhook with rotate_secret for the one follow-up scenario. It stops short of saying when not to create one (e.g. use test_webhook to verify, resend_webhook_delivery for retries), so it is strong context but not a full routing guide.

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